GIT: Merge Conflicts

The merge that we saw in the last chapter was relatively easy for Git to solve. But in reality, not all conflicts are going to be easy. Earlier we made changes to different lines in the same file in both our branches. Can you guess what will make up a hard conflict then?

Absolutely right! Changes made in the same line, or rather same areas of the file will result in a hard conflict. Git cannot determine which version you want to keep in the final project. In a simple conflict, Git conveniently merged both versions to the file.

Let's go on and set up a hard conflict for Git. Check out which branch you are in just to be sure. Let's say you are on the signin_feature branch. Open up any one of your files and make some changes. Remember to commit this change.

Then, checkout the master branch and make the changes to the SAME file, but in a different way.

Now that you are on master, commit this change and try merging the two branches. Just like in the last chapter, we see Git has detected a merge conflict and has tried automerging it, but it has failed. Uh-Oh.

Git has detected changes to the same line and doesn't understand which file you would like to keep in the final project. Whenever Git comes across such a conflict, it leaves it up to the user (you!) to resolve that conflict manually. Open up the conflicted file and hmm? There seem to be some weird punctuation marks inside the file. We didn't write these, then who did?

That's right, Git marks the area where the conflict occurred. Pretty smart and helpful, eh? They are called conflict markers. The angled brackets indicate that the whole area is conflicted. The row of equal signs is the separator between the two versions. The top version is labelled head which is a special term for the latest commit. The bottom version is labelled signin_feature, no prizes to guess what it means.

Git has given us full power to edit and keep whichever version we want in the final project. Now that we have resolved the conflict, we need to tell Git that its done. Resolve all other conflicts (if any). Let's add our change to the staging area and run $ git commit.

Notice that Git knows we are resolving a conflict and has already prepared a commit message for us. There, the conflict has been resolved and the two branches merged successfully. Keep in mind that in such cases, Git relinquishes all control over resolution of merges and it completely depends upon you to solve it.

Handling merges manually might seem a bit difficult and complicated, but then it ensures you have the right version in your final project. So that was all about merging.

VCS such as Git are useful when you work on a personal project, but they show their true power when you collaborate with others. When you collaborate , you need to store your repositories remotely. Let's learn more about interacting with remote repositories next!