A GIT merge introduces a new commit. This causes problems with "git blame": the merged lines appear to be committed by the developer that did the merge.
I can understand this being the case for conflicting changes (because he solved the conflicts). But is there a way to not have this happening for non-conflicting lines? Some option to "git blame"?
If there is no way around, this would basically make "git blame" almost useless when you have a lot of merges - and GIT encourages a lot of merges.
Does SVN have this issue with non-conflicting merges? I don't think so, but I may be wrong as I (understandingly) avoided branches like plague when working with SVN.
Internally git blame uses git rev-list to create the revision list. And git rev-list accepts the --no-merges option.
So you can do:
git blame --no-merges <file>
I just tried a merge with git version 2.3.8 and the non merge conflicted lines were not attributed to the merge commit author, they are attributed to the original author. Perhaps this has been addressed since your version of git.
来源：https://stackoverflow.com/questions/15769298/git-blame-correct-author-after-merge