14

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

如果你知道如何请解释如何在你选择的 VCS 中执行此操作，例如 subversion、git、Mercurial、bzr 等。

4

4 回答 4

26

在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更新主题分支（在此示例中名为）。feature_foo这意味着当您输入以下内容时：

git rebase master feature_foo

Git 将像这样重新排列修订树，并且还会应用补丁本身：

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

合并到上游分支现在将是一个简单的快进合并。还要检查新的提交并分别作为以前的提交E*和工作。F*EF

您可以使用相同的步骤对另一个开发人员的分支执行相同的操作，但不是在公共存储库中执行此操作，而是从开发人员的存储库中获取修订。这样一来，您就不必向其他开发人员询问补丁是否已经从他在他的存储库中发布的内容中获得。

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

于 2008-11-16T14:22:59.707 回答
2

在 SVN 中，您可以简单地进行更改，然后在提交之前，将 svn diff 的输出通过管道传输到这样的文件

svn diff > mypatch.diff

然后，您可以恢复您的更改并在以后使用

patch -p0 -i mypatch.diff

与往常一样，不要盲目地将补丁应用于您的代码并始终首先检查它们。

如果源文件在使用补丁后发生了足够大的变化，您可能还会发现补丁会破坏您的源代码。

您也无法保证在尝试签入代码时不会发生合并冲突。

于 2008-11-16T11:40:54.417 回答
2

Bzr 处理发送“合并指令”，这意味着它会为您发送补丁，以便对方可以简单地单击“确定”进行合并，并且补丁/应用等操作更少。

只是： $ bzr 发送 -o mycode.patch

于 2008-11-16T16:53:10.840 回答
2

在 Subversion 中没有很好的方法可以做到这一点。是的，您可以使用 svn diff + patch 但这只会将您的问题推迟到您要合并之前，然后您很可能已经忘记了它。

您在 Subversion 中执行此操作的方式是创建一个分支，在该分支上进行提交，并要求补丁的接收者切换到该分支。然后您可以以通常的方式将分支合并回主干。

于 2008-11-16T19:25:44.523 回答