Using tags instead of different branches

Question

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 ?

Answer 1

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.

Answer 2

The reason to still have a "main" or "master" branch is not because the names are special. Git is configured with a "default" branch. Typically this is "main" or "master". The default branch is what gets checked out after a git clone operation. Other Git commands operate on the default branch if no other branch, tag or commit is specified (think git branch X versus git branch X development).

Recent versions of Git allow you to configure the default branch. Maybe you just need to switch the default branch to "development"? I would caution you against doing this, however, since it is unexpected by most people. Instead, I would challenge you to rethink whether a "development" branch is necessary at all. I would recommend using "main" or "master" as your development branch, in which case this question is moot.

Merge feature branches into the default branch in Git. When your team identifies a stable commit to represent a release, tag that commit.

In other Git workflows, a "development" branch exists because it is desirable to separate "work in progress" from "stable" (and possibly "released to production"). This gives your team a place to integrate work before deployment, which is one of the goals of Git Flow. If this separation is not desirable for your team, then there is no benefit to having a separate "work in progress" branch from your "stable" branch.

The "main" or "master" branch is your integration branch. There is nothing wrong with this. Get rid of the "development" branch, not main or master. Tag your releases like you normally do. If you need to apply a hotfix, create a new branch from the tag to represent your patch to production. Fix, merge, tag, and deploy. Just be sure to merge your hotfix branch back into master.