Make sure to go through till the end, I have dived in-depth.
What's a Conflict?
A conflict is when two branches have overlapping changes.
Let me create a conflict for you.
I'll demo it on GitHub.
Let's take the dev branch as the reference.
The dummy file is where I'll be creating the conflict.
I'm creating two branches: feature_A, and feature_B from the dev branch.
In feature_A, I have a change in line 2.
In feature_B also, I have a change in line 2.
We raise a pull request (PR) from feature_A to dev. There won't be any conflicts, so we merge it right away.
Now, we raise a pull request (PR) from feature_B to dev & then this happens.
Conflict! Before we go ahead & resolve it, let me tell you why the conflict has happened.
Initially, we had our dev branch. From this, we create two branches: feature_A & feature_B.
Now, what we need to understand is what's happening under the hood in the step where the changes are shown.
Git decides if a file can be merged automatically based on the changes made in both branches by using a 3-way merge algo.
We are raising a PR from the feature (source) to the dev (target) branch. Here's how Git works in the backend:
Git identifies the common ancestor commit of both branches (merge base). This is where the branches diverged.
Git compares the changes made in the source branch since the merge base with the changes made in the target branch since the merge base.
In the case of PR from feature_A to dev, the changes in both branches do not overlap. This implies they modify different parts of the file & can be merged automatically (which we already did).
In the case of PR from feature_B to dev, the changes in both branches do overlap. This implies they modify the same parts of the file & can't be merged automatically. Hence, we get a conflict.
When we are trying to resolve the conflict, we can see a few additional lines.
Here's how I'm gonna break it down for you.
In line 2, we have feature_B mentioned. From the next line to '=' the changes are from our feature_B branch.
The '<' signifies that those are the changes that wanted to go into dev.
After '=', from the next line begins the code in dev branch.
The '>' signifies that those are the changes that would be replaced from dev.
Fun Fact: The number of '<' characters depends on the diff tool configuration or the specific Git client being used.
There can also be cases when you get multiple areas of conflict. In such cases, the branch names & angular brackets (<>) help a lot.
Let's go ahead & resolve the conflict. This is a step we need to do manually. It's up to us to decide which changes to keep, & which to discard. We can also keep both. It would ultimately depend on the situation.
Note: Remember to remove the symbols "<, =, >"
Like some movies which leave it up to your imagination to decide what happens, I'm gonna leave the last step to you.
You can check out the code here.
This article was written as part of the WeMakeDevs blogging challenge. Since version control is a part of DevOps, my submission is towards the same. #WeMakeDevs