Стратегия Git Braching / Merging: выпуск + исправление веток, в чем смысл мастера
Я работаю над стратегией ветвления / слияния на основе git, которая будет удовлетворять потребности моей организации: Я сослался на GitFlow (ссылка: https://datasift.github.io/gitflow/IntroductionGitFlow.html)
и начал приспосабливать к нему различные сценарии. Все это хорошо для нормальной разработки с использованием веток функций и выпусков с использованием веток выпуска. Однако, когда дело доходит до исправлений, все усложняется. На разных клиентах развернуто несколько разных версий нашего продукта, и нам нужно иметь возможность развертывать исправления для всех клиентов. Я считаю, что GitFlow предполагает, что в производственной среде развернута только последняя версия продукта, и стратегия обслуживает этот сценарий, создавая теги в основной ветке для каждого выпуска. Если требуется исправление, новая ветвь исправления может быть создана из последнего тега из мастера, и изменения будут объединены обратно в мастер, развиваться и продолжаться оттуда. Однако в моем случае мне может потребоваться развернуть исправление для версии, которая на несколько выпусков отстает от основной, и я не могу просто объединить ее обратно в мастер. Мне нужно объединить его с исходной веткой выпуска и веткой разработки. Я должен отслеживать все ветки выпуска и соответствующим образом редактировать их.
Мне интересно, есть ли изящное решение этой ситуации. Более того, поскольку я больше не беру ветку исправления из тега на master и снова сливаю с master, какой смысл иметь как разработку, так и основную ветку? Мне не нужна ветка разработки. Ветки функций можно было напрямую объединить в мастер, и во время выпуска я мог создать ветку выпуска из мастера и, когда он был готов, могу объединить ее обратно в мастер. Какие-либо предложения?
Ответ:
Как и упомянутый здесь, Gitflow идеально подходит для проектов, у которых есть запланированный цикл выпуска.
Develop and Master Branches
Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number.
Так:
I have to merge it back to the original release branch and develop branch. I have to keep track of all the release branches and version them appropriately.
I am wondering if there is an elegant solution to this situation
Не совсем: обратный перенос исправления необходимо оценивать для каждого выпуска (некоторые выпуски могут не нуждаться в исправлении)
Но вам не нужно объединять его с веткой разработки (если исправление все еще актуально для следующего выпуска), только с веткой выпуска.
what's the point of having both a develop and a master branch? I don't need the develop branch
master записывает каждый новый выпуск (и все его коммиты представляют новый выпуск).
Из каждого выпуска может быть создана ветка выпуска для размещения любой эволюции (например, нового исправления с обратным переносом).