Извлечение версии сборки приложения из `git description` - как получить относительно простую строку?

Question

ОБНОВЛЕНИЕ

Я вижу, что этот вопрос стал несколько популярным.Прошло уже много лет с моего по-настоящему приятного использования Git, и с тех пор я многому научился. Пожалуйста , довольно пожалуйста прочитайте последний абзац перед тем, как продолжить о своих приключениях в Git, с тем, что вы узнали из этого Q & A.

---

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

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

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

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

Теперь я знаю , что ветки Git - это просто ссылки на фиксацию, и поэтому многие ветки (и теги!) Могут указыватьна один коммит.Следовательно, вопрос «к какой ветви принадлежит этот коммит / принадлежит» не является полностью действительным для Git.Git отслеживает «текущую» ветку, в которой вы находитесь - ту, которую он для вас извлек - но в то же время любое количество других веток может указывать на тот же коммит и, возможно, нетОдна ветвь может быть выбрана как «главная», если вы не хотите иметь в виду ту, которая в настоящий момент извлечена на диск.Пожалуйста, прочитайте следующий ответ на этой странице для уточнения.

Answer 1

Вот что я использую:

echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"

Он производит что-то вроде:

master-6de772e

Как отметил Аристотель, на самом деле SHA-1 сам по себе является всем необходимым и достаточным для обеспечения однозначного тега сборки, а также полной информации, касающейся исторического контекста развития. Все остальное является избыточным в том смысле, что любая информация, которую они предоставляют, может быть получена или получена из SHA-1. Тем не менее, людям может понравиться дополнительная контекстная информация о фактической ветви, которая сразу же становится очевидной (или, по крайней мере, это делает этот человек), и, следовательно, включение названия ветви в метку. По этой причине (т.е. непосредственный анализ информации человеком) большинство моих проектов также используют более длинное «описание» идентификатора сборки, которое включает дату и время фиксации, на которой была основана сборка, в дополнение к метке идентификатора сборки 'дано выше.

Answer 2

В git вы должны понимать, что ветки - это просто фиксация закладок. Тот факт, что вы были в ветке foo, когда вы сделали коммит 0deadbeef, не имеет значения для самого коммита; ветвь не является частью своей идентичности.

(Mercurial вставляет имя ветки в коммит. По-разному, это хуже, как объясняет Дастин Саллингс .)

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

Еще одно примечание: вы можете возразить, что даже если «третий коммит из тега X» в общем случае неоднозначен, git describe может просто посмотреть на график и выяснить, является ли он неоднозначным, и если нет, пропустите хэш. Однако ничто не может помешать кому-либо начать ветку поверх этого тега позднее - поэтому ваша строка describe станет неоднозначной ретроспективно .

Суть в том, что однозначным идентификатором коммита only является его хеш. Так что это должно быть там. Что делает git describe, так это добавляет избыточную (и в случае номера коммита, неоднозначную) информацию, которая делает описание более полезным для вида пространственного / реляционного понимания, с которым люди ориентируются в пределах границ модели Git.

Answer 3

Официальные выпуски должны иметь тег с номером их версии.В этом случае я предлагаю следующий подход:

1. Если у текущего коммита есть тег, используйте этот тег
2. Если тег недоступен, используйте имя ветви и ключ SHA1

Эта единственная команда должна работать:

git describe --exact-match 2> /dev/null || echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"

Answer 4

git describe --long всегда будет выводить номер версии следующим образом: v1.2-10-gdeadbee , что означает 10-й коммит с аннотированным тегом 'v1.2', который указывает на коммит с укороченным SHA-1 «мертвец». Так что все, что вам нужно сделать, это пометить начало ветви (точка ветвления ветви), например. <<em>branch</em>>-start.

Сокращенный хэш SHA-1 коммита требуется для различения неоднозначных ситуаций, потому что «3-й коммит, т. К. Тег« x »» (например) не уникально различает коммит; может быть более одного коммита, который соответствует упомянутому описанию при наличии нелинейного, ветвистого развития. Например, в ситуации, показанной на диаграмме ASCII-искусства ниже, оба коммита, отмеченные *, соответствуют описанию «3-й коммит с тега« x »».

          /-.---*---.-\                   
         /             \                  
.---x---.---.---*---.---M---.    <--- branch

_{Обратите внимание, что в случае "слияния", как показано выше, вы не можете использовать имя ветви, чтобы различать эти два коммита с одинаковым описанием.}

Итак, вам нужно взять git describe --long вывод (здесь есть опция --long, чтобы избежать двусмысленности при разборе, см. git description manpage ), проанализировать ее и добавить текущую ветвь информация (например, от git symbolic-ref HEAD, , а не от ввода git branch output) самостоятельно.