时间戳

首页 > 解决方案 > git rebase 重新散列未触及的提交

git - git rebase 重新散列未触及的提交

问题描述

情况

这些是我分支中的提交哈希。PUSHED 提交是公共 master 的一部分，它是我的分支的基础。其他提交尚未公开。

PUSHED_A - PUSHED_B - mywork_A - mywork_B - correction_A

现在，我曾经git rebase -i将 Correction_A 重新排序并压缩到 mywork_A 中。
我理解为什么 mywork_A 和 mywork_B 在变基后有一个新的提交哈希。

但是现在连 PUSHED_B 也有了新的哈希值。哈希现在看起来像这样

PUSHED_A - PUSHED_B2 - mywork_A2 - mywork_B2

恐怕这会使我的分支很难正确地合并到公共主分支中，因为 PUSHED_B2 不被识别为已经存在的 PUSHED_B 并且会导致问题。

我纠正了这一点（新分支，樱桃采摘......）但我不了解背景。

为什么会这样？

我查看了 PUSHED_B 和 PUSHED_B2 的提交内容。没有区别。

也许我在做 rebase 时将 PUSHED_B 带入了提交列表，选择 HEAD~x 太大。但是我没有修改这个提交，也没有在它之前重新排序。因此，即使它是列表中提交的一部分，也不应该保持原样吗？

我可以追溯发生的事情和发生的时间吗？

标签： gitrebase

解决方案

请注意，某些形式的git rebase尝试注意到特定的现有提交可以被重用，然后将重用该现有提交（通过“快速转发”）。如果您不希望这种情况发生，请git rebase提供禁用它的选项。 其他形式的git rebase不太注意这一点：实际上，这些选项总是打开的。您似乎使用了不太谨慎的变基形式。

文档的BEHAVIORAL DIFFERENCES 部分git rebase提到了三个“后端”内部实现：am（使用git format-patch并git am完成复制，而不是挑选提交）、合并（使用挑选提交）和交互（使用樱桃挑选，但首先会生成一个您可以编辑的指令表，并且变得非常漂亮）：

  • am后端是不太小心的形式。这也是默认设置。
  • 如果您提供、或选项，前端git rebase命令将切换到合并后端。-m-s-X
  • 如果你使用 .前端git rebase命令切换到交互式后端-i。

在大约一年前的 Git 中，rebase 主要是作为 shell 脚本编写的，并且更容易判断哪个 rebase 做了什么。新的是 C 语言，更加不透明。该-p选项用于我们的交互式后端，但不是交互式的，也许仍然如此；或可能也-r。--rebase-merge很明显，两者都没有使用旧的am后端，并且从文档中的描述来看，-k也不能使用am后端。

正如kan 所说，您可以重新设置基准以将两个必须不同的提交放回原始提交序列的顶部。或者，正如您所做的那样，您可以git cherry-pick手动使用，这使您可以完全控制每一步，但代价是需要完全控制每一步。:-)

推荐阅读