3

我的 git repo 的历史看起来像：

* (topic2) commit_11
* (topic1) commit_10
* commit_9
* commit_8
* (HEAD, master) commit_7
* commit_6
* commit_5
* commit_4 <- I wanted to edit this commit.
* commit_3

所以我做了

git rebase -i commit_3

并在编辑器中替换pick为editcommit_4 。我更正了变量名中的一些拼写错误，然后

git add .
git commit --amend
(rename commit)
git rebase --continue

现在历史看起来像：

* (HEAD, master) commit_7.1
* commit_6.1
* commit_5.1
* commit_4.1 <- Edited commit.
| * (topic2) commit_11
| * (topic1) commit_10
| * commit_9
| * commit_8
| * commit_7
| * commit_6
| * commit_5
| * commit_4 <- Original commit.
|/
* commit_3

我想让我的历史像以前一样直截了当。我尝试了我之前多次成功使用的方式

git checkout topic1
git rebase master

但是在应用第一个补丁时会发生冲突。我手动解决了它们。但是当我尝试时git rebase --continue，它告诉我“没有什么可提交的”。

如何处理这个问题，为什么会出现？

4

1 回答 1

1

（我冒昧地修改了您的图表以表明当您变基时，所有提交都会更改，即使内容没有更改。您的新提交集将具有与原始提交不同的 shas。）

这里最简单的解决方案是使用--onto。看看这个链接，从文本“这里是你如何移植一个主题分支”开始： git rebase

因此，在您的情况下，它将是：

git rebase --onto commit_7.1 commit_7 topic1

换句话说，从commit_7之后直到（包括）topic1的提交，并将它们移植到commit_7.1。

但是，您可能仍然会遇到必须手动修复的合并失败。

我建议在执行此操作时，在 topic1 提交上创建一个额外的分支。称它为topic1old 什么的。如果变基不正确，这将更容易返回；您可以将您的 topic1 硬重置为该提交。

编辑：为什么没有简单的git rebase master工作？

如果你不告诉它， git rebase 假设你正在根据你的上游分支进行 rebase。

但是从我修改图表的方式可以看出，topic1 和 master 已经没有太多共同点了。如果您对 master 进行简单的 rebase，topic1 将尝试将您的所有提交 rebase 到 master 上的所有提交。这意味着你会得到类似的东西：

  • （主题1）commit_10
  • 提交_9
  • 提交_8
  • 提交_7
  • 提交_6
  • 提交_5
  • 提交_4
  • （头，主人）commit_7.1
  • 提交_6.1
  • 提交_5.1
  • commit_4.1 <- 编辑提交。
  • 提交_3

现在 Git 很聪明，不会重复已经存在的提交。显然，如果您更改了 X、Y 和 Z，然后稍后的提交再次进行了这些更改，Git 将忽略稍后的提交，因为这些更改已经存在。

但是让事情变得麻烦的是您对提交 4 的更改。结果是之后的所有提交都提交到了不同的代码集。这留下了进行大量合并的潜在必要性。

使用 --onto 可以解决这个问题，因为它允许您使用不同的基础。你是说：“我不关心 commit_4（因为我改变了它）也不关心 commit_5、_6 和 _7（因为我已经合并了它们，并且它们与我的主题分支中的基本相同）。因此，从 commit_8 开始，将这些更改重新建立在我已经处理过的内容之上。”

于 2014-04-23T20:43:44.073 回答