I want to conclude our discussion of merging by giving you some strategies that you can
use to try to take some of the pain out of merge conflicts, to reduce them and to make
them easier to deal with.
I think this is important, because handling merge conflicts is really the only part of
working with branches that can be at all painful.
The first tip is to keep lines short.
In the example that we just did, we had three large paragraphs of text, so we've got our
merge conflict, we didn't know for sure where the conflict was in those three blocks of text.
But by keeping the line short will make it much easier to spot where the problems were,
because Git would then be able to show us, ah, the error was actually in the first part
of this very long paragraph, not just somewhere inside of this paragraph, so it makes them
easier to deal with.
And in some cases, it might allow Git to resolve some of those conflicts for you automatically
and have less work for you to do.
The second tip is to keep your commits small and focused.
If you open up a document to make a change, just make that change and then commit it,
don't go in there and let yourself start wandering around, making lots of other changes, sort
of, while I'm in here changes. I might as well do these things while I'm in here, and
then you commit it all together.
You're more likely to create merge conflicts for yourself by doing that.
Especially, be careful about stray edits to whitespace, that is spaces, tabs, and line returns.
Now sometimes you're going to want to make edits to those, I'm not saying that, what
I'm saying is don't make unnecessary edits to those, or unintentional edits.
You will get a merge conflict if you change four spaces into eight spaces, and you'll
have to stop and resolve it, but if you don't unnecessarily change whitespace, then those
conflicts won't come up.
The next one may or may not be practical, which is to merge often.
If you can, if you're not waiting until you finish a feature, get to some future point
in a project, if you can merge in often back to your master branch, then you should do it.
Because then each time you do it these merges are going to be smaller and the conflicts
will be smaller and more isolated.
The longer you wait, the bigger the merge conflicts are going to be. Instead of having
a conflict in three files, suddenly you're going to have a conflict in 50 files.
And you're going to spend a lot of time resolving it, and it's going to be much more painful
experience than if you break that up and resolve those conflicts as you go.
Now I don't want it to be a surprise to you that you can't merge more than once, we've
only merged one time.
Let's just take a quick look to make sure that that's clear.
If you have your master branch, let's say, and we've our text_edits branch.
So we're making commits to both of those, we're merging back in.
Now we don't have to throw away our text_edits branch at this point.
We can still continue to make new commits into the text_edits branch, and new commits
to the master branch and then merge those commits back in.
We can make more edits in to our text_edits branch, more commits in the master branch
and then merge those back in, so this is what I mean by merging often.
The last strategy is perhaps the most important one of all, which is that you can track changes
to master as you go.
What do I mean by track changes? I mean as changes continue to happen in master, keep
bringing those changes into your branch so that your branch stays mostly in sync with
master, it doesn't get far out of sync.
Let me give in illustration of this.
So again, we have our master branch, we have our text_ edits branch, we're making commits to both of those.
So at a certain point though we say you know what, master has had some critical changes
in it that I'd really like to have in my text_edits branch.
I can merge those into the text_edits branch.
Now my text_edits branch is mostly in sync with master again, and then I'll have more
changes to master, more changes to text_edits, and then I can merge those changes back in
again, tracking what's going on in master all along so that I don't get too far out of sync.
And then that way when I finally decide that I want to merge text_edits back into master,
it's not that far away anymore.
It has most of the changes incorporated in master already, and we'll reduce the number
of conflicts that you get when you merge back in.
We call this process tracking, and it is an important strategy to use.
By now you should have a good sense of how to work with branches.
How to create them, how to add commits to them, how to switch between different branches,
and how to merge them back in. It's a very powerful feature of Git, and you're going
to find that you use it a lot.