Git Conflicts - 14 days of Git
I'm continuing on my 14 days of Git learning journey, you can see a history of what I've learnt so far here. Today I am exploring the world of conflicts, what they are, how to resolve them and how to find conflicts.
What are Git conflicts?
As we've seen in previous learning days Git can handle merges automatically most of the time. Git conflicts arises when two separate branches have made edits to the same line within a file or even when a file has been deleted in one branch and changed in another.
When teams of people are working on different branches, features, bugs this is when conflicts are likely to happen. They are almost part of the collaborating nature of working with Git and source control.
How do you resolve a git merge conflict?
Generally, you'll get information back from Git when there is a merge conflict on what you should do to resolve it.
Below is an error message when I tried to merge a branch into my main branch:
I deliberately made changes to the README on both branches to trigger this error, but you can see the error message has told me there is an issue with the README file.
If we switch over to Visual Studio Code and open that README file we can see more information as to what is causing the error:
As we can see in here Git has added some syntax for us, we have "less than" characters and "greater than" characters. There are 7 of each, and you can use these to search through your editor quickly if you have a lot of edits to be made.
Within this example we have two sections:
- The "less than" characters denote the current branch's edits, and the equal signs denote the end of the first section.
- The second section is where the edits are from where we attempted to merge. This time it starts with the equal signs and ends with the "greater than" signs.
It's up to you as the engineer, or merger to decide what stays and what goes. Within Visual Studio Code you also have the option to use the "Merge Editor", which gives you an even greater look at what is conflicting, and helps you correct it.
If I open the Merge Editor it can help me either accept the incoming merge, the current one or both merges.
I want to accept the change from the branch, so I put a tick next to that and accept the merge.
Throughout this learning journey I have tried to do everything within the command line so I can really get to know Git and learn it without the assistance of editors. Here I have turned to an editor to help. Editors such as Visual Studio Code are there to assist you. And let's face it, most of us will be working within an editor when we encounter Git, so why not make use of the features when we get to more complex issues?
There are other ways you might encounter a merge conflict, within GitHub for example. And there is great documentation by GitHub on how to deal with that.
Dealing with conflicts will always be tricky, deciding what to keep, what to delete, what to merge together. You as the merger or owner or even as a team need to decide what is best.
For me this is probably good clear pull requests into repositories is needed, keep your pull requests simple, fix one bug or add one feature at a time. Give good explanations of what you are doing, etc That way if there is a merge conflict whoever is trying to decide what to do will have the right context and make their job easier.
14 days of Git
Tomorrow is the last day of my 14 days of Git learning journey, on the last day we are tackling subtrees and submodules.
Be sure to subscribe and join me for that last step in the learning journey!
You can follow along here: https://github.com/weeyin83/14daysofgit