Чи слід відмітити гілку випуску або головну гілку, коли використовується gitflow?

Це питання вказує на те, що:

З мого розуміння, розміщення тегу на гілці випуску перед об'єднанням (а не на головній гілці) насправді це правильно. Це можна знайти і за допомогою git description - теги з гілки розробки. Див. №374

в той час як інший пост :

Сьогодні я випадково встановив 0.4.2-попередню версію через homebrew і збентежився тим, як працює маркування у цій версії. Раніше (версія 0.4.1) тег був створений на головній гілці після того, як гілка випуску була об'єднана в неї. Тепер, здається, тег створений на останньому фільмі гілки випуску, що, здається, не є гарною ідеєю для мене. Особливо, якщо у вас є система складання, яка покладається на теги git і створює версію випуску, якщо HEAD - це тег фіксованої версії та версія розробки, якщо її виконує один із наступних. Чи може хтось пояснити мені логіку, що стоїть за цією зміною? Щодо семантичної версії, я не вважаю це набуттям версій на рівні патчу!

У нашій команді ми мали і мали багато дискусій з цього приводу. Деякі вказують, що тег потрібно створити з ведучої гілки, а інші віддають перевагу гілці випуску. Відповідно до малюнка gitflow:

схоже, що тег розміщується на майстрі.

По-перше, ви не можете тегувати гілки, ви можете лише тегувати коміти.

Ви повинні позначити комісію, яку ви фактично звільняєте. У цьому і полягає зміст тегів версій. Якщо у вас виникли проблеми із вашим програмним забезпеченням у якомусь середовищі (виробничому чи іншому), ви можете з упевненістю сказати, що проблему було введено зобов'язанням, з якого вийшов цей реліз.

(Ось чому люди говорять про "відтворювані склади": тому вони можуть бути впевнені, що процес їх випуску не представляє нових помилок, яких не було в середовищі їх попереднього перегляду / інсценізації, а також якщо помилка у виробництві однакова бінарний файл працює на їх машині, коли вони переходять до його налагодження.)

Немає сенсу тегувати другий зелений комірок знизу (зелений дочірка комітету з позначкою "Тільки виправлення!") Як "v1.0", тому що ви не випустили цю команду на виробництво. Ви відпустили комісію на майстра. Ви навіть можете бачити, що потік git позначає це як "Тег 1.0".

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

Якщо у вас є проблеми з пошуку тегів у вашій галузі розробки, це зовсім окрема проблема. Зафіксуйте інструмент, який ви використовуєте для пошуку тегів. Або ще краще: не використовуйте git-flow. Це добре виглядає на цій діаграмі через прекрасні кольорові крапки та красиво викладені лінії, але насправді це схоже на божевільну безладну павутину кольорових ліній та крапок.