Git：合并来自分支的部分更改

Question

我们已经在一个工作分支上工作了一段时间，打算在某个时候将它带回我的主要分支。

与此同时，该工作分支通过与主分支的频繁合并保持最新。

现在事实证明，我们只想将该工作分支的一些更改（但不是全部）带到主分支。

这里的困难在于，这些更改根本没有很好地按提交或文件分开，因为从来没有人期望必须这样做。相反，单个提交会在我的主分支上带来我们想要的更改，以及我们不希望在我的主分支上进行的更改。可以在任何给定的单个文件中查看两种更改的实例。

现在，仍然有可能最终我们会按照原计划将该工作分支最终合并回主分支。所以我需要保持这种可能性，它需要提供一个很好的保证，确保一切确实按计划合并——或者至少是一种检查的好方法。

正因为如此，我觉得

git cherry-pick

（假设它可以下降到文件中的单个大块头的级别）不是我想要的选项，因为一方面来自工作分支的所有原始提交，以及另一方面，在主分支上通过 cherry-picking 生成的提交都将是愚蠢的冲突，看起来两个分支都带来了相同的变化。此外，由于重复的日志注释，日志看起来会非常丑陋。

我宁愿有一个单一的提交说“从工作分支带来与 X 和 Y 但不是 Z 相关的所有更改。”。然后一段时间后，如果我们这样选择，另一个提交说“从工作分支带来剩余的更改，主要是关于 Z”。我想理想情况下最后一个会有两个父母，但我不知道第一个最理想的是什么：它是否应该在工作分支中作为其父母进行一些提交？所以

merge

-like而不是

cherry-pick

-like.

与此同时，如果我决定进行实际的

merge

创建第一个提交，我将不得不手动删除主分支代码中的内容，以忽略可能来自工作分支的关于 Z 的更改通过这个

merge

。但是，由于第一次提交会将工作分支的尖端作为其父分支之一（这是一个实际的

merge

），所以在 git 看来，第一次提交包含工作分支中的所有更改 - 但那不会是真的。

可能是我把自己置于 git 无法干净地或原生地解决的情况，如果是这样的话，我想知道，我会接受的。我仍然会对其他会破坏我的一些要求的降级解决方案感兴趣。

Answer 1

你最好的选择是：

还原的更改现在可以存在于功能分支上，直到决定也将它们合并，或者如果它们仍然不需要，可以放弃它们。

Answer 2

方法一：

根据当前

partially-merge-feature-into-main

创建并签出新分支

main

方法 2

Answer 3

这里有一个完全不同的方法。由于您的提交历史已经一团糟，请放弃并清理它：

你可以在这一点上停下来，用 stash 保存你以后可能会或可能不会合并的东西。但是，如果您打算进一步开发该材料，那么，仍然在 main 上，创建一个新分支并切换到它，弹出存储并添加所有内容并提交。您现在有一个等待中的功能分支，仅包含您以后可能会或可能不会合并到主分支的内容。