【问题标题】:Rebase not behaving as expected变基行为未达到预期
【发布时间】:2017-12-14 06:28:06
【问题描述】:

我想从我的分支的历史记录中删除一长串提交。我用过 git rebase -i

然后我用fixup 标记了一些提交,认为它们会被应用但没有提交信息。我还将一些标记为squash,认为它们会被应用,但它们的提交消息将与之前的提交消息合并。我留下了一些 pick,以为他们会保持原样,或者将他们的追随者 squashfixup 合并到他们中。

根据需要标记它们后,我输入 Esc :wq,点击 return 并进入第二个编辑器屏幕。在这里,我只需点击Esc :wq 并再次点击return

没有报告任何问题,所以我输入了git push。 Git 抱怨我不先拉动就无法推动,所以我输入了git pull,然后输入了git push。这似乎满足了 git 之神,但随后查看 git log 我看到我想要压缩在一起的提交消息被压缩成一条消息,不幸的是所有原始提交消息仍在日志中。

我以为他们会被删除。

我做错了什么,我误解了这个过程吗? 当我将我的分支合并到 master 时,那些 fixup-ed 提交消息会被合并还是会消失?

【问题讨论】:

  • (警告不要匆忙这样做)我相信你想要git push --force而不是git pull。这将覆盖 overwrite 远程分支的历史记录。当你变基时,你自然会与远程存储库不同步。
  • 这听起来正是我想要的。幸运的是,我所做的更改并不难重做,但我想了解为什么日志似乎显示了我认为不再存在的提交消息。

标签: git merge rebase


【解决方案1】:

因为你已经推送了之前的历史,你的分支和远程分支会偏离你的变基点。运行git status会显示你的分支和远程分支已经发散了,这就是不允许push的原因:

A---B---C---D---E---F origin/feature
         \
          D'---E'---F' feature

当您在这种情况下发出拉取请求时,它将合并历史的两个版本,因此您的旧提交(来自远程)仍然存在,以及您的新的、重新定位的提交:

A---B---C----D----E----F origin/feature
         \              \
          D'---E'---F'---G feature

可能想要git push --force完全改写这段历史,但这样做存在许多风险:Safe force push procedure?

如果你这样做,你会得到这样的结果:

A---B---C---D'---E'---F' feature
                         origin/feature

在这里,旧的提交 (D-E-F) 不再属于您的分支,稍后将被清理。 (它们可能作为其他分支的一部分保留在 repo 中,或被标签引用,但它们将不再出现在您正在处理的分支的历史记录中。)

【讨论】:

  • 所以,只要没有其他人推动就安全了?就是这样,这里。
  • 强制推送通常很困难,因为它需要评估和重新定位所有可能受到影响的分支(包含旧提交的分支)。如果你是唯一一个在这个 repo 上工作的人,这是安全的,但你仍然需要考虑其他分支是否会受到影响。
  • 我的问题仍然存在:这些提交消息会被删除吗?
  • 是的,您完全覆盖了该分支中的历史记录,因此 D/E/F 提交将不再存在。 (这并不完全正确;例如,如果有一个指向 F 的标记,那么提交仍然存在,但它们不再是您的分支的一部分。)
猜你喜欢
  • 1970-01-01
  • 2014-09-29
  • 1970-01-01
  • 1970-01-01
  • 2020-08-02
相关资源
最近更新 更多