Git strategies, which one to pick?

Working with multiple people on the same codebase requires a good process related to Version Control. Although you will probably use git to store your code, the process of keeping track of versions is not purely technical. Team members should agree upon how to organize the code in branches, how to merge new changes and how to roll out changes with Continuous Integration and Continuous Delivery (CICD) automatically based on the structure of the repository.

Why I started looking for git strategies

Most of my past projects, in which I had to collaborate, already had a git strategy in place. Some worked, some did not. One of the projects in this last category needed an update to facilitate CICD. Moving over to automatic deployments removed a lot of manual time consuming work and especially gave the developers peace of mind since it lowered the chance of errors when deploying changes in the project. The git strategy for this project was not optimal, this is why I started investigating which strategies are out there and which ones were accepted as the way to go nowadays.

The search

Version control has been around for decades already, but it turned out that numerous strategies have emerged. A couple if them were accepted as the standard approach for a long time, but some just were not suitable for small teams and with emerging needs for faster deployments newer approaches have been chosen as it better facilitates this need.
Below I will discuss the following strategies:

• Gitflow
• Trunk-based workflow
• GitHub flow

Gitflow workflow

This workflow was one of the most popular git branching models. It was popularized by Vincent Driessen in 2010. In his original blog post he explains how the concept works, but has updated it with an explanation that the approach might have become outdated due to the emerge of CICD and thus suggests teams looking into more simpler workflows, such as GitHub Flow.

Driessen’s approach to branching relies on strictly separating the codebase over multiple deployment environments. This workflow has two central branches, namely ‘develop’ and the main branch. Adding a new feature requires the developer to branch of the development branch into a new feature branch. This feature branch can be long lived and multiple people can work on it at the same time. Once a feature is ready, the branch should be merged back into the develop branch.

The approach works with releases, which means that once the team thinks the application is ready to be published the code is released to a release branch to test everything. Once the code is there only bug fixes may be applied. Once the code has passed all the tests the release branch can be merged into the main branch and can be tagged with a version number to bring it to production. Once in production, no changes other than hotfixes (done in a separate branch) may be applied.

My take on the Gitflow workflow

Make use of it when building large applications that need to be versioned. I can imagine that, for example, large applications running on on-premise systems which are not updated constantly could be a suited use case. I feel that this branching and releasing strategy goes against Agile development principles, in which short cycles of new features are at the core, and thus crosses out its use in many teams.

Trunk-based workflow

This is an approach in which new code is created in short lived branches and then merged directly into the main branch (a.k.a. the trunk). CICD makes sure that the code passes tests, code is built and eventually deployed automatically.

The idea is that with this approach a team can roll out changes quickly and in small increments. Compared to the Gitflow workflow, this branch has less overhead in the process and therefore offers more flexibility.

Small teams can even decide to fully omit feature branches and as a result only start committing directly onto the main branch.

My take on the Trunk-based workflow:

In cases in which speed is key, I would go for this workflow, making collaboration easy and releases in short cycles. With automation with CICD at it's core forces the team to be mindful about the changes they publish and removes error prone manual steps from the process. This strategy, however, does not support a deployment to different environments that test the code, which might make it less suitable for applications that need proper user acceptance testing.

GitHub flow

Named after the popular version control platform GitHub, the GitHub workflow focuses on a lightweight process, in which collaboration and clarity are highlighted. In their process they give general good advice to give branches, commits and pull requests good descriptions. This advice includes including a link to an issue on an issue board related to the change, including images and overall being clear to your collaborators why and how you did a change. Branches should contain only changes that are related to each other, and should be deleted after it's merged into the main branch.

A main differentiator of this workflow is the use of GitHub's collaborative features, such as it's Pull Request feature, in which code can easily be peer-reviewed by fellow colleagues.

My take on GitHub flow

GitHub flow essentially is a Trunk-based workflow, in which short-lived branches are merged into a main branch. The description of GitHub flow on GitHub's site is concise and feels like it is targeted towards people new to version control systems.