What is Gitflow and Why Should You Know About It?

The Problem

Since we often work with Git, it is safe to assume that most people are familiar with Git concepts such as branches and commands like checkout, merge, rebase, and revert.

When developing a new feature, we usually checkout from the current branch to another branch to work on it. In a team environment, multiple people may be developing multiple features, each on their own branch, allowing for independent and parallel development. Everything would be perfect if one day, when merging branches together, there were no conflicts.

Gitflow was created to define rules for branching and feature development, as well as product releases. It is a workflow for working with Git that is most convenient for developers.

What is Gitflow?

Gitflow is a concept that defines branching and coordination for developing and releasing features using Git.

Gitflow can be customized by development teams based on their environment and requirements. It can be either created from scratch or based on an existing workflow.

There are many variations of Gitflow, but the most famous one is based on Vincent Driessen's branching model.

Gitflow based on Vincent Driessen's Branching Model

In Vincent Driessen's Gitflow, the workflow is as follows:

• The starting branch is master. When starting development of a new feature, we checkout from master to develop.
• Each feature is then checked out from develop to branches with the prefix feature/feature-name. For example, a login feature would be feature/login, and a logout feature would be feature/logout. Each feature is developed independently. After completion, the feature branch is merged into develop.
• During the release cycle, develop is merged into release. The release branch acts as a staging environment for the project. It closely resembles the production environment and only includes bug fixes, not new features. If any bug fixes are needed on the release branch, they are merged back into develop.
• When all bugs are fixed, the release branch is merged into master. A tag can be added to mark the release for convenient tracking and tracing.
• In production, bugs are unavoidable. In such cases, we checkout from master to a hotfix/fix-name branch to fix the bug. After fixing the bug, the hotfix branch is merged into develop. Once the fix is verified in develop, it is merged into master, effectively ending the bug fix session.

As you can see, with this Gitflow model, we need at least three environments for running code: production, staging, and develop, corresponding to the master, release, and develop branches, respectively. However, in practice, it is not necessary to have all three environments. We can customize Gitflow to suit our project's needs and optimize it for efficiency.

The Gitflow based on Vincent Driessen's model can be complex and may slow down the development process or result in a high number of code conflicts. However, it provides clear and distinct branches, and it is easy to establish multiple environments (develop, staging, production).

For example, we can have just the develop and production environments but still ensure that feature development branches are checked out from develop and merged into master before going into production.

Apart from the flows mentioned above, there are other Gitflows as well. In fact, both GitHub and Gitlab have proposed Gitflows for working on their platforms. If time allows, I will write another article discussing the Gitflows proposed by these two industry giants.

Conclusion

In this article, I have presented the concept of Gitflow along with the Gitflow model based on Vincent Driessen's branching diagram. Gitflow was created to address the challenges of working in teams by providing a convenient and conflict-free workflow. Gitflow is also a characteristic of a software development team. If you are using any Gitflow, feel free to share it with others!