And the Oscar for the best git workflow goes to…

Does your git branches look like this?

None of them. Or, better, all of them. But, before explaining this statement, let’s introduce the topic.

Why we should care about git workflows

Git is a distributed version control system created by Linus Torvalds in 2005. It is widely used among programmers (but not only them) because it makes easier for them to track changes in their code and to collaborate with the others.

But like every powerful tool, you must be sure to use it appropriately. And by “appropriately” I mean that how you use your tool should depend on what you need.

So, by “git workflow” I mean a set of rules and practices that are shared between the people that are working together in order to:

• improve the reliability of the code
• reduce the time waste due to a bad communication

During these 17 years, a lot of things have changed in the world of software development. That’s why software development teams have to change the way they use git in order to meet their needs.

The nominees are…

These are the most popular (but not the only ones) git workflows so far:

Git Flow

Git Flow was introduced in 2010 by Vincent Driessen. It relies on 5 types of branches:

• develop: the develop branch is the one from where you should start working
• feature/*: the feature branch is where you should implement the new feature (of course). It is always branched of the develop branch and it should merged back into develop
• release/*: the release branch support preparation of a new production release. So, when all of the new features are back into the develop branch you should branch off develop and perform your integration tests. When everything is good, you should merge into the main branch and back into the develop branch (if, for example, you had to perform some commits to fix something)
• main: the main branch (previously called master) is where the code reflects the production-ready state. This is the branch where you create your tags that are deployed in production
• hotfix/*: this branch is much like the release branch except for the fact that you need this when you must resolve a bug in production. So you should branch off the tag that is in production, fix the bug and then merge back both in the main and in the develop branch (so that the future feature branches have the bug fixed).

When you should use this workflow?

Git Flow helps your team having a clean state of branches and of the overall state of your repository. It also helps if you need to simply rollback to a previous version of your production code.

When you should not use this workflow?

Git Flow was created before all of the CI/CD stuff. So maybe it’s a little too complex for this purpose.

Github Flow

The Github Flow was created by Github in 2011. It is more simple than the Git Flow approach. In fact it relies on the rule that anything in the main branch is deployable. When you need to implement a new feature:

• create a feature branch off from main
• when the development is over, merge back into main via a Pull Request
• when the merge is completed, you should deploy to production

When you should use this workflow?

Github Flow is designed to implement CI/CD pipelines and it is much simpler than Git Flow.

When you should not use this workflow?

With this workflow it is easier to introduce bugs in production. So if you need to have a stable state in production (well of course everybody wants this), this may not be the right choice.

GitLab Flow

GitLab Flow was created by GitLab in 2014. It looks similar to Github Flow, but you can add some environment branches like production and pre-production . It is based on 11 rules that tell you exactly how you should implement your workflow and your CI/CD.

When you should use this workflow?

GitLab Flow has clear rules that define how you should implement all the steps of your process, including the CI/CD pipelines.

When you should not use this workflow?

This workflow is more complex than Github Flow and it could become as complex Git Flow. So it could be hard not to over-complicate it.

Who is the winner then?

In Flowe, every team has the power to decide which is the best flow to develop and ship the code to production. And this explains why at the beginning I said that each workflow deserves an Oscar: the team should decide which workflow is the best for its development cycle.

But how do we know which one is the best for our team? Here is what we did:

• we started with a custom workflow based on feature branches, main branch (not yet deployable) and release branches
• we had some bottlenecks using this workflow and we started switching to Git Flow because it looks that it could resolve our issues
• we improved our collaboration and communication with this workflow. We also reduced merge conflicts and the releases were much more smooth
• we’ll continue to use this workflow until we feel good with it

Takeaways

I’d like to conclude with a quote of Vincent Driessen:

Always remember that panaceas don’t exist. Consider your own context. Don’t be hating. Decide for yourself.

So, choose the workflow that better fits with your development cycle. We follow this principle for everything we do and, so far, we are very happy!

If you like what we do and how we approach new problems and challenges, check out Flowe’s website and all the open positions!

FLOWE — Pay better, be better

References

• Patrick Porto: “4 branching workflows for git”
• Vincent Driessen: “A successful Git branching model”
• Scott Chacon: “GitHub Flow”
• GitLab: “Introduction to GitLab Flow”