如何向另一个开发者发送补丁并避免合并冲突?

15

如何从提交中获取补丁以便发送给另一位开发者?在稍后合并我们的代码树时,如何避免与此补丁发生合并冲突?

如果您知道如何操作,请说明如何在您所使用的版本控制系统(如Subversion、Git、Mercurial、bzr等)中实现。

4个回答

27
git 中,您可以像这样将git-diff命令的输出在两个提交之间进行传递:
git diff fa1afe1 deadbeef > patch.diff

patch.diff 发送给开发者,让他像这样在工作区 git-apply

git apply patch.diff

如果其他开发者已经在他的代码库中有了这些提交,他可以像这样自己进行传输而无需合并:

git apply < git diff fa1afe1 deadbeef

您可以按照正常的流程添加提交更改,然后进行差异the usual way
现在,当你需要将补丁合并回主分支(即公共分支)时,就会出现有趣的部分。考虑以下修订树,其中C*是从主分支中的C应用的补丁:
A---B---C---D          master, public/master
     \
      E---C*---F       feature_foo

你可以使用 git-rebase 命令来更新主题分支(在本例中命名为 feature_foo)到其上游的最新版本。这意味着当你输入以下内容时:
git rebase master feature_foo

Git会重新排列修订树,同时也会应用补丁本身:

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

将合并到上游分支现在将是一个简单的快进合并。还要检查新的提交E*F*是否与以前的EF相同。

您可以使用相同的步骤针对另一个开发者的分支执行相同的操作,但是不要在公共存储库上执行它,而是从开发者的存储库中提取修订。这样,如果已经在他的存储库中发布了补丁,您就不必向其他开发者请求补丁。

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


事后发现,您可以使用git format-patch格式化补丁,并使用git am应用和提交补丁。例如:git format-patch -k --stdout R1...R2 | git am -3 -k - Spoike

2
在SVN中,您可以简单地进行更改,然后在提交之前将svn diff的输出流导入文件中,如下所示。
svn diff > mypatch.diff

您可以撤销更改,然后在以后的日期使用补丁程序来应用该补丁。

patch -p0 -i mypatch.diff

一如既往,请勿盲目应用补丁,始终先检查补丁。

如果源文件自从取出补丁以来发生了足够大的变化,你可能会发现补丁会破坏你的源代码。

你也无法保证在尝试提交代码时不会出现合并冲突。


2

Bzr处理发送“合并指令”,这意味着它为您发送补丁,以便对方可以简单地点击“确定”进行合并,而无需使用补丁/应用等工具。

只需执行以下操作: $ bzr send -o mycode.patch


bzr send只在两个不同的分支之间创建一个合并指令。我正在寻找如何创建像单个提交或挑选的补丁,以及在应用这些补丁时合并是如何工作的。 - Spoike

2
在Subversion中没有很好的方法来解决这个问题。是的,你可以使用svn diff + patch,但这只会将你的问题推迟到合并时,到那时你可能已经忘记了这个问题。
在Subversion中做这件事的方式是创建一个分支,在分支上进行提交,并要求补丁接收者切换到该分支。然后你可以像平常一样将分支合并回主干(trunk)。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接