如何将补丁发送给其他开发人员并避免合并冲突？

如何从提交中获取补丁以将其发送给其他开发人员？在以后合并我们的树时,如何最好地避免与此补丁的合并冲突？

如果您知道如何在您选择的VCS中解释如何执行此操作,例如subversion,git,Mercurial,bzr等.

在git中,您可以管理git-diff两个提交之间的输出,如下所示:

git diff fa1afe1 deadbeef > patch.diff

发送patch.diff给开发人员,让他git-apply到他的工作区,如下所示:

git apply patch.diff

如果其他开发人员已经在他的存储库中提供了提交,他可以随时将其自行管道而不会像这样合并:

git apply < git diff fa1afe1 deadbeef

然后,您可以通常的方式在diff中添加和提交更改.

现在,当你必须将补丁合并回主分支(即公共)时,会出现一个有趣的部分.请考虑以下修订树,其中C*是C主分支中应用的修补程序:

A---B---C---D          master, public/master
     \
      E---C*---F       feature_foo

您可以使用它的上游头git-rebase更新主题分支(在此示例中为named feature_foo).这意味着当您输入以下内容时:

git rebase master feature_foo

Git会像这样重新安排修订树,并且还会应用补丁本身:

A---B---C---D          master, public/master
             \
              E*---F*  feature_foo

合并到上游分支现在将是一个简单的快速合并.此外,检查新的提交E*和F*工作为以前E和F分别.

您可以使用相同的步骤对另一个开发人员的分支执行相同的操作,但不是在公共存储库上执行,您将从开发人员的存储库中获取修订.通过这种方式,如果已经从他在回购时发布的内容中获得了补丁,则无需向其他开发人员询问补丁.

请注意永远不要重新绑定公共分支,因为该命令将重写git历史记录,这是您不希望在人们依赖的分支上执行的操作,并且在合并到远程存储库时会造成混乱.也永远不要忘记经常整合,以便团队中的其他人可以参与您的更改.