How To Solve Merge Conflict With Intermediate Branch
Tags: git
Published: 2024-04-18 07:22:36

## 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.

![No Conflict](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k2s00hdfhdioxdqpcx9z.png)
_**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

![Concept](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b7xvrjdmzq7am4wtbq4f.png)_**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.


![resolving merge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lfkb5trczgtkkqywl8et.png)_**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**

![Intermediate Branch](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8fsogdmm73drxh8xjzq7.png)_**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**

![Git visualized](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ndx7gjfww8yoed6qt66d.png)_Each developers **Branch** are clean and can directly PR to **Master**_



![Git workflow visualized](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kl7ixi4p2fc0sw8a3eq8.png)_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