合并/比较工具，可以显示作者（支持责备或注释）中的文件版本控制之下(Merge/diff tool

当合并文件，这将是有帮助的（对我来说），以显示每行的作者。是否有任何差异或合并工具，支持了吗？

Answer 1:

捆绑gitk工具是不是一个真正的合并工具，但它表明冲突线用红色和蓝色，“+”的前面，你可以右击 - 对其中任何>‘这一行显示的起源’，去提交，其引入的线：

你可以运行你的合并工具，或者只是在平行diffmarks文本编辑器

Answer 2:

So what you really want is a tool that can easily identify your changes relative to other's changes in a merge conflict, rather actually identify the author of each line (which would be a mean to achieve that), right?

If I understood you correctly, I have some relatively good news: It can be done with git + kdiff3. For merging you can just use git mergetool (which you can configure to use kdiff3). But it is not supported natively if you get a merge conflict when doing interactive rebase, so for that some manual scripting is required.

Instead of making up my own simple merge conflict example, I will use http://www.gitguys.com/topics/merging-with-a-conflict-conflicts-and-resolutions/ as an basis. Follow that page to git merge test. From after the merge command I diverge a bit from that example by running different commands (but basically doing the same job). I'll do all the manuall steps first.

So we have a merge conflict and git has inserted content from both contributing sources into the file in this <<<<<<<...>>>>>>> format, which I really do not like at all and never consider even looking at it. Instead I use my favourite merge tool, kdiff3.

First we need to find which versions that are involved.

$ git ls-files -u
100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1       README
100644 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 2       README
100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3       README
$

Basted that information we can perform a three way merge:

$ git cat-file blob b0ed415d15862ac5582b51e4de65528e86934cd2 > v1
$ git cat-file blob 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 > v2
$ git cat-file blob 9585db7d9c2d9ca05075f67a878f2554886d7b1a > v3
$ kdiff3 -o merge_result v1 v2 v3 &
[2] 18394
$

Which gives the following view where you can select from which ancestor you want to merge from.

Afterwords (if you are satisfied with the merge result) you need to

$ rm v1 v2 v3
$ mv merge_result README
$ git add README

All the manual steps above are done automatically with git mergetool. So why showing all that then? Well, because if you get a corresponding conflict during git rebase -i, then it has to be done that way (before running git rebase --continue).

In this small example there is only one conflict line, so it does not show the more typical case where a lot of lines are automatically resolved, leaving you to just manually resolve the ones that was not done automatically. A more real life example might look more like the following:

Notice that in the merge result you now clearly see the origin of the C lines that were automatically resolved. I think this is sort of what you were asking for when asking for getting the author for each line, right? That information is completely absent in the <<<<<<<...>>>>>>> text (and it is difficult/impossible to spot that you should update the printed string in the hello function).

I cannot recommend kdiff3 highly enough. Using a graphical merge tool like that compared to some lines from both sources mixed inline in the file is like using an excavator versus a spade.

Answer 3:

号而且，我认为，永远不会 - 当我们合并，我们认为有关内容，而不是作者