Git的合并主分支 - 冲突（从Subversion背景的）

Question

颠覆背景：

我们从过渡到SubversionGit。

我们使用Subversion trunk作为我们的“黄金副本”，创建长期运行的功能分支，我们将合并trunk多次分支。

最后，当功能完成后，我们会将分支合并回trunk。

当我们这样做时，如果在trunk中修改了Bar.java，但我们从未在分支中修改它，我们将永远不会在Bar.java上发生合并冲突。

我认为这是因为Subversion有一个概念svn:mergeinfo，并知道合并的历史和Bar.java从未在分支中修改。

SVN分公司Maintenence图：

Git的行为：

现在我们已经过渡到Git，我们正在合并主分支越来越冲突，即使我们没有改变分支中的Bar.java！

我相信这是因为Git不会有svn:mergeinfo相同的概念，并没有持续跟踪Bar.java变化从master走了过来，在合并的事实

的Git图（SHOWS ISSUE）：

问：

有没有什么办法可以继续使用我们在Subversion（频繁合并中继到分支）中使用的相同方法，而不会在Git中发生冲突？

有没有办法实现一个等效的svn:mergeinfo，以便Git知道一个文件只在master更改，并且从未在branch中更改，并自动合并？

虽然我所示的例子是微不足道的（一个文件），实事求是，我们有许多开发人员并行工作，并最终处理大量的文件发生冲突，并在行为从svn到git这种差异是导致我们很多的痛苦。

Answer 1

Git确实与svn:mergeinfo类似，实际上是更先进的一个。如果你在你的分支中没有碰到的文件上看到合并冲突，这意味着你以某种方式触摸它（IDE​​自动行结束转换是一个常见的陷阱），或者有些已经改写了trunk上的历史记录。确保你们不要做git rebase，commit --amend或类似的历史重写改变的主干。

编辑为我们如何寻找合并信息

标准git log会告诉你，在第二行中的合并信息：

$ git log 
commit 1ca56fefd6ed1af2a6e62f1fbd811d56fa72ded7 (HEAD -> master, origin/master, origin/HEAD) 
Merge: a3323f6 2237297 

通常使用图形表示的UI看什么都有被合并，并没有。在命令行git log --oneline --graph HEAD origin/master将显示一个包含您当前工作日和origin/master的子图供检查。 git log origin/master --not HEAD会打印出git假定尚未从主服务器合并到您当前分支的提交。