0

在Progit它说：

如果你想让 Git 更智能地尝试解决冲突，你可以传递一个 -3 选项给它，这使得 Git 尝试三向合并。默认情况下，此选项不启用，因为如果补丁所基于的提交不在您的存储库中，则该选项不起作用。如果你确实有那个提交——如果补丁是基于公共提交的——那么 -3 选项通常更聪明地应用一个冲突的补丁：

和

这种方法的另一个优点是您还可以获得提交的历史记录。尽管您可能有合法的合并问题，但您知道他们的工作在您的历史中的哪个位置；正确的三向合并是默认设置，而不是必须提供 -3 并希望补丁是从您有权访问的公共提交中生成的。

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

4

2 回答 2

3

更改可以很容易地基于私有提交，并且只要更改不冲突，它就会应用。

考虑：

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

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

更有礼貌的做法是重新排序您的提交：

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

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

A                   master
\--------B-----C    HEAD
\--------C'         upstream-request
于 2012-07-03T16:57:26.000 回答
0

我不确定您所说的“私人提交”是什么意思；在您的本地存储库中提交？这几乎总是您将提交补丁的内容。

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

于 2012-07-03T16:49:00.057 回答