Gitflow: The Art of Branch Management

Introduction!

While working on a project, I faced challenges related to workflow management and effective version control. I conducted research and found some workflows on Atlassian’s official website. They mentioned three workflows, and now I’m sharing simplified articles about them

what is gitflow workflow?

Gitflow is an alternative git branching model. it has numerous, longer-lived branches and larger commits. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. Gitflow can be used for projects with a scheduled release cycle and for the DevOps best practice of continuous delivery. This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns particular roles to different branches and defines how and when they should interact.

How does it work?

Minimize image

Edit image

Delete image

Gitflow diagram

instead of many branches, this workflow uses 2 branches to maintain the whole project history

Main Branch

*main branch holds release history and it’s a more stable branch.

Develop branch

*develop branch serves as an integration branch for features. It’s also convenient to tag all commits in the main branch with a version number.

we have two option go with manually maintain or use gitflow extension

step 1 :

create main branch and develop branch

without gitflow extension:

$ git branch develop
$ git push -u origin develop

or use gitflow extension:

library .execute “git flow init” on an existing repo will create the develop branch:

$ git flow init 

Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch * develop main

Feature branch

each feature should create its own branch from the develop branch. after finishing it should merge back into develop branch. feature branch should never directly interact with main branch.

if any changes happen in develop branch take pull

creating feature branch

without gitflow extension:

$ git checkout develop
$ git checkout -b feature_branch

or use gitflow extension:

$ git flow feature start feature_branch

finishing feature

when done feature , the next step is merge feature branch into develop branch

without gitflow extension:

$ git checkout develop
$ git merge feature_branch

using gitflow extension:

$ git flow feature finish feature_branch

Release branch

Once it’s ready to ship, the release branch gets merged into main and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release. It also creates well-defined phases of development (e.g., it’s easy to say, “This week we’re preparing for version 4.0,” and to actually see it in the structure of the repository).

without gitflow extension :

$ git checkout develop
$ git checkout -b release/0.1.0

using gitflow extension

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

after last time bugfixes

without gitflow extension :

$ git checkout main
$ git merge release/0.1.0

using extension :

$ git flow release finish '0.1.0'

Hotfix branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they’re based on main instead of develop. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into both main and develop (or the current release branch), and main should be tagged with an updated version number.

without gitflow extension :

$ git checkout main
$ git checkout -b hotfix_branch

using gitflow extension :

$ git flow hotfix start hotfix_branch

Similar to finishing a release branch, a hotfix branch gets merged into both main and develop.

without gitflow extension :

$ git checkout main
$ git merge hotfix_branch 
$ git checkout develop 
$ git merge hotfix_branch 
$git branch -D hotfix_branch

using gitflow extension :

$ git flow hotfix finish hotfix_branch

Some key takeaways to know about Gitflow are:

• The workflow is great for a release-based software workflow.
• Gitflow offers a dedicated channel for hotfixes to production.

The overall flow of Gitflow is:

1. A develop branch is created from main

2. A release branch is created from develop

3. Feature branches are created from develop

4. When a feature is complete it is merged into the develop branch

5. When the release branch is done it is merged into develop and main

6. If an issue in main is detected a hotfix branch is created from main

7. Once the hotfix is complete it is merged to both develop and main