Git，合并分支git

Question

I can not understand why my merge is updating one commit... it look that it updating commit Add Color, not merging master with coins. Sublime doesn't pop out when i try to merge these branches. Anyone can help me? Moreover when i type git commit i have:

On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean

Answer 1

I'm not sure what your question is, but think there's two things going on here you might not fully understand.

First, I don't think git merge master coins does what you think it does.

git merge master coins does not say to merge master into coins . It says to merge master and coins into the currently checked out branch. That's because master coins is a list of branches to merge into the current branch. From the docs ...

[git merge] incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch .

If master is checked out, then it merges coins into master. If coins is checked out, then it merges master into coins . If something else is checked out you get what's called an "octopus merge" and all three, master , coins , and the current branch are merged together into what is probably a big mess.

As it stands, you merged with master checked out, so git merge master coins is the same as git merge coins . You merged coins into master which is, I think, what you wanted, but it could have gone bad.

So don't use that syntax; it can get you in trouble, and it's hard to know what actually happened by looking at the command history. Instead use git checkout branch-to-merge-into; git merge branch-to-merge-from git checkout branch-to-merge-into; git merge branch-to-merge-from . So if you want to merge from coins into master, git checkout master; git merge coins git checkout master; git merge coins .

---

Next issue is about the fast-forward merge. This is something that Git does when there's no need for a merge, when the branches haven't diverged. For example, let's say you had this...

A - B - C - D - G [master]
         \
          E - F - H [feature]

Since master has changes which are not in common with feature (D and G), it must merge. So git checkout master; git merge feature git checkout master; git merge feature results in a new merge commit.

A - B - C - D - G - I [master]
         \         /
          E - F - H [feature]

But if there were no new commits on master , you have this ( master is pointing at C).

         [master]
A - B - C - E - F - H [feature]

feature is said to have not diverged from master . There's no need for a merge commit, so Git doesn't bother with one. When you do git checkout master; git merge feature git checkout master; git merge feature it simply moves master to H.

                      [master]
A - B - C - E - F - H [feature]

Git can do this because "branches" are really just labels pointing at a commit. Now master and feature point at the same commit.

---

I recommend avoiding fast-forwards while merging feature branches because it loses important archeological information. Someone looking at the repository later cannot tell that E, F, and H were all done as a single branch.

I recommend to always merge feature branches with git merge --no-ff . This forces Git to make a merge commit and someone trying to figure out your code in the future can know that E, F, and H are all part of a greater whole.

A - B - C --------- I [master]
         \         /
          E - F - H [feature]

The merge commit, I, also gives you a place to describe the branch and add things like a link to the issue/bug/ticket describing what the branch was for.