An Overview of Some Git Branching Models

Git is a wonderful tool. But like all tools, it require methods to be used correctly. We will cover in this article some git branching model I have encountered during my career.

Trunk Only Development

Used either by student who don’t know what they are doing or by skilled and mature team as an extreme interpretation of “Trunk Based Development”.

Trunk only development

Pros:
– Real time integration.
– Makes developers aware of their responsibilities: If you break something, everyone is impacted.

Cons:
– When a commit break something, everyone is impacted…
– Don’t forget to pull before pushing.
– Quickly becomes a real mess if your team is not mature enough. Even if history stay linear, your product will be broken several times a day and developers will spend lot of time fixing conflict.

One branch per developer

If you don’t know what to do, take this one. Simple to explain, very well adapted to Github’s Pull Request or Gitlab’s Merge Request paradigm, and ensure some stability even with beginners team.

Developer branch

Pros:
– Master branch always works.
– No integration dependency. Each developer is responsible of its own branch.

Cons:
– Isolate developer on its own task.
– No validation of branches together.
– Require well dimensioned test infrastructure. May not be possible for embedded development or heavy legacy software.

One branch per feature

Similar to the one before, but enforce collaboration between developers. For me, the best trade off between having real time integration and having a stable Master branch.

Feature branch

Pros:
– Master branch always work.
– No integration dependency.
– Several developers can work on the same feature.

Cons:
– No validation of branches together.
– Require good collaboration between developers.
– Require well dimensioned test infrastructure. May not be possible for embedded development or heavy legacy software.

Trunk Based Development

This one seems to be the most fashionable model today. Warning, “Trunk Based Development” is not “Trunk Only Development”. Developers can work both on master branch for small fixes or on feature branches for more complex development, as long as feature branches have a short lifetime. You can take a look to this article to have more details about this model.

Trunk based development

Pros:
– Benefit of real time integration and longer term development
– Empower collaboration and accountability.

Cons:
– Master can be broken
– High and variable pressure on test system => Require a dynamic scalable infrastructure.
– Risk of drifting to Trunk Only Development by laziness.

Nightly integration test

Developer merge their branch in a “Nightly test branch”. Test are executed nightly and result are available in the morning. If you don’t have a very exotic test system with strong constrains that prevent you doing real continuous integration, please don’t do this.

Nightly integration branch

Pros:
– Branch are validated together.
– Load is constant on test infrastructure.
– Can handle complex test system or very long tests.

Cons:
– Have to wait the next day to have results.
– If test infrastructure crash during the night, have to wait another day.
– When test fail, have to investigate which branch is responsible.

Gitflow

Gitflow has a little success back in the 2015’s, especially with the git-flow CLI tool. It is today more and more criticized for its complexity and the latency it introduced in integration. What I personally think about Gitflow can be summarized by:

Just because you are doing something complicated doesn’t mean you are doing something smart.

Gitflow

Pro:
– Explicitly handle all the case than can occurs during product life time: Feature development, stabilization, code freeze, last minute hotfixes.
– Each branches are tested before integration and common result is tested before release.

Cons:
– Complicated to explain for people who are not familiar with Git.
– Lot of branches, lot of complexity, lot of mistakes.
– Going from feature to master takes times, slowing down continuous integration.

Guitar hero world tour

Guitar hero branching model

Pro:
– Very good with friends

Cons:
– Is not a branching model

Home


Similar topics

One response to “An Overview of Some Git Branching Models”

  1. How to Work Efficiently With Git ? – KissYagni Avatar

    […] workflow is well adapted to Trunk based development, but can also be used for any git branching models. The most important points […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s