Как я добавляю определенную для проекта информацию к комментарию фиксации Мерзавца?
С Мерзавцем, если Вы фиксируете, это включает раздел в соответствии с сообщением о фиксации, которое комментируется. Это содержит инструкции относительно записи сообщения о фиксации, а также списка файлов, которые изменяются. Как это:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: important-file.txt
#
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: some-other-thing.txt
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# untracked.txt
Действительно ли возможно добавить дальнейший материал к этому файлу? Один ясный вариант использования для тех, которые используют программное обеспечение отслеживания ошибки как Trac, Redmine и т.п. указывает дополнительные синтаксические элементы. Пользователи Redmine, например, могут включать номер выпуска и некоторые специальные ключевые слова для маркировки проблем, как разрешено: ключевые слова являются "судьями" (и "ссылки"), и "фиксирует" (или "завершения") - но я часто нахожу трудным помнить ключевые слова.
Было бы удобно, затем, если можно было бы добавить некоторый определенный для проекта текст в нижней части инструкций по фиксации.
Есть ли какой-либо существующий способ сделать это, или я должен взломать один в? Как второстепенный вопрос, сделайте какие-либо другие VCSes (как Подвижный) имеют подобное поведение?
4 ответа
Я использовал commit.template (как описано здесь). Я мог бы использовать хук prepare-commit-msg, но шаблон коммита делает эту работу немного проще, плюс я могу хранить шаблон коммита в системе контроля версий проекта.
Вариант 1:
Как уже упоминалось, прямой способ сделать это с помощью Git - это обработчик prepare-commit-message .
Однако есть проблемы с этой стратегией, которые необходимо учитывать. Из главы 7.4 Pro Git:
[клиентские скрипты ловушек] не перенесен с клоном проект, вы должны распространить эти скрипты каким-то другим способом, а затем ваши пользователи копируют их в свои Каталог .git / hooks и сделайте их исполняемый файл. Вы можете распространять эти крючки внутри проекта или в отдельный проект, но нет возможности чтобы настроить их автоматически.
Вариант 2:
Как упоминал Том Моррис , используйте шаблон фиксации .
Вариант 3:
Вы можете создать собственную сборку Git, которая будет включать ваши дополнительные инструкции. Инструкции, включенные в текущее сообщение фиксации, жестко запрограммированы в исходном коде Git. См. $ GIT_SRC / builtin / commit.c , начиная с , строка 655 .
Этот метод, вероятно, не является предпочтительным, поскольку вам придется применять патч каждый раз при выпуске новой версии Git.
Вариант 4:
Создайте патч для Git, который добавляет эту функцию, и отправьте его в список рассылки. Если вы (или другие) решите попробовать это, я сначала попросил бы совета из списка о том, как действовать.
Mercurial:
Скрипты хуков в Mercurial ведут себя аналогичным образом. Из главы 10 Mercurial: The Definitive Guide:
В Mercurial хуки не являются пересмотром контролируются, и не размножаются, когда вы клонируете или извлекаете из репозитория.Причина проста: крючок это совершенно произвольный кусок исполняемый код. Он работает под вашим личность пользователя, с вашей привилегией уровень, на вашей машине.
Это было бы крайне безрассудно для любого распределенная система контроля версий для реализовать хуки с контролем ревизий, так как это предложило бы легко эксплуатируемый способ ниспровергнуть аккаунты пользователей ревизии система контроля.
Вы можете настроить сообщение коммита через prepare-commit-message hook.
Я уверен, что для этого можно использовать хук prepare-commit-msg. Посмотрите на githooks для получения дополнительной информации.