Решение, которое я предпочитаю, выглядит следующим образом.
master -> release1
master будет иметь свое дальнейшее развитие,
предположим, что в ветке release1
возникнет какая-то ошибка нужно создать ветку hotfix
из ветви release1
и после исправления ошибки в ветке hotfix
просто объединить ее с веткой release1
и перебазировать hotfix
с веткой master
, чтобы сохранить историю, после того как перебазировать с помощью master
слияние веток hotfix
в ветке master
, поэтому исправление ошибок будет происходить как в master
, так и в release1
ветке
Теперь предположим, что пришло время иметь release2
, вам просто нужно создать ветку release2
из ветви master
, поскольку все ошибки уже исправлены в основной ветке, а все новые разработки находятся в ветви master
.
Master
commit1
commit2 -> release1
commit3
commit4
git checkout release1
git checkout -b hotfix
Hotfix
commit2
bugfix1
Исправление слияния с выпуском 1 станет
git checkout release1
git merge hotfix
Release1
Commit1
commit2
butfix1
Перебазировать исправление с мастером, оно перезапишет вашу историю
git checkout hotfix
git rebase master
Hotfix
commit1
commit2
commit3
commit4
bugfix1
после того, как ветвь слияния слияния с главной веткой
git checkout master
git merge hotfix
Master
commit1
commit2
commit3
commit4
bugfix1
git branch -d hotfix
git push -d origin hotfix
не забыли удалить hotfix
, потому что мы уже сделал с этой веткой там больше нет требования этой ветви после слияния. Вы также можете изменить имена веток исправлений на идентификатор билета jira или идентификатор ошибки, если они где-то зарегистрированы.
теперь создаем release2 из мастера, в котором уже исправлена ошибка.