如何从提交中获取补丁以将其发送给其他开发人员？在以后合并我们的树时，如何最好地避免与此补丁的合并冲突？
如果您知道如何在您选择的VCS中解释如何执行此操作，例如subversion，git，Mercurial，bzr等。
答案 0 :(得分：20)
在git中，您可以在两次提交之间管道git-diff的输出，如下所示：
git diff fa1afe1 deadbeef > patch.diff
将patch.diff发送给开发人员，让他git-apply将其发送到他的工作区：
git apply patch.diff
如果其他开发人员已经在他的存储库中提供了提交，他可以随身携带它而不会像这样合并：
git apply < git diff fa1afe1 deadbeef
然后，您可以add和commit差异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*是否分别与之前的E和F一样。
您可以使用相同的步骤对另一个开发人员的分支执行相同的操作，但不是在公共存储库上执行此操作，您将从开发人员的存储库中进行fetching修订。这样，如果补丁已经从他在回购邮件中发布的内容中获得，那么您就不必向其他开发人员索取补丁。
请注意永远不会重新绑定公共分支，因为该命令会重写git历史记录，这是您不希望在人们依赖的分支上执行的操作，并且在合并到远程时会造成混乱库。也永远不要忘记integrate often，以便团队中的其他人可以参与您的更改。
答案 1 :(得分：2)
在SVN中，您可以在提交之前简单地进行更改，将svn diff的输出通过管道传输到文件中
svn diff > mypatch.diff
然后您可以使用
还原更改并在以后应用修补程序patch -p0 -i mypatch.diff
一如既往，不要盲目地在代码中应用补丁，并始终先检查它们。
如果源文件自修补程序以来发生了很大的变化，您可能还会发现修补程序会破坏您的源代码。
当您尝试签入代码时，也无法保证不会出现合并冲突。
答案 2 :(得分：2)
Bzr处理发送“合并指令”，这意味着它会为您发送补丁，以便对方只需单击“确定”即可合并，并且补丁/应用等方面的不足之处。
只是： $ bzr发送-o mycode.patch
答案 3 :(得分：2)
在Subversion中，没有很好的方法可以做到这一点。是的，你可以使用svn diff + patch，但这只会推迟你的问题直到你要合并，那么你可能已经忘记了它。
在Subversion中执行此操作的方法是创建分支，在分支上执行提交并要求修补程序的收件人切换到分支。然后你可以用通常的方式将分支合并回主干。