Simple Modified Gitflow Workflow

There are many different Git workflows out there. Gitflow has been one of the most popular for a decade now, especially for open source projects. It provides a standardized branching mechanism with a lot of flexibility. However, it is not recommended for projects that desire to maintain a single version in production. On the other end of the spectrum, GitHub flow is another popular branch-based workflow that simplifies the development workflow and is very friendly for continuous integration and continuous delivery (CI/CD). A major downside to Github flow is that features are merged directly into the Master/Main branch which greatly increases the probability of bugs or unstable code being released into production. It also may not be the best workflow for open source projects, which we at the The Grim Admin are full supporters of. Since all features are merged directly into the production branch, you need to really trust all of your developers and that can be hard at times when dealing with open source projects.

For our projects, most of the time we implement a simplified version of the Gitflow model. This modified workflow aims to be simpler in that it cuts out the release branches, which are unnecessary when maintaining a single version in production workflow. The Master/Main branch will always be the latest stable version released and tagged with an updated version number anytime the Develop branch is merged into it. Rebasing will occur if we need to streamline complex history.

How Does it Work?

As stated above, it's basically the Gitflow model without the release branches. There are two lifelong branches. The master branch stores the official release history, and the develop branch serves as an integration branch for features.

While these two branches are continuous branches that last for the life of the project, the next two branches are created and only exist until they are merged back into either the Master/Main or Develop branches.


This workflow is nice because contributors only need to worry about two types of branches: Hotfix & Feature. A detailed Git history is available on the Develop branch, while the Master/Main branch is always the latest production version ready for install or download AND is tagged so as to easily find previous release versions. This also works well for open source because of the extra layer of code review.

We'd love to hear your thoughts in the comments!

Tag: the grim admin gitflow git programming

Comments (0)

The Grim Admin