Skip to content

Latest commit

 

History

History
64 lines (39 loc) · 2.35 KB

branching-strategy.md

File metadata and controls

64 lines (39 loc) · 2.35 KB

< devops-project-template

Branching strategy

Branching strategy defines how different new features are developed in parallel and integrated into a new release.

Clone this repo and document your branching strategy here:



Content

De industry standard for collaborative coding and revision control is GIT. Integration with GIT is done using merge requests into branches. GIT branching strategy should match life-cycle-, test- and deployment strategy.

In general:

  • Production code is stored in a permanent branch
  • New features or fixes are developed in temporary feature branches
  • Feature branches are merged back into the production branch when ready
  • Merging is done using merge-requests which incorporate code review by another developer

See:

Tips and hints

  • Keep features and merge request small, avoid merge hell

  • Start with trunk-based development and switch to a GitFlow when the product can be built in feature increments or when the project is crowdsourced

GitFlow

Complex, only needed when multiple concurrent releases must be supported.

GitLabFlow

Flexible, can be as simple as Github-flow or as complex as Git-flow.

GitHubFlow

Simple, release always tight to the permanent master-branch.

Trunk-based

Trunk-based development (TBD) is a branching strategy that in fact requires no branches but instead, developers integrate their changes into a shared trunk at least once a day. This shared trunk should be ready for release anytime. This can be done with a feature flag or user ring based delivery strategy to keep the new trunks isolated in production.

Good choice for the initial stages of the project when changes in functionality and volatility of solutions make GitFlow's unpractical.