Git is a wonderful tool. But like all tools, it require methods to be used correctly. This article will cover some git branching model I have encountered in 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”.
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.
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.
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.
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.
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.
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
Pro:
– Very good with friends
Cons:
– Is not a branching model
Top comments (0)