Okay, not really but this post is mostly about the git merge command. That’s also part of the reason I titled it combo breaker. Breaking the combination of code is what the command can do. The strange part about this command is that I wasn’t fully sure of what I was really doing until after I had already run the command. The most basic way of explaining the command would be by saying, “it merges A and B together.” Now that sounds almost too simple but it can be a little more complex than that.
Complex? But Why?
Yes, things can get a little complex with the merge command. Part of that reason is because of what the command can do. Taking a snippet from the description on the docs page:
Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch.
https://git-scm.com/docs/git-merge
Yeah, we can see why it can lead to a bad time for some. The part I want to really emphasize is the last two words on there. The, “current branch.” This is the part that could trip many up and cause more headaches. It has for me at least once.
It can be a frustrating one because when it comes to dealing with merge conflicts, there is no one way of preventing them short of just not merging anything.
And you can’t always avoid that. Even more so when you are working on a team.
What is a merge conflict?
So then what exactly is a merge conflict? A merge conflict is when git doesn’t know what to do with changes being committed. That is probably one way of explaining it. I’m sure there are other ways but that’s the way I think of it. The reason being is that we have to tell git what version it should use when committing those changes. That’s when git checkout comes in handy. We tell git to either use the local working branch or the use the version we are trying to merge from.
I’m sure you’re probably wondering what causes these merge conflicts. I know I did for some time. One of the more common ones is when a file is deleted and git really has no clue as to what to do with the file. While git may be powerful when it comes to merging things it can still stumble upon those and that’s where we step in and tell it to either keep it or remove it from version control. Often times that’s much faster than having to look over conflicting lines on many other files.
The other instance is when a line, or more, gets changed and git just doesn’t know which version it should be using from which file. This one that can take a little longer depending on how many lines and how many files are affected. The really cool part though is that git does show you what it can’t decide upon and it does with text.
What a conflict looks like
Yes, it sounds weird but knowing how to read that text can be super useful when it comes to resolving merge conflicts. I’m sure you’re wondering what that text looks like. It’s three symbols. Just repeated a few times.
text from file that is cleanly resolved.
<<<<<<< ours:path/to/file.txt
Conflict resolution is hard;
let's git some things back to working.
=======
Git makes conflict resolution sort of easy, right?
>>>>>>> theirs:path/to/file.txt
And here is another line that is cleanly resolved or unmodified.You’ll notice those three symbols the <,=, and > which are just repeating a few times. That’s how git tells us what needs to be chosen. There are GUI applications which can help in better viewing but at the core of it that’s what git uses. So think of most GUI applications as sort of visual representation of the command line. What you’ll notice is that there is a ours and theirs that is added in that sample snippet. This is to help understand what git is trying to tell us.
The lines between <<<<<<< and ======= are what is on the local copy and the working branch. The lines after ======= and between >>>>>>> are what git is trying to merge but isn’t sure it should. There are times when we do want to keep what is on the the current working copy so we’ll chose the first lines. This is done by removing those == and << and only keeping the lines we would like to commit. This is part of the reason merge conflicts can be a huge pain to resolve. When there are so many files that have those to look over it can really put a damper on productivity.
The important bit
Not like code bit but rather the key take away from all of this. It’s that git merge can and will take changes from one commit and apply it to the current branch. This will happen if those histories have diverged. So if the changes you are looking to apply to the current branch are already present, git won’t do anything.