Part Two: What is merge?

Content Summary

• The first part: What is a commit hash?
• Part II: What is merge?
• Part III: What is rebase?

In the first part we created a small demo repository, which has a feature1 branch, and the branch is ready to merge into the master branch.

At this point, we can select the merge or rebase feature1 branch to the master branch. About rebase will be introduced in the third part. Now let's take a look at what happened in the way of merge. It's very straightforward to merge the branches together. First you need to switch to the branch you want to merge into, and here we need to switch to the branch because we're going to feature1 merge to the branch master master .

I switch to the master branch, and then feature1 merge the branches in. Look back and see what's happening in this, why the graph generated by the source tree looks like this.

Remember the first part and the Commit 3 Commit 4 same previous commit? Commit 2is a common ancestor of these two commits, because Commit 3 it is created on another branch and Commit 4 is created on the master branch, so it is completely unaware Commit 3 of the existence. feature1We added more commits on the. Commit 5directly referenced Commit 3 because it Commit 4 is valid only on the master branch Commit 6 Commit 5 .

When we feature1 merge into master it, it does not magically move all of these commits to the branch in some way master . In fact, it creates a feature1 new commit that contains all the changes on the branch. This commit is called Merge branch ‘feature1‘ , like this:

If you notice the commit difference in, you will see that I added to the index.txt smacking of the two lines. You should notice that these lines are added separately through each commit. However, what you see now is that all of these changes are in a single difference.

Git does this by feature1 aggregating all the differences in all commits into a single commit. This new commit has done something we have not discussed before. You can see that it has 2 ancestors, and it has Commit 4 Commit 6 two lines from and over. Why is it? Commit can hold multiple indexes of a previous commit. I'm only talking about it now because I don't want to cause confusion too soon.

When a commit is created, the number of previous commits it refers to can be one, multiple, or even none. Usually only the first commit in the warehouse has no previous commit, and the merge commit generally has more than one previous commit.

If you remember the first part, the branch is actually just a pointer to a specified commit.

You may notice that the feature1 point is still pointing Commit 6 , and the master branch points to the new merge commit, which is simple because we are going feature1 to merge into master . If we switch the branch to and feature1 then merge it in master , then git does a fast-forward marge (fast-forward merge), which feature1 points to the latest commit.

If we completely remove the feature1 branch, you may think that the pink line disappears, but you are wrong.

Remember that the Source tree and other git visual tools generate graphs by iterating through your commits and connecting each commit with an indexed commit hash. The branch is simply a pointer to the specified commit. When you pull an update from a remote repository, GIT does the following:

• 1. Download all commits not on your local machine
• 2. Merge the Lost commit to your local repository, either through a merge commit, or through a fast-forward merge, provided you have not made any changes since the last time you pulled the update.
• 3. Point your local branch to the latest commit.

If you've ever confused master and origin/master pointers, then now you should know what they are. origin/mastertell you where your origin remote master branch is pointing. If I add a remote repository to this demo repository origin , and then do some commit,git on the local repository, the history might look like this:

You will see master that the branch points to the latest commit, and to the origin/master previous merge commit. The Source tree even prompts us to say that there is a commit that can be pushed (push) to the remote repository. If we push it, git will upload the lost commit and update your remote branch pointer, which origin/master is already pointing to the same commit as your local master branch.

Hopefully you now have a better understanding of Git's merging capabilities. Jump to the third part let's dig into the rebase and see what difference it has with the merge smacking.

English Address: http://codetunnel.com/merge-vs-rebase-part-2-what-is-a-merge/

Part Two: What is merge?