То, о чем вы просите, это, по сути, расширение ключевых слов. Для начала рассмотрим вопрос Git FAQ «Does git have keyword expansion?». В нем говорится:
Расширение ключевых слов не рекомендуется. Расширение ключевого слова вызывает всевозможные странные проблемы и в любом случае не очень полезно, особенно в контексте SCM. Вы можете выполнить расширение ключевого слова за пределами git, используя собственный скрипт. Сценарий экспорта ядра Linux делает это, чтобы установить переменную EXTRA_VERSION в Makefile.
См. gitattributes(5), если вы действительно этого хотите. Если ваш перевод не является обратимым (например, расширение ключевого слова SCCS), это может быть проблематичным. (Подсказка: поставленный $Id$-expansion помещает 40-значное шестнадцатеричное имя объекта blob в идентификатор, вы можете выяснить, какие коммиты включают этот blob, используя сценарий, такой как this.)
См. here for a discussion и here on how GIT may help anyway.
Так что у git есть что-то вроде расширения ключевого слова, хотя это не рекомендуется. Git также не имеет понятия «редактирование файла» (это то, что кажется вашим номером @version
), поэтому это не сможет дать вам именно то, о чем вы просите.
Вы также можете создать крючок (возможно, крюк предварительного приема?), Который увеличит вашу версию. Это всего лишь исполняемый файл (так что это может быть оболочка/Python/Perl/Ruby/whatever-you're-comfortable-with script), который будет автоматически выполняться при нажатии. См. githooks man page.
Ваш скрипт крючок будет:
- Определение файлов, которые должны быть изменены.
- Из тех, что нашли узоры
@version \d+
- Прирастить версию. Вы хотите увеличить значение в родительском коммите, а не значение, которое в настоящее время находится в файле!
Обратите внимание, что это, по крайней мере, столь же плохо, как с помощью расширения ключевых слов, что Git FAQ рекомендует против, и, возможно, гораздо хуже. Это, вероятно, приведет к раздражающим конфликтам слияния. Вы также можете легко ввести вводящие в заблуждение номера версий в своем коде, особенно если вам когда-либо понадобится исправление для более старой версии, хотя это, вероятно, также произойдет, когда вы объедините изменения из нескольких репозиториев/филиалов (что довольно часто встречается у большинства git workflows), если вы не будете осторожны.
См. Также http://stackoverflow.com/questions/1127177/to-put-the-prefix-revision-number-to-codes-by-git-svn – VonC