Если вы работаете в Windows и хотите выполнить приведенные ниже шаги, все, что вам нужно сделать, это настроить Git на локальном компьютере.
Прежде чем мы перейдем к командам Git, имейте в виду (и не забывайте!), Что у Git есть рабочий каталог, промежуточная область и локальный репозиторий. Смотрите обзор ниже, взятый с http://progit.org .
Рабочий процесс GIT выглядит следующим образом: Вы идете в каталог, где вы хотите иметь контроль версий. Вы используете git init чтобы поставить этот каталог под контроль версий. Это создает новый репозиторий для этого текущего местоположения. Вы вносите изменения в свои файлы, а затем используете git add to stage files в области подготовки. Вы будете использовать git status и git diff чтобы увидеть, что вы изменили, а затем, наконец, git commit для фактической записи снимка навсегда в ваш локальный репозиторий. Если вы хотите загрузить свои изменения в удаленный репозиторий, вы будете использовать git push . Если вы хотите загрузить изменения из удаленного репозитория в локальный репозиторий, вы будете использовать git fetch и git merge .
Давайте пройдемся по этому шаг за шагом.
Чтобы создать хранилище из существующего каталога файлов, вы можете просто запустить git init в этом каталоге. Перейдите в тот каталог, который вы хотите получить под контролем версий:
|
1
|
git init |
Все новые и измененные файлы должны быть добавлены в промежуточную область перед фиксацией в хранилище. Чтобы добавить все файлы в текущем каталоге в область подготовки:
|
1
|
git add --all |
Чтобы зафиксировать файлы и изменения в хранилище:
|
1
|
git commit -am "Initial commit" |
Обратите внимание, что я использовал опцию -am которая неявно add -all . Эта команда эквивалентна «commit» в стиле SVN или CVS. Опять же: если вы хотите обновить свой локальный репозиторий Git, всегда есть операция добавления, за которой следует операция фиксации со всеми новыми и измененными файлами.
Затем вы создаете хранилище на Github.com . Допустим, вы назвали это git_example.
Затем вы добавляете адрес удаленного хранилища в вашу локальную конфигурацию GIT:
|
1
|
git remote add EXAMPLE https://nschlimm@github.com/nschlimm/git_example.git |
Обратите внимание, что в примере это мое имя пользователя на Github.com. Вам нужно будет использовать свой очевидно. Я назвал удаленный репозиторий «ПРИМЕР». Вы можете ссылаться на псевдоним вместо использования удаленного URL-адреса все время. Вы готовы общаться с удаленным хранилищем сейчас.
Если вы находитесь за брандмауэром, вы настраиваете прокси:
|
1
|
|
Затем вы отправляете свои файлы в удаленный репозиторий:
|
1
|
git push EXAMPLE master |
Тогда представьте, что кто-то изменил удаленные файлы. Вы должны получить их:
|
1
|
git fetch EXAMPLE |
Вам необходимо объединить эти изменения с удаленного мастера в локальную ветвь мастера (простым языком: вы копируете изменения из локального репозитория в рабочий каталог). Предположим, что ваш текущий контекст является основной веткой, и вы хотите объединить EXAMPLE ветку с главной, вы напишите:
|
1
|
git merge EXAMPLE |
Чтобы сравнить область подготовки с вашим рабочим каталогом:
|
1
|
git status -s |
В примере показан статус после того, как я изменил файл README.txt (но еще не добавил и не зафиксировал).
Без каких-либо дополнительных аргументов простой git diff покажет, какой контент вы изменили в своем проекте с момента последнего коммита, который еще не подготовлен для следующего снимка коммита.
|
1
|
git diff |
В примере показан вывод diff после того, как я отредактировал файл README.txt (но еще не добавил и не зафиксировал). Когда я добавляю все изменения в промежуточную git diff , git diff не будет отображать изменения, потому что в вашей рабочей директории нет ничего, что не было подготовлено.
С git status по-другому. Он показывает разницу между вашим последним коммитом и промежуточной / рабочей областью:
Вкратце: git status показывает различия между вашим локальным хранилищем и вашим рабочим каталогом / промежуточной областью. В то время как git diff (как использовано выше) показывает различия между вашей областью подготовки и вашим рабочим каталогом.
Вот и все. Это самые важные команды Git, которые новичок должен знать, чтобы начать. См. Ссылку на gitref.org для получения дополнительной информации об использовании Git.
Загрузка удаленного репозитория
Если вы хотите скопировать репозиторий с Github.com (или любого другого удаленного адреса) на локальный компьютер:
|
1
|
git clone https://nschlimm@github.com/nschlimm/spring-decorator.git |
Теперь вы можете работать с кодом и отправить изменения обратно в этот удаленный репозиторий, если хотите.
Работа с ветками — изменение текущего контекста
Ветвь в Git — это не что иное, как «текущий контекст», в котором вы работаете. Обычно вы начинаете работать в «основной» ветке. Допустим, вы хотите попробовать что-то, и вы не уверены, что то, что вы делаете, является хорошей идеей (что на самом деле случается очень часто :-)). В этом случае вы можете создать новую ветку и поэкспериментировать с вашей идеей:
|
1
|
git branch [branch_name] |
Когда вы просто войдете в git branch он выведет список ваших новых веток.
Если вы хотите работать с новой веткой, вы можете написать:
|
1
|
git checkout [branch_name] |
Обратите внимание на один важный факт: если вы переключаетесь между ветками, это не меняет состояние ваших измененных файлов. Скажем, у вас есть измененный файл foo.java . Вы переключаетесь с master ветки на новую ветку some_crazy_idea . После переключения foo.java все еще будет в измененном состоянии. Вы можете some_crazy_idea его в ветку some_crazy_idea . Если вы переключитесь на master ветку, однако этот коммит не будет виден, потому что вы не зафиксировали в контексте master ветки. Если бы файл был новым, вы бы даже не увидели его в рабочем дереве.
Если вы хотите, чтобы другие узнали о вашей новой идее, вы отправляете ветку в удаленный репозиторий:
|
1
|
git push [remote_repository_name] [branch_name] |
Вы бы использовали fetch вместо push чтобы снова внести изменения в удаленную ветку в ваш локальный репозиторий.
Вот как вы снова удаляете ветку, если она вам больше не нужна:
|
1
|
git branch -d [branch_name] |
Удаление файлов
Если вы случайно зафиксировали что-то в ветке, вы можете легко удалить файл снова. Например, чтобы удалить файл readme.txt текущей ветки:
|
1
|
git rm --cached readme.txt |
Опция --cached удаляет только файл из индекса. Ваш рабочий каталог остается без изменений.
Вы также можете удалить папку. .settings папка .settings для проекта eclipse — это то, что вы не должны делить с другими:
|
1
|
git rm --cached -r some_eclipse_project/.settings |
После rm команды rm файл все еще находится в индексе (история контроля версий Git). Вы можете навсегда удалить всю историю с помощью этой команды:
Примечание: будьте очень осторожны с такими командами и попробуйте их в копии своего репозитория, прежде чем применять их в своем производительном репозитории. Всегда создавайте копию полного хранилища, прежде чем запускать такие команды.
|
1
|
git filter-branch --index-filter 'git rm --cached --ignore-unmatch [your_file_name]' HEAD |
Игнорирование файлов: вы не хотите контролировать версию определенного файла или каталога
Чтобы игнорировать файлы, вы просто добавляете имя файла в файл .gitignore в каталоге, которому принадлежит файл. Таким образом, он больше не будет добавлен в систему контроля версий. Вот мой .gitignore для корневого каталога проекта Eclipse:
|
1
2
3
4
|
/target/.settings.project.classpath |
Он игнорирует target и папку .settings а также .project и файл .classpath .
Иногда полезно настроить глобальные правила игнорирования, которые применяются ко всему хранилищу:
|
1
|
git config --global core.excludesfile ~/.gitignore_global |
Это добавило следующую запись в мой .gitconfig глобальных параметров .gitconfig который находится в корневом каталоге git.
excludesfile = d:/dev_home/repositories/git/.gitignore_global
Это мои текущие глобальные правила исключения в моем файле .gitignore_global :
# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so
# Logs and databases #
######################
*.log
Примечание: эти правила доступны другим пользователям. Локальные правила репо могут быть добавлены в файл .git / info / exclude в вашем репо. Эти правила не привязаны к репо, поэтому они не передаются другим.
Восстановление файлов — поставь часы обратно
Иногда вы вносите изменения в свои файлы и через некоторое время понимаете, что то, что вы сделали, было плохой идеей. Вы хотите вернуться к своему последнему состоянию фиксации. Если вы внесли изменения в свой рабочий каталог и хотите восстановить последний коммит HEAD в своем рабочем каталоге, введите:
|
1
|
git reset --hard HEAD |
Эта команда устанавливает для текущего --hard ветви последний коммит (HEAD) и перезаписывает ваш локальный рабочий каталог этим последним состоянием фиксации (опция --hard ). Таким образом, он будет перезаписывать ваши измененные файлы.
Вместо HEAD (который является вашим последним коммитом) вы можете назвать ветку или тэг как ‘v0.6’. Вы также можете сбросить до предыдущего коммита: HEAD ~ 2 — коммит до вашего последнего коммита.
Может быть, вы хотите восстановить файл, который вы удалили в вашем рабочем каталоге. Вот что я ввел для восстановления java-файла, который я случайно удалил:
|
1
|
git checkout HEAD sources/spring-decorator/src/test/java/com/schlimm/decorator/simple/SetupSession.java |
Опять же: вместо HEAD вы можете назвать ветку или тег, например, «v0.6». Вы можете извлечь файл из предыдущего коммита: HEAD ~ 2 — коммит до вашего последнего коммита.
Работа с тегами — создание закладок для вашего исходного кода
Иногда вы хотите сделать версию вашего исходного кода. Таким образом, вы можете обратиться к нему позже. Чтобы применить тег версии v1.0.0 к вашим файлам, вы должны написать:
|
1
|
git tag -a v1.0.0 -m "Creating the first official version" |
Вы можете поделиться своими тегами с другими в удаленном хранилище:
|
1
|
git push [remote_repository_name] --tags |
Где remote_repository_name — это псевдоним вашего удаленного репозитория. Вы пишете fetch вместо push чтобы получить теги, которые другие отправили в удаленный репозиторий, в ваш локальный репозиторий.
Если вы просто введете git tag он выдаст вам список известных тегов. Чтобы получить информацию о теге v1.0.0, вы должны написать:
|
1
|
git show v1.0.0 -s |
Если вы хотите продолжить работу с тегом, например, в производственной ветке с версией v5.0.1, введите:
|
1
|
git checkout v5.0.1 -b [your_production_branch] |
Обратите внимание, что эта команда также создает новую ветвь для тега, таким образом, вы можете делать коммиты и все остальное, что хотите записать обратно в репозиторий.
Справка: «Лучшие 10 команд для новичка Git» от нашего партнера JCG Никласа.