Как произойти, строка версии сборки приложения с Мерзавцем 'описывают' команду?
Я хочу составить версию сборки приложения, которая автоматически получена из имени ответвления Мерзавца, которое я иду (при создании) и количество фиксаций, так как ответвление отличалось. Я полагаю, что это будет уникально для какой-либо фиксации в моем репозитории Мерзавца? Имена ответвления уникальны, и фиксации связаны друг с другом вдоль ответвления? Если и когда я отмечаю фиксацию, у меня может также быть версия, снабжаются префиксом тот тег.
В некотором роде git describe делает то, что я хочу, но это не включает имя ответвления, я иду, и это включает сокращенный хеш SHA-1 фиксации, который я не думаю, что мне нужно, поскольку это ничего не добавляет к энтропии строки и может быть избыточно (я могу быть неправым здесь, поэтому исправьте меня).
Каковы мои опции? И я думаю в правильном направлении здесь вообще? Я просто немного устал от добавления чисел к версиям, когда у меня есть более важные вещи иметь дело с относительно разработки программного обеспечения.
Я никогда не создаю с грязным рабочим деревом, между прочим. Т.е. Я всегда передаю изменения в репозитории прежде, чем создать общедоступный выпуск.
3 ответа
Что вы должны понимать о git, так это то, что ветки по сути являются просто закладками фиксации. Тот факт, что вы были в ветке foo , когда выполняли коммит 0deadbeef , не имеет значения для самого коммита; филиал не является частью его идентичности.
(Mercurial записывает имя ветки в коммит. Во многих отношениях это хуже, как объясняет Дастин Саллингс .)
Даже если предположить, что git describe будет использовать только текущую извлеченную ветку - если у вас есть история слияния, может быть несколько путей, ведущих к той же самой последней помеченной фиксации, которая git describe будет использовать. Так что даже не обязательно какая-то одна ветка.
Еще одно замечание: вы можете возразить, что даже если «3-я фиксация из тега X» в общем случае неоднозначна, git describe может просто посмотреть на график и выяснить, ли это неоднозначно, а если нет, то хеш не учитывать. Однако ничто не мешает кому-либо запустить ветвь поверх этого тега в более позднее время - тогда ваша строка описать станет неоднозначной ретроспективно .
Суть в том, что единственный однозначный идентификатор коммита является его хешем. Так что это должно быть там. Что git describe делает, так это добавляет некоторую избыточную (и, в случае номера фиксации, неоднозначную) информацию, которая делает описание более полезным для такого рода пространственного / реляционного понимания, на которое люди ориентируются. с, в рамках модели Git.
git describe --long всегда будет выводить номер версии следующим образом: v1.2-10-gdeadbee , что означает 10-ю фиксацию с момента annotated тег 'v1.2', указывающий на фиксацию с сокращенным SHA-1 'deadbee'. Итак, все, что вам нужно сделать, это отметить начало ветки (точку ветвления ветки), например. < ветвь > - начало .
Сокращенный хэш SHA-1 фиксации требуется, чтобы различать неоднозначные ситуации, потому что «3-я фиксация после тега 'x'» (например) не однозначно различает фиксацию; может быть более одного коммита, который соответствует упомянутому описанию при наличии нелинейной, ветвистой разработки. Например, в ситуации, показанной на диаграмме ASCII-art ниже, обе коммиты, отмеченные *, соответствуют описанию «3-я фиксация с момента тега 'x'».
/-.---*---.-\
/ \
.---x---.---.---*---.---M---. <--- branch
Обратите внимание, что в случае «слияния в», как показано выше, вы не можете использовать имя ветки, чтобы различать эти два коммита с одинаковым описанием.
Итак, что вам нужно сделать, это получить вывод git describe --long (параметр - long здесь, чтобы избежать двусмысленности при синтаксическом анализе, см. git описать справочную страницу ), проанализировать ее и добавить информацию о текущей ветке (например, из git symbolic-ref HEAD , не из вывода pasing git branch ) самостоятельно .
Вот что я использую:
echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"
Получается что-то вроде:
master-6de772e
Как заметил Аристотель, на самом деле SHA-1 сам по себе - это все, что необходимо и достаточно для обеспечения однозначной метки сборки, а также полной информации о развитии исторического контекста. Все остальное является избыточным, в том смысле, что любая информация, которую они предоставляют, может быть вычислена или получена из SHA-1. Однако людям может понравиться дополнительная контекстуальная информация о фактическом ответвлении, которая сразу же становится очевидной (по крайней мере, этому человеку), и, следовательно, встраивание названия ответвления в метку. По этой причине (т.е. для немедленного разбора информации человеком) в большинстве моих проектов также используется более длинное "описание" идентификатора сборки, которое включает дату и время коммита, на котором была основана сборка, в дополнение к "метке" идентификатора сборки, приведенной выше.