In this movie I want us to understand the difference between fast-forward merges and real merges.
When I first gave you an example of what a merge looks like,
I said that it looked something like this, and then we made a merge commit that brought
those two branches back together and did it with a new commit.
But that's not what actually happened in the last movie when we did our first merge, and
the reason why is because this isn't really representative of the state of our two branches at that time.
We hadn't made additional changes to master yet.
It actually looks something more like this.
So we had made our branch, we'd made another commit on that branch, but we had not make
any changes to master, as a result, it did a fast-forward merge.
You may or may not have noticed, but it actually came up and told us that when we did the merge.
What happens is when git goes to do a merge, it takes the thing that you're merging in,
and it starts at the end of it, and it looks back at all of the ancestors, all the way
back up to the beginning.
So in our example here, it starts with ba8ce and then goes to 534de, all the back to get
to 84c46a, all the way down the chain.
And along the way, it looks to see whether it has the HEAD pointer of the current master branch.
In our case, the HEAD pointer was pointing at the commit where the branch was made, no
movement had been made.
If it does that, if in the chain of ancestors it sees the HEAD, it says oh, I'm safe to
do a fast-forward merge.
I don't need to do that fancy merging and make a new commit, instead what I can actually
do is I can just move that commit up into my timeline and move the HEAD along to it.
Now revise_navigation also points to the same thing, they both point to ba8ce.
There was no need to make a new commit. You could just fast-forward along the chain and merge that way.
So we know that that's true, because we can do git log seo_title --oneline, and then let's
just look at 3 of those lines.
Now notice that the top commit here dc9c83c, that's the thing that had changed before in
seo_title, that's what we merged in to master.
So let's take a look now at master.
See the same commits here, it's got the same SHA, it's the exact same object stored in Git.
It did not make a new commit in order to merge these two together, it did a fast-forward.
Now there are a couple of options with merge that are related to the fast-forward.
The first is the no-ff option so that would be git merge --no-ff and then whatever branch
you were trying to merge.
The no-ff option forces Git to create a merge commit anyway.
It says, don't do a fast-forward, make a new commit with the commit message anyway.
And the main reason you'd want to do this is if you wanted some kind of documentation
of the fact that you did do this merge.
You didn't want it to just quietly do it, you wanted it to sort of make some noise in your git log.
The other option you should know about is the ff-only option.
Don't get those confused, no-ff says don't do a fast-forward, ff-only says do the merge
only if you can do a fast-forward.
If you can't do a fast- forward merge, then just abort.
Don't try and do it at all just exit.
So we won't do either one of those now, but those are useful options to know.
All right, so now as a contrast, let's try an example of a true merge or a non-fast-forward merge.
Let's take a look at our branches, so we've already merged in our seo_title branch.
What I want to do is I want to merge in our shorten_title branch and make those changes.
Now if we were just to merge it in the way that we did before, git merge shorten_title,
it would do a fast-forward merge.
Why is that? Well, it's because the only object that's different between them is the one commit
now that master doesn't have.
There were two commits; the master was missing before, now it's only missing one, and it
would just fast-forward one more time.
Instead, we need to make it so that it's non-fast- forward, and the way that we do that is we need another
commit on master.
If there's another commit on master, then it'll no longer be able to just fast-forward,
because now HEAD will have moved to a new commit that is not in the shorten_title branch.
So let's try that.
You want to make sure you're on your master branch and then let's edit our contact.html,
and you see it says Export California: Contact Us, let's take out the us, so it's just Contact.
Close it up, clear it, git status, so we have our contact file there, git add contact.html,
git commit -m and "Edit contact.html title".
Okay, so now we've made our commit, git log --oneline, and let's just look at 3, so there it is.
Now we have a new commit that comes after this dc9 commit, so git log for the shorten_title
branch, so let's just take a look that one real quick.
Notice now it has that commit here, but then there are two commits that come after it.
So we've got a common ancestor, but right now HEAD is pointing here, and it's not one
of the ancestors of the shorten_title branch.
So it won't be a fast-forward merge, it'll be a true merge.
The process is the same though.
We just say git merge shorten_title.
Now Git popped up, and it asks me to provide a commit message here, that's because I had
configured it to have TextMate as my default editor. It may have popped you into a different
editor, or it can be configured so that it doesn't give you the opportunity to edit it, that
it just goes ahead and makes this commit with this commit message, Merge branch shorten_title.
All of these lines are going to get ignored and left out of the commit message.
So I'm going to go ahead and accept this, so I'm just going to hit Save and close it,
and it says, Merge made by the recursive strategy.
So merge has different strategies for merging, recursive is typically the one that you're
going to see there, and it figured out how to make a merge between the two.
If you take look at the log for the master branch now, you'll see that we've a have a
new commit, Merge branch shorten_title that comes after that one, and that is the
commit that ties these two items back in together.
And sure enough, if we take a look over here, our contact.html page is what we would expect.
And if we take a look at our index.html page, it is our shorter title here as well.
Now may be wondering, what about the fact that the index.html was different in the master branch?
Well, that might at first seem like it's a conflict between the two, but it's not, because
the change to shorten_title branch was made after that. It has that as an ancestor, so
it was able to resolve it, it was able to say, oh I see, later that thing was changed. There's
a snapshot that addresses that change.
So it wasn't any kind of conflict, the same way that it wasn't a conflict when we did
our fast-forward merge.
So hopefully that it gives you a better idea of the two ways that Git can handle merges, either
by fast-forward or by doing a real merge, and it's pretty good at figuring out how to merge things in.
However, sometimes there are merge conflicts. Sometimes there are problems that Git can't
solve on its own, and it needs you to resolve them, and that's what we're going to look
at in the next couple of movies.