Должна ли ветвь релиза или основная ветвь быть помечена при использовании gitflow?


16

Эта проблема указывает на то, что:

Насколько я понимаю, размещение тега в ветке релиза до слияния (а не в ветке master) на самом деле является правильным решением, так как его можно найти с помощью git description --tags из ветки Develop. Смотрите № 374

пока еще один пост :

Я случайно установил версию 0.4.2-pre через homebrew сегодня и был озадачен тем, как в этой версии работает тегирование. Ранее (версия 0.4.1) тег создавался в основной ветке, после того, как ветка выпуска была объединена с ней. Теперь кажется, что тег создается при последнем коммите в ветке релиза, что не очень хорошая идея для меня. Особенно, если у вас есть система сборки, которая опирается на теги git и создает версию выпуска, если HEAD представляет собой коммит с тегами, и версию разработки, если один из следующих коммитов. Может ли кто-нибудь объяснить мне логику этого изменения? И что касается семантического управления версиями, я бы не стал рассматривать это как повышение версии на уровне патча!

В нашей команде у нас было и было много дискуссий по этому поводу. Некоторые указывают, что тег должен быть создан из главной ветви, в то время как другие предпочитают ветку выпуска. Согласно картинке Gitflow:

введите описание изображения здесь

похоже, что тег размещен на мастере.


1
Я знаю, что GitLab борется с тегами на ветках, когда вы убираете старые ветви, поэтому было бы лучше, если бы тег был на главном. Не уверен насчет других инструментов git.
HorusKol

«Gitflow» подразумевает, что этот (IMO плохой) рабочий процесс является стандартным или официальным рабочим процессом Git. Это не так.
Майлз Рут

@MilesRout Какой ваш любимый рабочий процесс git?
030

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

Ответы:


16

Во-первых, вы не можете пометить ветки, вы можете только пометить коммиты.

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

(Вот почему люди говорят о «воспроизводимых сборках»: поэтому они могут быть уверены, что в процессе их выпуска не появятся новые ошибки, которых не было в их среде предварительного просмотра / размещения, и что если у них есть ошибки в работе, то же самое двоичный файл работает на их машине, когда они идут на его отладку.)

Нет смысла отмечать второй зеленый коммит снизу (зеленый дочерний элемент коммита, помеченный как «Только исправления!») Как «v1.0», потому что вы не выпустили этот коммит в производство. Вы выпустили коммит на мастере. Вы даже можете видеть, что git flow пометил это как 'Tag 1.0'.

Помните, у тегов есть цель: легко найти коммиты. Вы помечаете коммит как 'v1.0', чтобы вы могли легко найти то, что вы выпустили как версию 1.0. Вы не помечаете его ради наличия тега 'v1.0' где-то в вашем дереве коммитов, смутно близкого к коммиту, который вы фактически выпустили.

Если у вас есть проблемы с поиском тегов в вашей ветке разработки, это совершенно отдельная проблема. Исправьте инструмент, который вы используете, чтобы найти теги. Или еще лучше: не используйте git-flow. На этой диаграмме это выглядит красиво из-за прекрасных цветных точек и красиво выложенных линий, но на самом деле это похоже на безумную грязную паутину цветных линий и точек.


3
You should tag the commit you actually release, Таким образом, если, например, 20 коммитов, которые должны быть освобождены, находятся в ветви релиза, и эта ветвь объединяется с ведущим, то созданный коммит слияния должен быть помечен, чтобы узнать, что было выпущено?
030

1
Да, коммит слияния будет помечен. Как вариант git-flow, я также видел создание / тегирование отдельной «фиксации версии» непосредственноbranch:master
rmharrison
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.