Gitflow зачем нам мастер

Question

в gitflow все ветки релиза в конечном итоге

1. слияние с мастером
2. слияние для разработки
3. мастер тегов
4. удаление ветки релиза

но почему бы нам не просто

1. пометить ветку релиза
2. объединить для разработки
3. удалить ветку релиза

в случае исправления мы можем просто

1. ветки последнего тега
2. сделать исправление
3. тега, который исправляет ветку
4. объединить для разработки
5. удалить ветку исправлений

Answer 1

По основной причине, по которой ветка master необходима (ветку develop нельзя заменить) в gitflow:

• Все версии на ветке master должны быть достаточно стабильными, посколькуиспользуется для среды продукта.
• В то время как для веток develop все разработчики могут выполнять свою работу напрямую, даже без проверок.Это означает, что ветвь develop может быть "грязной", что приведет к разрушению производственной / жилой среды.

Answer 2

Вы почти описываете модель ветвления потока выпуска:

• Разработчики объединяются с общей ветвью магистрали (назовите ее разработкой или мастером)
• Когда вы готовы выпустить веткуиз основной линии (назовите это release / r-1.2 и т. д.)
• Когда вы обнаружите проблему с новым выпуском, создайте ветку исправлений (hotfix / fix -thing)
• Объедините ваше исправление с основной веткойкак и обычный dev
• Merge / cherry выбирает исправление в ветку релиза
• Ветвь релиза представляет рабочую версию при развертывании в этой среде

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

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

Это хорошо задокументировано командой VSTS: https://docs.microsoft.com/en-gb/azure/devops/devops-at-microsoft/release-flow

Answer 3

Позвольте мне попытаться изложить здесь свое понимание,

Соглашение о присвоении имен ветвям git master, develop & release было хорошо определено и принято для универсальной синхронизации.Это не означает, что вам нужно следовать, вы можете определить, как вы хотите, и подтолкнуть своих клиентов и пользователей. Многие организации следуют универсальным соглашениям об именах, чтобы избежать ненужной путаницы.

В Mercurial Многие следуют за именами ветвей default вместо master.

Определение в одной строке:

master  : Ready Product (Public Available)

develop : Requirements/bugs/Improvements Implementation In Progress (Not recommended to use)

release : Preparing to `Ready Product` (Private or internal)

tag master : Stable Product with defined features.

Вы можете сослаться Это Это Это для получения дополнительной информации