Git Branching and Merging Strategy
Git branching strategy for continuous delivery, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file or a directory tree) so that modifications can happen in parallel along both branches.
Git Branching Strategy for Continuous Delivery Types
Entire delivery team is responsible for promoting code, the strategy would give a clear communication and misunderstanding would be less frequent. The following are the most common branching scenarios-
- “Branch by release“, sometimes called “staircase model” is the oldest one, where for every planned release we have a separate branch.
- “Branch by feature“, in turn, has distinct branches for different user stories. This occasionally comes in handy, as when we have to do a challenging task such as a cross-cutting upgrade, and we do not want to risk the stability of our code by mixing upgrade check-ins with other stuff.
- Lastly, “branch by abstraction” approach, which has recently had much more attention due to the “continuous delivery” (CD). This strategy is founded on the concept of a single branch for everything. Features that are new, but not yet finished, can be enabled or disabled by feature-toggles. We can use this device to release different versions of our application from single branch, by changing its configuration.
The following table shows a branching model based on Branch by Feature strategy.
|Master||The main branch which contains production ready source code. This branch is for keeping production ready code only. All releases will be tagged in this branch.|
|Develop||Develop branch will be created from Master branch. This is where the latest changes are made to the source code|
|Feature||A feature branch is used to develop new features. A feature branch exists as long as the feature is in development, but will eventually be merged into develop before the development for the defined release is to be merged into the Release branch|
|Release||A release branch allows for the preparation of a new release.A Release branch will be taken from Develop when all features for a targeted release are merged into Develop|
|HotFix||A Hotfix branch is used to fix any issue with the live production code. When a critical bug in the production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. (Please note that this should not be used for any major feature development, that should be planned for next major release and come through Develop >Release >Master|
- Only selected people (leads for e.g.) will have rights to Master and Develop branch.
- A developer will get the facility of Gated Build – which includes compilation, unit test execution and code quality analysis to ascertain the quality of his code.
- When a developer wants to merge his changes to the Develop branch, he/she will raise a pull request.
- One of the leads will accept the pull request and then a CI build will be triggered on the Develop branch.
- This CI build can happen multiple times a day whenever a merge is accepted in Develop branch.
- When code stability is reached a pull request to merge to Release branch will be raised. A select set of people will have rights to accept merge to Release Branch.
- On merge to Release Branch a new build will be triggered which will generate release ready artifacts.
- Multiple release branches can exist when development reaches readiness to fork out a release branch from Develop branch.
- A release branch will not be merged to another release branch directly. It will be merged to Develop and Master branches.
- When a release branch code reaches production like environment, a merge to Master is done to keep reference ready.
- Other running branches will take latest from Master and keep themselves up-to-date.
Note: Direct commits/merges are not allowed in Master / Develop branch. Developer must raise pull request to propagate code to target branches. Appropriate reviewers will be added automatically for each pull request to upstream branches.
Thank you once again for reading our posts. If you haven’t read the post on how to migrate/setup gitlab – please read them here 🙂