如何保存git“正在重新设置基准”？

如果您是作为基础的一部分而处于冲突的合并中，那么您就会陷入困境。这就是为什么，如何以及可以做什么。

重新设置=反复摘樱桃

从根本上讲，Git中的rebase操作只是一系列的挑选操作。我们从这样的东西开始：

...--A1--A2--A3--A4--A5   <-- branchA
          \
           B1--B2--B3   <-- branchB

而我们最终会得到：

...--A1--A2--A3--A4--A5   <-- branchA
          \           \
           \           B1'-B2'-B3'  <-- branchB
            \
             B1--B2--B3   [abandoned]

我们（或Git）实现此目标的方法是使用git cherry-pick，或类似的方法，将现有的提交复制B1（将其转换为补丁并应用它）紧随其后A5，再复制B2至其后B1'，依此类推。

git cherry-pick对于您在说明中留下的每个“拾取”操作，交互式重新基准实际上会运行。非交互式rebase有几个选项，包括running git cherry-pick。

挑选承诺时，如果在应用承诺时存在冲突，Git可以使用三向合并。这仍然可能因冲突而失败。这将停止变基。或者，当使用交互式变基时，您可以选择“编辑”提交，在这种情况下，先提交并停止变基的Git Cherry-pick。无论哪种情况，Git都会留下足够的信息，供您稍后使Git恢复基准。

索引中有冲突

快速提醒一下，让我们注意，Git的索引是您构建下一个提交的位置。正常情况下每个文件的一个条目被提交，因此，如果你的下一个承诺将包括只有三个命名的文件README，file以及otherfile，将有三个索引条目。

请注意，索引与工作树是分开的，工作树包含正常的非Gitty格式的文件。与索引和存储库文件的内部Git格式不同，您可以编辑这些文件，对其进行编译，使用它们来提供网页服务，等等。（工作树还可以保存未跟踪的文件，这在重新设置基准期间并不重要。）

在发生冲突的合并期间，每个索引条目都会公开其各自的slot。每个条目最多有四个插槽，并且已编号。插槽零保存正常，无冲突的文件（如果存在），否则为空。插槽1-3（如果正在使用）包含三个必须解决的冲突部分。¹这些分别是基本版本（来自merge base），“本地”或--ours版本，以及另一个（--theirs或有时是“远程”）版本。您的工作是编辑文件的工作树版本，解决冲突，然后解决git add结果。这会将调整后的工作树版本复制到索引的插槽0中，从而清除插槽1-3条目。现在，文件已解决，可以提交了。

---

¹因此，要么插槽0被占用并且1-3为空，要么插槽0为空并且被占据1-3。在某些奇怪的情况下，插槽1、2和/或3也可以为空，例如，如果您遇到修改/删除冲突或添加/添加冲突，但通常为“ 0空意味着1-3已满”反之亦然。

---

但是只有一个索引

非常短语的指数意味着只有一个。这基本上是对的。

因为未合并状态在此（“ the”）索引中，并且只有一个索引，所以在完成解决冲突（然后进行提交）之前，需要使用该索引的任何其他操作都无法继续进行。

您可以根据需要简单地git add解决未解决的/未解决的项目和git commit结果，从而避免冲突。这里的缺点是Git不会保留哪些文件有冲突：您将清除插槽1-3条目，而Git会认为您已完成所有工作。

您可以保存索引-这是一个普通文件；您可以将其复制.git/index到其他地方。但是，由于它是具有各种特殊内部用途的二进制文件（索引也称为“缓存”，并且为了速度而缓存内部文件系统数据），这并不是非常安全。（如果Git有一种方法可以“导出”索引状态，然后在以后再次“导入”它，这样您就可以真正保存和恢复合并冲突状态。但是Git却没有。）

因此，为了安全起见，建议完全解决此冲突的合并状态。或者，如果您尚未开始解决，就什至不开始：那么就没有保存的工作。

你现在在哪

假设您开始我在上面绘制的“ B分支”变基，并且目前停留在复制commit的中间B2，但一些冲突尚未解决。这是您现在实际拥有的：

...--A1--A2--A3--A4--A5   <-- branchA
          \           \
           \           B1'  <-- HEAD
            \
             B1--B2--B3   <-- branchB

索引处于冲突状态。您还有一个“分离的HEAD”：Git正在以这种方式构建新的提交链。该名称HEAD指向所有已完成的提交。

如果您已经完成了一些解析工作，则应该完成它（因为保存未解析状态太难了），或者至少记下未解析的内容（因为您可以将文件添加到下一个提交中），然后运行git commit以创建提交B2'：

...--A1--A2--A3--A4--A5   <-- branchA
          \           \
           \           B1'-B2'  <-- HEAD
            \
             B1--B2--B3   <-- branchB

如果您尚未完成任何解析工作，则没有要保存的实际工作，因此请不要运行git commit。但是，无论哪种方式，现在是时候创建一个分支或标记名称，指向HEAD现在指向的同一提交：

$ git branch saveme    # or git tag saveme

现在您有了这个：

...--A1--A2--A3--A4--A5   <-- branchA
          \           \
           \           B1'-B2'  <-- HEAD, saveme
            \
             B1--B2--B3   <-- branchB

现在您可以：

$ git rebase --abort

这使得Git停止了重新设置基准的尝试，并移回至branchB：

...--A1--A2--A3--A4--A5   <-- branchA
          \           \
           \           B1'-B2'  <-- saveme
            \
             B1--B2--B3   <-- HEAD->branchB

现在，您已经保存了到目前为止所做的所有工作，可以返回并稍后重试重新设置基准。您拥有您（或Git）制定的解决方案B1'，如果您提交B2'，则您也拥有为此制定的解决方案。它们分别是commitsaveme~1和saveme；或者只提交一次saveme（如果只有一次提交）。