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
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. So if you want to merge from coins into master, 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 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 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.
