Virtually every team uses git to manage their code base, but there is much less uniformity in how version control is used. How much code should one write before adding it to a branch? When should branches be created? When should they be merged? How much should be on a branch? How many branches should we have at any one time?
Like with much else in programming there is no one right way to answer these questions, but two main practices have become popular strategies to tackle them. GitFlow and Trunk Based Development have opposing views on how to tackle versioning your project, but both are widely used in industry.
GitFlow
The idea behind GitFlow is that each commit to the Master branch represents a complete version of the software (e.g. 2.2). GitFlow has two main branches, Development and Master. Master is, obviously, the “live” or production branch – this doesn’t change across version control strategies. The development branch is the version or development branch and is the only branch of the main two that should have features or new things added to it. The development branch has smaller branches for each feature planned that the development team schedules and divides amongst themselves. Once features are complete they’re merged into the release branch. The release branch is tested all as features come in, and once all features are in any bugs detected are fixed and those fixes are applied to the development branch. There may need to be multiple rounds of bug fixes and reworks, but once all of this has been tested and fixed, the development branch is merged with the Master branch for a complete version.
Benefits
- Clear delineation for versions (2.2 vs 2.3)
- Rollbacks are very easy
- Easy for multiple versions to exist in marketplace
- More widely used in industry
- More overlap with manufacturing methods – easier for non-software people to work with
Drawbacks
- Long time between deployments means slower bug response
- Physically long deployments – merges and commits take some time to process
- Large code bases for each deployment means bugs can be more difficult to track down and troubleshoot
Trunk Based Development
The idea behind Trunk Based Development is that deployments should be early and often. There are only two components of a Trunk Based tree: the Master branch, or Trunk, and feature branches. Instead of doing a branch with sub-branches for larger features, the larger feature is broken up into separate subcomponents that are themselves treated as the features. The idea is to never have more than two levels of branching, and to merge feature branches back into the Master branch as soon as they’ve passed testing.
Benefits
- Deployment cycles are much faster
- Deployment itself is much faster due to fewer possible merge conflicts
- Continuous improvement can be more easily practiced
- Deployments and changes less disruptive for users
- User-discovered errors can be patched/fixed quickly as part of normal cycle
Drawbacks
- Does not work well for products that are not connected to the internet
- Lack of real rollback ability
- Bugs are more likely to slip through into production
TL;DR
GitFlow works well for products that should have specific, distinct versions that can be active in the marketplace simultaneously. If your product is intended to be all the same version and you don’t anticipate rolling back or having multiple active versions out, then Trunk Based Development is a better choice.
