0

Git flow recommends to have separate branches .i.e.

main/master --> production deployable code

Development branch gets created from main/master --> active development branch (integration branch)

feature branch ---> Multiple Feature branch gets created from development branch

My question is basically, why I need to keep main Branch in above flow (or any other branch hotfix, released etc ) what benefit it gives ? can't I just used tags .i.e.

If i have only two branches .i.e.

Development --> active integration

feature branch --> got created from Development branch

Developers works on feature branch merge code back to development at a particular point (commit) they made development stable for a particular version, we put a released versioned tag on that commit id (which is basically production deployable ) ,

Developers start continues on next version getting feature branch created from head of development branch.

If there is a hotfix requirement, we create branch from released tag fix code and merge it back to development put a new versioned tag. ( whereas if we had master we would needed to merge code back to master as well)

As far as Continuous delivery, is concerned the artifacts created from released tag on development branch would be promoted to different environment test cycles (qa, stating prod)

So basically my question is what benefits different branches provide in comparison to putting releasable tags.

one cosmetic benefit I could think of is that, if you have master branch and you run git tags in that branch you will get all your production deployed releasable tags.

Whereas if you are using only development branch then you will get both pre-release and released tags.

Other then that any other major benefit of having branches like main , hotfix ... etc. can't that workflow be handled via tags ?

3

It's best not to use git flow for a project where you aspire to continuous delivery.

As Vincent Driessen, the originator of Git Flow writes:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

I would suggest instead trying some form of Trunk Based Development.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.