Gitflow Workflow

Let’s take a closer look at the Gitflow Workflow, which was first outlined in Vincent Driessen’s A successful Git branching model.

This workflow consists of five types of branches, each with different roles:

• Main
• Feature
• Release
• Hotfix
• Develop

We’ll go into each in more detail.

Main

The main branch represents the production-ready code. It should only contain stable, bug-free code. Upon making the first commit in a repository, Git will automatically create a main branch by default. Subsequent commits will go under the main branch until you decide to create and switch over to another branch. The latest commit will be given a release tag when it is ready for a specific release.

Feature branch

The feature branch (sometimes called the Topic branch) is used to develop new features or enhancements. They branch off from the develop branch and are merged back when the feature is complete. When you start working on a new feature or bug fix, you should create a feature branch. A feature branch is normally created off a develop branch. This branch can reside in your local machine throughout the entire development life cycle of the feature.

You will push this branch to the remote repository whenever you are ready to merge the change set with the develop branch.

Release branch

The release branch is used for preparing a new production release. Once all features for a release have been added, this branch is merged into both main and develop branches.

A release branch helps you ensure the new features are running correctly.

By convention, start with the prefix “release-” when naming the release branch.

Team members should address only bug fixes and release-related issues on this branch. This allows other team members to continue pushing new features to the develop branch without interrupting the release workflow.

Hotfix branch

A hotfix branch is created to quickly fix critical bugs found in the production code. They branch off from the main branch and are merged back into both main and develop branches.

By convention, start with the prefix “hotfix-” when naming the hotfix branch.

The advantage of a hotfix branch is that it allows you to quickly issue a patch and merge the change with the main branch without waiting for the next release.

Develop branch

The develop branch (i.e., Integration branch) serves as the branch for ongoing development. All feature branches are merged into this branch. Your team should always keep the develop branch stable. Your team creates new branches off of this branch, and it could go live on production. Continuous integration tools such as Jenkins can do just that.

When some changes need to merge into the develop branch, creating a feature/branch to work on is generally a good idea.

The Gitflow Workflow process

In summary, this is the Gitflow workflow process:

1. A new feature starts by creating a feature branch from the develop branch.
2. Developers work on their respective feature branches, regularly merging the latest changes from the develop branch into their branches.
3. Once a feature is complete, it is merged back into the develop branch through a pull request or merge request.
4. When it's time for a release, a release branch is created from the develop branch.
5. The release branch is used for final testing, bug-fixing, and any last-minute changes.
6. Once the release is ready, it is merged into both the Master and develop branches. The Master branch is tagged with the release version.
7. If any critical bugs are found in the production code, hotfix branches are created from the Master branch, fixes are applied, and then merged back into both Master and develop branches.

The Gitflow Workflow provides clear guidelines for branching, release management, and collaboration in Git-based projects, enabling teams to work in parallel and maintain a stable production codebase.

When to choose the Gitflow Workflow

The Gitflow Workflow is best suited for projects that require a more structured and formalized approach to branching and release management. Here are some situations where choosing the Gitflow Workflow is beneficial:

• Long-term development: If you are working on a project with long-term development cycles and frequent releases, the Gitflow Workflow provides a clear separation between features, releases, and hotfixes. This helps maintain stability in the production codebase while allowing ongoing development in the develop branch.
• Parallel development: If your team needs to work on multiple features or enhancements simultaneously, the Gitflow Workflow allows for parallel development by creating separate feature branches. This enables developers to work independently without conflicting with each other's changes.
• Formal release process: If you have a formal release process that involves testing, bug fixing, and finalizing the release, the Gitflow Workflow provides a dedicated release branch. This branch allows you to thoroughly test the code, fix any bugs, and prepare the release without disrupting ongoing development.
• Hotfixes and maintenance: If your project requires regular maintenance and the ability to quickly address critical issues in the production code, the Gitflow Workflow handles hotfixes efficiently. The hotfix branches allow you to isolate and address critical bugs and merge them back into both the master and develop branches.
• Team collaboration and documentation: The Gitflow Workflow provides clear guidelines and structure for collaboration, making it easier for team members to understand how different branches are used and how changes are integrated. It also encourages good documentation practices by maintaining a clear history of merges, releases, and hotfixes.

Remember, the choice of workflow depends on the specific needs and requirements of your project. While the Gitflow Workflow offers advantages in certain scenarios, it may not be the best choice for all projects. It's important to assess your team's needs, project complexity, and development processes before deciding on a workflow strategy.

Example Git branching workflow

You will need to create a branching strategy that works best for your team, of course. But here is a quick example of how to follow a branching strategy workflow involving two types of branches: a develop/integration branch and a feature/topic branch.

Say you are working on a new feature when somebody finds a bug in the production, and you must fix that bug parallel to working on the new feature.

Before starting on the bug fix, you create a new branch off of the develop branch. This new branch isolates the bug fix from the new feature you were working on.

When ready to release the bug fix, you merge the bug fix feature branch into the develop branch.

Then you switch back to your original feature branch and continue working on the new feature.

On the feature branch, you notice that commit “X,” the bug fix commit, is needed to continue implementing the new feature. In other words, you have to synchronize your current branch with the changes on the develop branch.

There are two options to go about doing this: the first is to merge the develop branch that includes commit “X” with the current branch; the second option is to rebase the current branch to the develop branch that includes commit “X.”

For this example, you use the rebase approach.

Once you have “X” in your current working tree, you can begin safely working on the new feature again.