使用Git Rebase和导出修复合并冲突

Question

我已经遇到了一些与git rebase的合并冲突。

我的问题是，如果我解决了冲突，那么我应该做这样的事情吗：

git add files
git commit "fixed merge conflicts"

然后继续

git rebase --continue

我的另一个问题是，如果我搞砸了，我可以做吗

git rebase --abort 

并会删除所有提交吗？

Answer 1

根据您对jready答案的 评论 ，您真正的问题是您是否应该将原始的提交链保存在某个地方/以某种方式保存。

在某种基础上，Rebase可以通过复制进行工作（因为无法更改提交，这包括其向后的链接）。 分支名称只是指向某些特定的提交。 如果我们将提交绘制为图形中的节点，那么我们将如下所示：

...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch

如果您运行git checkout your-branch && git rebase origin/whatever ，则Git必须复制提交J ，方法是将提交J转换为一组更改（相对于其父G ，并将这些更改应用于提交I （其中origin/whatever指向）。 将J复制到J' ，它将尝试将K复制到新的提交K' ，依此类推。 在解决了所有冲突之后但在Git“剥离名称”提交L之前，最终结果是：

                J'-K'-L'  <-- HEAD
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch

的最后一步git rebase是删除名字your-branch从那里现在粘贴，指着犯L ，并使其指向，而不是犯L'是底垫制成-the最后一个副本：

                J'-K'-L'  <-- your-branch (HEAD)
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   [abandoned]

如果您使用git rebase --abort而不是继续，那么Git只会放弃复制的链，而your-branch名称仍指向L ：

                J'-K'-L'  [abandoned]
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch (HEAD)

在开始重新设置基准之前，或者在your-branch的中间任何时候your-branch仍然指向提交L ，您都可以添加一个新名称来记住提交L的原始哈希ID：

                J'-K'  <-- HEAD
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- your-branch, extra-name

例如，您可以使用git branch extra-name your-branch 。 这样，在完成变基之后，假设您完成了变基，您将得到：

                J'-K'-L'  <-- your-branch (HEAD)
               /
...--F--G--H--I   <-- origin/whatever
         \
          J--K--L   <-- extra-name

你不必这样做，因为偷偷git rebase设置了一个特殊的名字， ORIG_HEAD ，记住您的分支的名字是前猛拉其关闭L并粘贴它放到L' 。 但是名称ORIG_HEAD将被您稍后使用的任何其他Git命令（可能是另一个重新设置）覆盖，该标签会像这样晃动标签，因此这是一种短期的权宜之计，您可以在不喜欢的情况下进行恢复结果。

您的Git还在分支的reflog中记录了分支名称的先前值，即your-branch以前指向提交L而不是L'的事实。 这些reflog条目持续30或90天。 ¹它们不是最容易使用的东西：

git reflog your-branch

会溢出所有这些信息，但是您得到的是每次提交中使用的单行摘要，并且当您使用git rebase ，通常将原始的单行摘要从提交L复制到提交L' ，因此可以很难说是哪一个。

尽管如此， ORIG_HEAD和reflogs的某种组合通常会使您无需额外名称即可恢复。 如果使您更舒适，请使用多余的名称。 我做了很多事情：如果我正在使用feature/X ，并且需要重新设置feature/X.0 ，那么我将创建feature/X.0然后重新设置feature/X.0 。 我的原始提交系列现在可以作为零点版本了。 几天后，如果需要再次进行基准调整，请创建feature/X.1 ，然后进行基准调整。 因此feature/X是最新版本， feature/X.<number>是较旧的版本，还有更多较旧的版本，直到我将它们收集起来并自己扔掉为止。

---

¹从技术上讲，那些在30天内到期的文件将使用expireUnreachable时间：这些是从引用的当前值无法达到的提交。 Rebase通常会提供这种参考，因此默认的30天到期时间是您应该关注的时间。

（ 可以访问的Reflog条目将默认为90天。）

Answer 2

git rebase --abort将完全退出rebase，从本质上将您的存储库恢复到开始rebase之前的时间点。 唯一丢失的提交将是git rebase创建的全新提交（因为git rebase 重播了原始提交，因此形成了新提交）。

无论您是否中止，都不会触及原始提交。