GIT: наличие текущего хэша фиксации и последнего тега в файле при фиксации

это скорее вопросы ноу-хау, наверное:

Я управляю версиями с помощью git и отправляю файлы для PHP CMS на тестовый или рабочий сайт с помощью rsync. Теперь я хотел бы отслеживать, какой коммит в настоящее время развернут, используя надежную и автоматизированную систему, я думал об этом:

Настройте хук git, чтобы добавить/обновить текстовый файл с последним тегом и хэшем фиксации. Тогда я могу легко найти коммит.

Моя проблема в том, что во время предварительной фиксации скрипт не будет знать хэш фиксации. Есть ли какой-нибудь простой способ сделать это (или другой подход, который приводит к тем же целям)?

Спасибо за ваш вклад заранее!


git deployment pre-commit
person Martin Rasser    schedule 03.05.2013    source источник
comment
Я думаю, вы хотите справиться с этим на стороне развертывания. Напишите сценарий для развертывания, а затем заставьте этот сценарий скопировать текущий хэш куда-нибудь в каждый файл, прежде чем он скопирует их.   -  person Mason    schedule 03.05.2013
comment
Забавно, после публикации вопроса у меня возникла именно такая идея. Тем не менее, было бы еще лучше, если бы git позаботился о файле версии — в этом случае не будет иметь значения, как обрабатывается развертывание.   -  person Martin Rasser    schedule 03.05.2013
comment
Если вы попытаетесь сохранить информацию о версии в файле под контролем версий git, обновить и зафиксировать, вы получите новую фиксацию SHA1. :) Вы должны сделать это вне git.   -  person Tuxdude    schedule 03.05.2013
comment
Нет, это логически невозможно, и ваше решение не может работать. Помещение текущего идентификатора коммита в файл обязательно изменит текущий коммит. Вы можете (в лучшем случае) поместить в файл идентификатор предыдущего коммита, но это будет гораздо менее полезно. Вы действительно, действительно не должны пытаться управлять этим с помощью Git.   -  person meagar    schedule 03.05.2013

Ответы (3)


arrow_upward
9
arrow_downward

Хорошо, я думаю, что получил нормальное решение:

Существует git-хук под названием post-commit, и вот что я делаю:

  • Я помещаю файл с тегом/хэшем в .gitignore (чтобы избежать ненужных изменений при следующем коммите)
  • Пусть хук post-commit обновит файл версии.

Содержимое хукового файла:

#!/bin/sh 
git describe --tags > version.txt

Теперь я уверен, что этот файл обновляется после каждой фиксации, поэтому все готово, если я делаю фиксацию перед развертыванием.

Примечания. Неприятное предостережение для новичков: сделайте файл ловушки исполняемым, git игнорирует файл без предупреждения, если это не так.

Все о git-хуках: http://git-scm.com/book/en/Customizing-Git-Git-Hooks

Все о .gitignore: http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files

Ваше здоровье,

Мартин

person Martin Rasser    schedule 04.05.2013

arrow_upward
3
arrow_downward

Это часто задаваемые вопросы.

https://git.wiki.kernel.org/index.php/Git_FAQ#Does_Git_have_keyword_expansion.3F

Найдите export-subst в gitattributes(5), вам нужно использовать git-archive(1), чтобы выполнить замену.

(%H дает вам хеш. Чтобы получить тег, вам все равно понадобится скрипт, который вызывает git-describe(1), я не вижу формата для этого)

person Uwe Geuder    schedule 03.05.2013
comment
Красивый! После проб и ошибок вот мои .gitattribtues: version.txt export-subst. И моя версия.txt: $Format:%H$ - person Peter Ehrlich; 10.10.2015

arrow_upward
3
arrow_downward

Поскольку вы используете rsync для deploy своего кода, сделайте что-то вроде этого:

$ git describe --long > VERSION.txt

Затем включите VERSION.txt в пакет rsync.

Строка gitscribe выглядит следующим образом:

$ git describe --long
r1.0-2-gca93d0a

В приведенном выше:

  1. Последний тег: r1.0
  2. 2 указывает, что мы сделали две фиксации после этого тега.
  3. g означает «git» (хорошо, это немного странно, но да ладно)
  4. Текущий хэш: ca93d0a.
person John Jesus    schedule 04.05.2013
comment
Спасибо, выглядит хорошо, увидел ваш ответ после публикации моего - посмотрите ответ, где git позаботится об этом. Если подумать, пусть сценарий rsync позаботится об этом, и это имеет свои преимущества, поскольку он обеспечивает актуальность файла версии. Я мог бы даже использовать сценарий rsync, чтобы фактически запретить развертывание, если в рабочей копии есть незафиксированные изменения. - person Martin Rasser; 04.05.2013
comment
Хорошая идея с проверкой рабочего дерева на наличие бродяг. Можете ли вы проголосовать за мой ответ, если он полезен? Мне нужно пару очков, чтобы перейти на следующий уровень. - person John Jesus; 05.05.2013