Using Git 1.8.1.2 on Linux, I have been working on two different branches based on master in parallel (call them A and B), and also created a third branch (call it M) which merges those two branches—so far with no non-merge commits of its own.
After doing some work on one of the “primary” branches (A), I checked out the merge branch (git checkout M), verified that it already had everything in B (git merge B reports Already up-to-date.) , and so I git merge A to pull in the new work on A.
Some merge conflicts are reported, which is expected. I edit the affected files to remove the conflict markers, then git add them. All looking normal so far.
But then when I git commit, the commit message gives no indication of this being a merge. If I proceed, the resulting commit (in the M branch) looks like just a simple commit (atop my prior merge of A and B); git show does not report Merge: parents. Prior to the commit, .git contains MERGE_MODE (empty) but there is no MERGE_HEAD.
I am not using any special merge strategy, so I suppose the default (recursive) is being used. Anyway this does not look like a strategy problem: the contents of the working tree appear exactly like I would expect them to.
If I manually create MERGE_HEAD with the hash of the head of A before committing, the resulting commit looks normal e.g. in gitg, though of course this makes me a little nervous.
What could be going on? Is this a bug in Git—is there ever any reason for MERGE_HEAD not be created after git merge command which did not create a commit? 1.8.4.3 appears to have the same behavior.
I believe you should use
git merge --no-ff your_feature_branch
来源：https://stackoverflow.com/questions/19985906/git-merge-not-creating-merge-commit-no-merge-head