Branching Models

Branching Models

There are two popular branching models that we see customers typically use in their organization. One is Trunk-based and other is Feature-based or “GitFlow” model.

Trunk-based development

In Trunk-based model, developers collaborate on code in a single branch called “trunk” resisting any pressure to create other long-lived development branches by employing documented techniques. This leads to avoiding merging complexity and hence effort. At Amazon, we strongly encourage our teams to practice Continuous Integration via Trunk-based development where developers merge their changes several times a day into a central repository.

Feature-based aka GitFlow development

So why do teams use Feature-based model? There are several reasons why:

  • Not many teams have achieved CI/CD nirvana
  • Multiple teams may be working on different feature releases with different launch timelines
  • Organizations that provide SAAS (Software As-A Service) may have customers who do not wish to be on the “latest” version at all times, and thus forcing them to create multiple “Release” and “Hotfix” branches
  • Certain teams within an Organization may have specific QA/UAT requirements that require manual approvals, that may delay the time since a new feature is introduced until it’s released to production

We developed this workshop considering above, and also our customers have asked us for information that would help them use our tools to automate merge and release tasks.

GitFlow

GitFlow involves creating multiple levels of branching off of master where changes to feature branches are only periodically merged all the way back to master to trigger a release.

  • Master always and exclusively contains production code

  • Develop is the basis for any new development efforts you make.

These two branches are so-called long-running branches: they remain in your project during its whole lifetime. Other branches, e.g. for features or releases, only exist temporarily: they are created on demand and are deleted after they’ve fulfilled their purpose.

GitFlow guidelines:

  • Use development as a continuous integration branch.
  • Use feature branches to work on multiple features.
  • Use release branches to work on a particular release (multiple features).
  • Use hotfix branches off of master to push a hotfix.
  • Merge to master after every release.
  • Master contains production-ready code.

gitbranch

For more details, please see Vincent Driessen’s branching model

With that, let’s Start the Workshop…