Introduction
Usually, in a company, there are several developers, repositories, and branches. The more features that are developed, the more complex Git branching becomes, so there needs to be a correct Git branching mechanism to make the process of merging code easier.
This will explain git method to prevent tainting branch from other branch changes, making branch clean and can be directly merged to master branch, avoiding cherry-pick and reduce Merge Complexity.
Knowledge Requirement
This document assume that you have basic knowledge of git commit, merge, branch, and merge conflict.
Here some basic tutorial link:
- https://learngitbranching.js.org/
- https://git-school.github.io/visualizing-git/
- https://www.amazon.com/Learning-Git-Hands-Visual-Basics/dp/1098133919/
Problem
The issue came up when two or more people were working on the same shared branches like master (for the production server) and staging/dev (for the testing server), and pushing changes directly to these branches was not allowed.
This create a situation where staging/dev contain changes from other people and might not yet stable, thus cannot be merged to master, and to your branch because your branch eventually will be merged to branch.
For example:
you checkout from master to develop new functionality to calendar feature, after finishing the development you PR to staging, but at the same time Steve (other developer) working on calendar feature to improve performance, and both Steve and you happen to change the same file. Now Steve or You cannot directly merge/rebase into staging, now imagine if there is more than 2 developer.
Example No Conflict
If the branch does not conflict with staging/dev on PR You don't need to use special strategy, You can directly PR to main & staging/dev without any conflict.
This happens if changes happen in different file, and if up-to branch date is not enforced.
Branch created from master, after branch updated, PR has no merge conflict with master/dev and staging/dev, therefore intermediate branch can be skipped.
Example Conflict
If the Branch PR has merge conflict staging/dev, you cannot proceed the merge, merging/rebase from staging/dev to Branch will make Branch contain changes from staging/dev that may not stable/final yet
Branch created from master, after branch updated, PR has merge conflict with staging/dev, therefore intermediate branch is needed
If you merging/rebase from staging/dev to Branch, then you cannot directly merge Branch to Master because Branch contain changes from staging/dev that may not stable/final.
Branch created from master, after branch updated, PR has merge conflict with staging/dev, merging staging/dev to Branch cause Branch contain changes staging/dev
Solution
One solution is using new Intermediate branch to contain merge conflict resolution between branch and staging/dev
Intermediate branch accept changes from Branch or staging/dev, but not pushing changes to Branch, and PR to Staging/Dev using Intermediate Branch
Branch created from master, after branch updated, PR has merge conflict with staging/dev, create intermediate branch from Branch, merging staging/dev to intermediate branch will not change Branch, Branch are clean and can directly PR to Master
Now with intermediate branch, Branch does not contain changes from staging/dev, and branch is clean and can be directly PR to master.
Now each developers Branch does not contain changes from other developer Branch
Each developers Branch are clean and can directly PR to Master
Git workflow visualized
Pros & Cons
Pros
- Branch clean can be directly PR to master
- No cherry picking
Cons
- Increase branch number
- In rare case you need to resolve the same conflict multiple times
Conclusion
By using intermediate branch able to make master/branch clean in our use case. There is many branching model for git, this model works particularly well in our use case. You should also explore another branching model/strategy option, to make inform decision to decide which is best for your use case.
Legend
- --> = merge/rebase
- Branch = Working branch outside master, staging/dev for feature, hotfix or anything.
- ⚪ = Commit
Top comments (0)