Скотт Чакон - Pro Git

Эта возможность реализована как команда и как параметр конфигурации. Параметр конфигурации называется rerere.enabled, который можно включить глобально следующим образом:

$git config --global rerere.enabled true

После этого любое разрешение конфликта слияния будет записано на случай повторного использования.

Если нужно, вы можете обращаться к кэшу “rerere” напрямую, используя команду git rerere. Когда команда вызвана без параметров, Git проверяет базу данных и пытается найти решение для разрешения текущего конфликта слияния (точно так же как и при установленной настройке rerere.enabled в значение true). Существует множество дополнительных команд для просмотра, что именно будет записано, удаления отдельных записей из кэша, а так же его полной очистки. Более детально “rerere” будет рассмотрено в Rerere.

После выпуска релиза, возможно, вы захотите пометить текущее состояние так, чтобы можно было вернуться к нему в любой момент. Для этого можно добавить тэг, как было описано в Основы Git. Кроме этого, вы можете добавить цифровую подпись для тэга, выглядеть это будет вот так:

$git tag -s v1.5 -m 'my signed 1.5 tag'

You need a passphrase to unlock the secret key for

user: "Scott Chacon "

1024-bit DSA key, ID F721C45A, created 2009-02-09

Если вы используете цифровую подпись при расстановке тэгов, то возникает проблема распространения публичной части PGP ключа, использованного при создании подписи. Сопровождающий Git проекта может решить эту проблему добавив в репозиторий свой публичный ключ как бинарный объект и установив ссылающийся на него тэг. Чтобы это сделать, выберите нужный ключ и списка доступных, который можно получить с помощью команды gpg --list-keys:

$gpg --list-keys

/Users/schacon/.gnupg/pubring.gpg

---------------------------------

pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09]

uid Scott Chacon

sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09]

Затем экспортируйте выбранный ключ и поместите его непосредственно в базу данных Git при помощи команды git hash-object, которая сосздаст новый объект с содержимым ключа и вернёт SHA-1 этого объекта:

$gpg -a --export F721C45A | git hash-object -w --stdin

659ef797d181633c87ec71ac3f9ba29fe5775b92

Теперь, когда ваш публчниый ключ находится в репозитории, можно проставить указывающий на него тэг, используя полученное ранее значение SHA-1:

$git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92

Выполнив команду git push --tags, maintainer-pgp-pub тэг станет общедоступным. Теперь все, кто захочет проверить вашу подпись, могут ипортировать ваш публиный ключ, предварительно получив его из репозитория:

$git show maintainer-pgp-pub | gpg --import

После этого можно проверять цифровую подпись ваших тэгов. Кроме этого, вы можете включить дополнительные инструкции по проверке вашей подписи в сообщение тэга, которое будет отображаться каждый раз при вызове команды git show .

Git не использует монотонно возрастающие идентификаторы для коммитов, поэтому если вы хотите получить читаемые имена комитов, то воспользуйтесь командой git describe для нужного коммита. Git вернёт имя ближайшего тэга, количество коммитов после него и частичное значение хэша SHA-1 для указанного коммита:

$git describe master

v1.6.2-rc1-20-g8c5b85c

Таким образом, вы можете сделать снимок или собрать билд и дать ему понятное для человека название. К слову, если вы склонируете репозиторий Git и соберете его из исходного кода, то вывод команды git --version будет примерно таким же. Если попытаться получить имя коммита, которому назначен тэг, то результатом будет название самого тэга.

Команда git describe поддерживает аннотированные тэги (созданные с использованием опций -a или -s), поэтому следует использовать именно такие тэги для пометки релизов, особенно если вы используете git describe для проверки корректности именования коммитов. Так же это название можно использовать при выполнении команд “checkout” и “show”, однако в конце имени содержится частичный SHA-1 хэш, поэтому название не будет валидным постоянно. К примеру, ядро Linux недавно перешло к использованию 10 символов в SHA-1 хэшах вместо 8, чтобы обеспечить уникальность каждого объекта, таким образом предыдущие результаты git describe стали невалидными.

Время делать релиз сборки. Возможно, вы захотите сделать архив последнего состояния вашего кода для тех, кто не использует Git. Для создания архива выполните команду git archive:

$git archive master --prefix= 'project/' | gzip > ` git describe master ` .tar.gz

$ls *.tar.gz

v1.6.2-rc1-20-g8c5b85c.tar.gz

Распаковав архив, вы получите последнее состояние кода вашего проекта в директории “project”. Точно таким же способом можно создать zip архив, просто добавив опцию --format=zip для команды git archive:

$git archive master --prefix= 'project/' --format=zip > ` git describe master ` .zip

Теперь у вас есть два архива с релизным состоянием вашего кода, которые можно загрузить на сайт или отправить по почте.

Сейчас самое время оповестить людей из списка рассылки, которые хотят знать что происходит с вашим проектом. С помощью команды git shortlog можно быстро получить список изменений, внесенных в проект с момента последнего релиза или предыдущей рассылки. Она собирает все коммиты в заданном интервале. Например, следующая команда выведет список коммитов с момента последнего релиза с названием v1.0.1:

$git shortlog --no-merges master --not v1.0.1

Chris Wanstrath (8):

Add support for annotated tags to Grit::Tag

Add packed-refs annotated tag support.

Add Grit::Commit#to_patch

Update version and History.txt

Remove stray `puts`

Make ls_tree ignore nils

Tom Preston-Werner (4):

fix dates in history

dynamic version method

Version bump to 1.0.2

Regenerated gemspec for version 1.0.2

И так, у вас есть готовая к отправке сводка коммитов, сгруппированных по авторам.

Вы должны чувствовать себя достаточно свободно, внося свой вклад в проект под управлением Git, а также занимаясь поддержкой своего собственного проекта или интегрированием наработок других пользователей. Поздравляем вас, опытный Git-разработчик! В следующей главе вы узнаете о том, как использовать самый большой и самый популярный Git хостинг, GitHub.

Гитхаб это крупнейшее хранилище Git репозиториев, а так же центр сотрудничества для миллионов разработчиков и проектов. Огромный процент репозиториев хранится на Гитхабе. Многие проекты с открытым исходным кодом используют его ради Git хостинга, баг-трекера, рецензирования кода и других вещей. Так что, пока всё это не часть открытого Git проекта, наверняка вы захотите, или вам придётся взаимодействовать с Гитхабом при профессиональном использовании Git.

Эта глава про эффективное использование Гитхаба. Мы разберём регистрацию, управление учетной записью, создание и использование Git репозиториев, как вносить вклад в чужие проекты и как принимать чужой вклад в собственный проект, а так же программный интерфейс Гитхаба и ещё множество мелочей, который облегчат вам жизнь.