Question

在Progit中说：

如果你希望Git尝试更智能地解决问题冲突，你可以传递-3选项，这使得Git尝试三方合并。默认情况下，此选项未启用，因为它不会如果修补程序说它基于的提交不在你的工作中库。如果你确实有这个提交 - 如果补丁是基于a 公共提交 - 然后-3选项通常更聪明应用有冲突的补丁：

和

这种方法的另一个优点是你可以获得历史提交也是如此。虽然您可能有合法的合并问题，你知道你的工作历史在哪里;适当的三方合并是默认的，而不是必须提供-3并希望补丁是从您有权访问的公共提交中生成的。

这是否意味着我可以将我的补丁基于我的私人提交？我想知道它会有什么意义，因为它会在合并时导致明显的冲突，因为提交补丁的文件基于贡献者的方面与我现在的文件看起来不同，所以如何将它们合并？从项目维护者的角度来看，Progit对这些内容进行了描述，因此贡献者不会将他的补丁基于某个开发秘密分支。

Answer 1

更改很容易基于私有提交，只要更改是非冲突的，它就会适用。

考虑：

A                   master
\--------B-----C    HEAD

A是上游（公共）主人; B和C是对私人分支的承诺。您可以生成从B到C的补丁，如果A..B和B..C没有冲突，它将应用于上游公共提交A.

更礼貌的事情是重新排序你的提交：

A                   master
\--------C-----B    HEAD

并提交补丁A..C。如果这是不可能的（例如，因为中间阶段提交已在本地发布），您应该能够将提交选择到专门准备上游提交补丁的分支中：

A                   master
\--------B-----C    HEAD
\--------C'         upstream-request

Answer 2

我不确定你的'私人提交'是什么意思;在本地存储库中提交？这几乎总是你将从中提交补丁。

您希望基于公共分支在您的存储库中创建一个分支，该分支仅包含您要向上游提交的提交。从该分支创建一个format-patch的补丁。然后上游可以最容易地应用补丁。