git - 当一个分支有另一个不想要的恢复时 merge git 分支

Question

我们正在开发两个版本，一个是次要版本，一个是主要版本，每个版本都有自己的 git 分支。在我们创建主要分支之前，最初将一个功能添加到次要分支。后来该功能从次要分支中删除(通过 revert 提交)，因为我们决定在主要版本中引入该功能。

所以现在我们有这样一种情况，如果我们将更改从次要分支 merge 到主要分支，它将包括还原提交，这在主要分支中没有意义。

我考虑过的一个选项是在还原提交后对次要分支中的提交使用 cherry-pick，但这有一个缺点，即任何基于次要分支的分支都不会可以与主要分支 merge 。 (对于类似的任何事情，我们必须继续使用 cherry-pick。)不过，它的优势在于更准确的历史记录，因为不包括还原提交。

另一种选择是将所有次要分支 merge 到主要分支中，只是“忽略”还原更改。通过“忽略”，我的意思是在进行 merge 时手动还原还原的更改。从 git 的角度来看，这更好地保留了历史记录，但可能意味着在 merge 过程中会出现一些困惑。

一般来说，我们只在主要分支中使用 merge ，并且仅在 merge 之前对最新代码进行挑选以调整修复。所以我倾向于选择第二个选项，但我想在这里了解这是否是处理这种情况的正确方法，或者我是否遗漏了什么。

编辑:这是 ASCII 艺术 :-)

*   (major)
| * (minor)
* | ...
| * revert feature on minor
* | major: unrelated commit
| * minor: unrelated commit
* |
|/
*   common ancestor
|
*   add feature to main branch

Answer 1

我很好奇你所说的“在主要分支中没有意义”是什么意思。您是否担心该功能会在主要分支上恢复？或者您只是因为标题为“还原功能”之类的提交将出现在主要分支的历史记录中而实际上该功能存在而感到恼火？

如果没有更多细节，很难说 merge 的结果是什么，但这里有一些可能性:

如果您的历史看起来像这样:

*   (major)
| * (minor)
* |
| * revert feature on minor
* | cherry-pick feature onto major
| * add feature to minor
* |
|/
*   common ancestor
|

然后你可以简单地将 minor merge 到 major 中，没有任何问题。

为什么？可以这样想:当你将 minor merge 到 major 时，你实际上是在获取共同祖先之间的差异(git merge-base major minor) 和 minor，将其作为补丁应用到 major 上，然后创建恰好同时具有 major 和 minor 的提交 作为 parent 。

共同祖先和 minor 之间的差异不会包含任何关于添加然后还原的功能的提示，因为这两个提交相互抵消了。因此，将引入 major 的唯一更改是由 minor 上的其他提交引起的更改。

如果您的历史是这样的:

*   (major)
| * (minor)
* |
| * revert feature on minor
* | merge minor into major
|\|
* | cherry-pick feature onto major
| * add feature to minor
* |
|/
*
|

那你就有问题了。在这种情况下，major 和 minor 之间的共同祖先是标记为“add feature to minor”的提交。如果您查看此共同祖先与 minor 之间的差异，差异将包括功能的恢复。当您将 minor merge 到 major 时，此差异将应用于 major，恢复 major 上的功能。

在这种情况下，有几种简单的方法可以避免丢失 major 上的功能:

• 将 minor merge 到 major 中，然后还原还原。生成的图表如下所示:

  *   revert the revert (major)
  |
  *   merge minor into major
  |\
  * |
  | * (minor)
  * |
  | * revert feature on minor
  * | merge minor into major
  |\|
  * | cherry-pick feature onto major
  | * add feature to minor
  * |
  |/
  *
  |
  

• 从 minor 中创建一个新分支。我们称它为 minor-for-merge。在此分支上，还原还原。然后将分支 merge 到major，删除分支。生成的图表如下所示:

  *     merge minor-for-merge into major (major)
  |\
  | *   revert the revert
  *  \
  |   * (minor)
  *   |
  |   * revert feature on minor
  *   | merge minor into major
  |\_ |
  *  \| cherry-pick feature onto major
  |   * add feature to minor
  * _/
  |/
  *
  |
  

两种方法都行。后者有点尴尬——提交还原还原有点悬在无人区——但它可以帮助您在 merge 到 major 时避免大量 merge 冲突。

无论采用哪种方式，minor 的任何分支都可以 merge 到 major 而无需恢复功能。如果 minor 的分支是在还原之前创建的，则还原不会在 merge 的历史记录中。如果 minor 的分支是在还原之后创建的还原(或者如果 minor 在还原后被 merge 到分支中)，那么还原仍然不会在被 merge 的历史中，因为该提交已经在 major 中的祖先。