Первый крупный релиз от git

Question

Я только что выпустил V1.0.0 продукта из git, и мне интересно, какой сейчас рекомендуемый совет.

Создать ветку v1.0.0 или аннотированный тег v1.0.0, лучшая альтернатива?

Мне кажется, что тег подходит мне правильно, но я не уверен в процессе ветвления и объединения из тега.

Answer 1

Фраза catch была выражена в StackOverflow в другом месте:

Ветви для работы, теги для релизов.

Ваша основная ветка (обычно главная) должна бытьпродолжаем дальнейшую разработку для следующего выпуска.Каждый раз, когда выпускается релиз, используйте тег (как минимум, аннотированный), чтобы отметить событие.

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

git checkout -b <tag>-maintenance <tag>

Это создаст новую ветку для ваших работ по техническому обслуживанию.Вы будете следовать тому же процессу в ветви обслуживания, отметив выпуск в ветви обслуживания, когда закончите с выпуском обслуживания.

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

Answer 2

С git вы можете создавать ветки в любое время! Я бы сделал следующее:

1. Создать тег 'v1.0.0'
2. Когда мне нужно добавить исправление к версии 1.0.0, я бы создал ветку 'v1.0.0-maintenance' на основе моего тега.
3. Если вы хотите применить исправление к текущей версии, объедините 'v1.0.0-maintenance' с 'master' или используйте cherry-pick

Answer 3

Аннотированный тег - это, вероятно, первое, что вы должны сделать.

Оттуда у вас есть несколько вариантов для вашего рабочего процесса: вот два наиболее распространенных варианта.

Вы можете перемещатьв стиле «только вперед», где серия 1.0 больше не поддерживается (1);Вы можете сделать «только поддержку» в серии 1.0, и все новые функции будут добавлены в серии 2.0 (или заменить 1.0.1 и 1.1, оставив 2.0 для полного переписывания - номера версий не так уж важны) (2).

Сценарий 2 определенно является более «профессиональным» вариантом, но если это небольшой проект с узкой областью действия, сценарий 1 в порядке.

В сценарии 1 вы можете выполнить все своиработать в основной ветке, или делать ветви функций, сливаясь с мастерской, когда будете готовы.Если у вас есть новый выпуск, просто пометьте его как 1.1 или 1.0.1 или как угодно.

В Сценарии 2 вы можете использовать свою основную ветку, чтобы отразить новейшую версию, ветку «поддержки», чтобы отразить вашу поддержку.выпуск, «промежуточная» ветвь на стадию и тестирование новых функций, которые в конечном итоге будут объединены в мастер, и вы можете использовать ветки функций для разработки новых функций или исправления ошибок.И по мере развертывания исправлений ошибок, вы объедините ветку поддержки обратно в master.Когда вы выпускаете либо новую версию, либо версию поддержки, просто используйте аннотированный тег снова.

Лично я обычно поддерживаю ветку master-staging-support с тегами, а не ветку длякаждый версионный выпуск;но это замечательная вещь в git - вы можете делать это так, как считаете нужным!Поэтому, конечно, два варианта, которые я представил, ни в коем случае не являются единственными вариантами, которые у вас есть для вашего рабочего процесса разработки.

Answer 4

Зависит, но я предполагаю, что вы захотите продолжить исправление v.1.0.0 довольно скоро, также работая над следующей версией.

Я бы сразу создал ветку.Весьма маловероятно, что вам это не понадобится (только в том случае, если вам никогда не понадобится создавать v1.0.1).

Конечно, вы также можете пометить его (никогда не повредит), а затем создать ветку на основена этом теге.Вы можете создать ветку из тега просто с помощью

git checkout -b 1.0.0 v1.0.0