如何将补丁发送给其他开发人员并避免合并冲突？
如何从提交中获取补丁以便将其发送给其他开发人员？ 当稍后合并我们的树时，如何最好地避免与此补丁发生合并冲突？
如果您知道如何操作，请解释如何在您选择的 VCS（例如 subversion、git、Mercurial、bzr 等）中执行此操作。
How do I get a patch from a commit in order to send it to another developer? And how do I best avoid a merge conflict with this patch when merging our trees at a later date?
If you know how please explain how to do this in your VCS of choice such as subversion, git, Mercurial, bzr or etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 git 中，您可以通过管道传输
git-diff在两次提交之间，如下所示：将
patch.diff发送给开发人员并让他< a href="http://www.kernel.org/pub/software/scm/git/docs/git-apply.html" rel="noreferrer">git-apply像这样将其添加到他的工作区：如果其他开发人员已经在其存储库中提供了可用的提交，他总是可以将其通过管道传输到自己中，而无需像这样合并：
然后您可以 添加 和 提交 diff 中的更改 通常的方式。
现在有趣的部分来了，您必须将补丁合并回主分支（即公共分支）。 考虑以下修订树，其中
C*是主分支中C应用的补丁：您可以使用
git-rebase使用其上游头更新主题分支（在本例中名为feature_foo） 。 这意味着当您输入以下内容时：Git 将像这样重新排列修订树，并且还将应用补丁本身：
合并到上游分支现在将是一个简单的快进合并。 另请检查新提交
E*和F*是否分别与之前的E和F一样工作。您可以使用相同的步骤对另一个开发人员的分支执行相同的操作，但不是在公共存储库上执行此操作，您将从开发人员的存储库中获取修订版本。 这样，如果其他开发人员在其存储库中发布的内容中已经提供了补丁，那么您就不必向其他开发人员索要补丁。
请注意永远不要对公共分支进行变基，因为该命令将重写 git 历史记录，这是您不希望在人们依赖的分支上执行的操作，并且在合并到远程存储库时会造成混乱。 另外，永远不要忘记经常集成，以便团队中的其他人可以参与您的更改。
In git you can pipe the output of
git-diffbetween two commits like this:Send the
patch.diffto the developer and let himgit-applyit to his workspace like this:If the other developer already has the commits available in his repository he could always pipe it in himself without merging like this:
You can then add and commit the changes in the diff the usual way.
Now here comes the interesting part when you have to merge the patch back to the master branch (that is public). Consider the following revision tree where
C*is the applied patch fromCin the master branch:You can use
git-rebaseto update the topic branch (in this example namedfeature_foo) with it's upstream head. What that means is when you type in the following:Git will rearrange the revision tree like this and will also apply the patch itself:
Merging to the upstream branch will now be an easy fast-forward merge. Also check that the new commits
E*andF*work as the previousEandFrespectively.You can do the same thing against another developer's branch using the same steps but instead of doing it on a public repo, you'll be fetching revisions from the developer's repository. This way you won't have to ask the other developer for a patch if it is already available from what he published at his repo.
Please note to never rebase a public branch because the command will rewrite git history which is something you don't want to do on branches that people depend on and will create a mess when merging to remote repositories. Also never forget to integrate often so others in your team can take part of your changes.
在 SVN 中，您可以简单地进行更改，然后在提交之前，将 svn diff 的输出通过管道传输到文件，这样
您就可以恢复更改并在以后使用补丁应用补丁，
一如既往不要盲目地将补丁应用到您的代码并始终首先检查它们。
您还可能会发现，如果自打补丁以来源文件发生了足够大的更改，则该补丁会破坏您的源代码。
您也不能保证当您尝试签入代码时不会出现合并冲突。
In SVN you can simply make your changes then before commiting, pipe the output of the svn diff to a file as such
you can then revert your changes and apply the patch at a later date using
As always don't blindly apply patches to your code and always inspect them first.
You may also find that the patch will break your source code if the source files have changed significantly enough since the patch was taken.
You also can not guarantee that there will not be merge conflicts when you attempt to check in the code.
Bzr 处理发送“合并指令”，这意味着它会为您发送补丁，以便对方只需单击“确定”即可合并，并且可以减少补丁/应用等方面的麻烦。
只需：
$ bzr 发送 -o mycode.patch
Bzr handles sending a "merge directive", meaning it sends the patch for you so that the other party can simply click "OK" to merge and there's less futzing around with patch/apply etc.
just:
$ bzr send -o mycode.patch
在 Subversion 中没有好的方法可以做到这一点。 是的，您可以使用 svn diff + patch，但这只会推迟您的问题，直到您要合并为止，到那时您很可能已经忘记了它。
在 Subversion 中执行此操作的方法是创建一个分支，在该分支上进行提交并要求补丁的接收者切换到该分支。 然后你可以按照通常的方式将分支合并回主干。
In Subversion there is no nice way of doing this. Yes, you can use svn diff + patch but this will only postpone your problems until you are going to merge and by then chances are that you've forgotten about it.
The way you would do it in Subversion would be to create a branch, do the commit on the branch and ask the recipient of the patch to switch to the branch. Then you can merge the branch back to trunk in the usual way.