Question

我的git分支看起来像这样：

master-*-*-*-*-*-*-implement_x
 \                    \-*-further_foo_fixes_that_depend_on_x
  \                    \-*-*-further_bar_fixes_that_depend_on_x
   \
    \-implement_x_rebased

它以这种方式结束，因为我认为我的分支implement_x将按原样合并到上游，但我被要求将其压缩到单个提交，因此implement_x_rebased。但是，我已经启动了几个分支，以便在等待implement_x合并时等待我的工作进一步修复和开发。

现在我想重新调整implement_x_rebased的进一步工作。我认为这是一个无操作，因为implement_x和implement_x_rebased处于完全相同的状态 - 不存在合并冲突，仅应用implement_x和{{1}之间的更改在further_foo_fixes_that_depend_on_x之上。等等。然而，似乎git并不那么聪明，并且它试图从基础一路变换 - 引入不必要的合并冲突。

我认为最简单的方法就是将implement_x_rebased上的进一步修复加入并进行压缩，然后将它们藏匿起来，然后将条带应用到implement_x，但我很好奇是否有任何正确的方法让git意识到implement_x_rebased和implement_x实际上处于同一状态？

Answer 1

这似乎是--onto的{{1}}选项的任务。

git rebase

您可能希望查看git rebase manual中的git rebase --onto implement_x_rebased implement_x further_bar_fixes_that_depend_on_x示例。

Answer 2

解决此问题的一种方法是首先使implement_x和implement_x_rebased相同，例如：

git checkout implement_x_rebased
git merge implement_x

然后以正常方式合并你的进一步修复。

从代码的角度来看，implement_x的合并应该是一个NOOP（检查git diff implement_x implement_x_rebased实际上什么都不产生），但是你正在记录这两个被合并的事实，这将允许你轻松地完成其他任务。

如果它们不完全相同，您可能需要-s ours选项。这记录了合并已完成而不合并代码。 极度使用。

如果不这样做，您只需使用git rebase将后来的分支机构重新定位到implement_x_rebased。

这比挑选樱桃要好 a）你不需要挑选每个单独的提交，记得得到正确的订单等。 b）在语义上，你的git树之后更有意义

如何重新定位已经重新定位的分支机构

2 个答案: