在我们的项目中，我们试图接近“官方”git工作流程，如下所示： http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
我们使用master和next分支，从master开始我们的主题分支，定期将测试集成到next，如果分支完成，我们将其合并到master。
现在有时它会发生，topic-X上有一些发展。开发人员创建somefile.c并在其中添加他的主题所需的代码。一段时间后，另一位开发人员在topic-Y上工作，并发现他还需要创建somefile.c，甚至需要topic-X中该文件的某些部分 - 但不是完整文件，如它还包含代码，该代码仅与topic-X相关。他可能还需要在该文件中添加其他代码。
如果topic-X完成并合并到master，则很容易：我们可以将topic-Y重新定义为master以使该代码可用。但是，如果这两个主题仍然不完整呢？
由于topic-X和topic-Y实际上是无关的，除了somefile.c中的这个次要共享代码之外，我们如何避免将它们相互合并并仍为开发人员提供共享来自somefile.c的部分？
如果我们在somefile.c中仅使用相关部分创建topic-Y的全新副本，我们发现当我们在next中测试集成时，我们会发生合并冲突。还有其他选择吗？
答案 0 :(得分：1)
合并时，git会检测是否已经应用了提交中的更改。
因此，如果topic-x中的提交在somefile.c中更改了topic-y，那么您可以在topic-y中挑选该提交。 （让自己轻松一点，并将此提交仅限于您想要共享的内容。）
git checkout topic-y
git cherry-pick topic-x
稍后当您合并topic-x和topic-y时，git会看到该修补程序已经应用并正常跳过它。
这是一个比变基更好的选择，因为如果分支已经公开给多个开发人员，那么变基有副作用。
答案 1 :(得分：1)
最好在分支中合并X和Y的公共基础，并将topic-x和topic-y基于该分支。然后，两个分支最好不再触及somefile.c，但只说somefile-x.c和somefile-y.c。
或者，像topgit这样的更高级的工具可能会帮助您（或不会： - ））