2.3.2 Git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись. Кроме этого в git представленные так называемые «легковесные тэги» («lightweight tags»), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко: git tag stable-1 — создать «легковесный» тэг, связанный с последним коммитом. Если тэг уже есть, то еще один создан не будет. git tag stable-2 f292ef5 — пометить определенный коммит.  git tag -d stable-2 — удалить тег. git tag -l — перечислить тэги. git tag -f stable-1.1 — создать тэг для последнего коммита, заменить существующий, если таковой уже был. После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее: git diff stable-1.1...stable-1 Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию»: git tag -a stable — создать обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария. git tag -a stable -m «production version» — создать обычный тэг, сразу указав в качестве аргумента комментарий. Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

2.3.3 Относительная адресация

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master: git diff master^ Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния: git diff HEAD^2 — найти изменения по сравнению со вторым предком последнего коммита в master. HEAD здесь — указатель на последний коммит активной ветки. Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться: git diff master^^ — что привнес «дедушка» нынешнего коммита. git diff master~2 — то же самое. Обозначения можно объединять, чтобы добраться до нужного коммита: git diff master~3^~2 git diff master~6

2.3.4 Файл .Gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.  Заставить git status игнорировать можно, создав в корне или глубже по дереву (если ограничения должны быть только в определенных директория) файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов определенного формата. Пример содержимого такого файла: >>>>>>>Начало файла #комментарий к файлу .gitignore #игнорируем сам .gitignore .gitignore #все html-файлы… *.html #… кроме определенного !special.html #не нужны объектники и архивы *.[ao] >>>>>>>>Конец файла Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore.

3 «Вместе мы — сила», или основы работы с удаленным репозитарием

Естественно, что большая часть проектов все-таки подразумевает работу по крайней мере двух разработчиков, которым требуется обмениваться кодом. Далее будут перечислены команды, требующиеся для совместной — возможно удаленной — работы.

3.1 Удаленные ветки (remote tracking branches)

Новое понятие здесь — удаленные ветки. Удаленные ветки соответствуют какой-либо ветке (чаще master) на удаленном сервере. Одна такая создается автоматически при создании копии удаленного репозитария; все команды, связанные с удаленной работой, будут по умолчанию использовать именно эту удаленную ветку (обычно называется «origin»). Рассмотрим эти команды.

3.2 git clone — создание копии (удаленного) репозитария

Для начала работы с центральным репозитарием, следует создать копию оригинального проекта со всей его историей локально: git clone /home/username/project myrepo — клонируем репозитарий с той же машины в директорию myrepo. git clone ssh://user@somehost:port/~user/repository — клонируем репозитарий, используя безопасный протокол ssh (для чего требуется завести у себя на машине эккаунт ssh). git clone git://user@somehost:port/~user/repository/project.git/ — у git имеется и собственный протокол.

3.3 git fetch и git pull — забираем изменения из центрального репозитария (из удаленной ветки)

Для синхронизации текущей ветки с репозитарием используются команды git fetch и git pull. git fetch — забрать изменения удаленной ветки из репозитария по умолчания, основной ветки; той, которая была использована при клонировании репозитария. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge. git fetch /home/username/project — забрать изменения из определенного репозитария. Возможно также использовать синонимы для адресов, создаваемые командой git remote: git remote add username-project /home/username/project git fetch username-project — забрать изменения по адресу, определяемому синонимом.  Естественно, что после оценки изменений, например, командой git diff, из надо создать коммит слияния с основной: git merge username-project/master Команда git pull сразу забирает изменения и проводит слияние с активной веткой: git pull — забрать из репозитария, для которого были созданы удаленные ветки по умолчанию. git pull username-project — забрать изменения из определенного репозитария. Как правило, используется сразу команда git pull.