Simple Modified Gitflow Workflow

General News

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.

  • Master/Main: Always the latest live branch containing the production code. When the Develop branch is merged into it, the Master/Main branch will be tagged with the latest release version number. 
  • Develop: The Develop branch is a one-time branch off of Master/Main and contains the complete history of the project. All features will be merged into into this branch and when reviewed will make their way to the Master/Main branch.

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.

  • Hotfix: This is a branch created directly off of the Master/Main branch and should only be used if you need to quickly patch production releases. Having a branch for critical bug fixes allows you to address serious issues without having to wait for the next feature release or interfering with ongoing development. Hotfixes are not the norm and should be an exceptional case. When ready, hotfixes will be merged onto both Master/Main and Develop branches. 
  • Feature: Each new feature will reside in its own branch created off of the Develop branch. A new feature branch can also be created for non-critical bugs in released code that can wait until the next planned release. If possible, feature branches should not be very long-lived. Once ready for code review, a merge/pull request should be made to merge your commits into the Development branch.

Conclusion

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

Share It!

Story Options

  • Simple Modified Gitflow Workflow
  • 1 comments
I arrived at this post because I'm starting a new project with a new team. And when I suggested we use the Gitflow method, the other senior developer threw a dizzy fiit about how awful Gitflow is, how it overcomplicates everything, etc. And I was like, huh? In my previous job we used Gitflow, and it worked *just fine*.

So, in the interest of intellectual honesty, I went and did a search on "Why is Gitflow bad". I found a few articles on the topic, but when i dived in, I thought, "Yeah, *this* Gitflow that you're criticizing really *is* terrible. But that's not the way *I* did Gitflow in the past." I never saw a need for both "develop" and "release" branches. In my case, we used "release" branches instead of "develop", because sometimes we needed to have more than one release in development at a time. But it's the same idea.

IMO, this is a perfectly good flow, and it answers all the criticisms of Gitflow that I've seen out there.