Git branching strategy

Owned by Diego Cesa de Meira (Unlicensed)
Aug 09, 2019
2 min read

 

Overview

Determine a branching strategy for our code repository that will facilitate our CI/CD goals. We could consider our current approach as a monorepo

Chosen approach

The trunk based development approach is suggested. Create feature branches off of master. Create pull requests to merge features. Create a release branch at least once a sprint to keep our staging environment as current as possible.

Branching naming convention

One of the suggestions from the azure documentation , create feature branches following the pattern features/feature-area/feature-name.

Since EGIS is essentially using a monorepo, we should label our branches to match what folder (eg. ARM, DSC, TC Smart Maps, et.) that we'll be working in.

Release branches would similarly be named releases/1.0.0, as per semantic versioning

Research and options

Feature branch

A simple approach which is the first suggestion in the Azure documentation.

https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops

Trunk based development

https://trunkbaseddevelopment.com/

According to this , trunk based development is ideal for small teams of senior developers who trust each others coding.

Fork and Pull

IMS does not permit merges on the master branch. They force developers to fork the repository and make pull requests when ready to release. This is also the approach of the RAMP2/FGPV project.

Frequently used by open-source project where many possible unknown 3rd party developers are involved. Once forked, each team can use their own branching strategy.

Questions

Should a branch be created for each PBI, or instead at the feature or task level?

Pragmatically, we should allow groups of related tasks to be tackled within one branch, but set a goal of committing back to the trunk every day.

Should we have a Dev branch that is a branch from master?

No. According to trunk based branching , few server side branches promote easier integration and easier CI.

More

  • Do we need code review on every commit to master? What are the alternatives?

  • If we use trunk-based development, how do pipelines recognize release trunks?

    • Not a problem for this page

    • Production is a release off a build

Decision

  • Fork and pull - ref

Links