合并时git如何解决？

Question

也许这是一个愚蠢的问题。但。当我开始使用Git时，我被告知在处理功能分支时，在合并到master之前，我必须合并从master到my branch的所有内容。现在，从测试的角度来看，我可以理解。为了能够在将代码合并到master之前知道一切都正常运行我应该首先在我的分支中进行测试，因此我必须从master合并到我的分支。 在我目前的项目中，我们有另一个工作流我有一个功能分支，然后master充当临时分支，然后我们有另一个生产分支。很好的工作流程btw。

但这迫使我开始思考如何在git中实现分支和合并。如果开发人员D1创建了分支A，并且开发人员D2稍后创建了分支B.开发人员D1执行一些工作并将分支A合并到主服务器。现在D2将他的分支B合并到主人。只有D2实际更改的文件才能合并到master，或者git会尝试合并D2创建分支时存在的每个文件，即使那些没有更改的文件也是如此？ D2在尝试合并之前是否应该从主人合并到分支B，或者不重要吗？

我的猜测是git只合并了更改的文件，但我不是100％肯定：）

Answer 1

合并结合了两条开发线的变化。因此，除非你告诉Git，否则它不会用master覆盖B，但它会结合master和B以及master所做的更改我已合并A，master上的 更改

。

Answer 2

git中的合并操作总是作用于整个存储库，没有基于文件的合并。

那就是说，它是一个每个文件的3路合并（像往常一样）。这意味着，如果将您的功能分支A合并到master：

• git会在A和master之间找到最年轻的常见提交;我们称之为oldmaster。
• git会找到oldmaster和A之间的差异，并尝试将这些差异（补丁）应用于当前master;逐个文件。如果某个文件没有差异，那么该文件当然不会做任何事情。
• 最后，你得到一个（合并）提交;所有不同文件的所有补丁都将作为一个补丁提交;此提交将同时包含A和master。

具体回答您的问题：

  

只有D2实际更改的文件才会合并为主文件，

是

  

或者git会尝试合并D2创建分支时存在的每个文件，即使那些未更改的文件也是如此？

也是的。 git将“尝试”它们，但发现没有变化，所以这是一个无操作。

  

D2在尝试合并之前是否应该从主服务器合并到分支机构B，或者不重要？

这取决于您的工作流程（您实际上与主人一起做什么），但通常不会，“默认情况下”没有技术理由这样做。 git不是svn，它可以做任何类型的合并;没有（就像在“旧时代”中的一些限制，例如在svn中，你有所有“重新整合”使合并变得复杂的东西）。

  

我的猜测是git只合并了更改的文件，但我不是100％肯定：）

这就是“合并”的意思。合并并不意味着将所有内容从A复制到B，而是看看在共同父C之间发生了哪些变化。