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

Question

我正处于一个巨大的“回扣进行中”与无数的冲突。
我想搁置这一进展，尝试用另一种方法解决这一问题。
有没有一种方法可以保存一个正在进行的回扣，以便我可以稍后完成它？

Answer 1

如果你坐在一个矛盾的合并作为一个回扣的一部分，你是有点卡住。这就是为什么，如何，以及你能做什么。
Rebase=重复樱桃采摘
从根本上说，git中的rebase操作只是一系列的cherry pick操作。我们从这样开始：

...--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'之后，等等。
Interactive Rebase字面上为您在说明中留下的每个“pick”操作运行 git cherry-pick。非交互式rebase有几个选项，包括运行 git cherry-pick。
当cherry选择提交时，如果在应用时有冲突，git可以使用三方合并。如果发生冲突，这仍然可能失败。这就阻止了回扣。或者，当使用交互式rebase时，可以选择“编辑”提交，在这种情况下，git cherry会选择提交，然后停止该rebase。在这两种情况下，git都会留下足够的信息，以便让git稍后恢复回扣。
索引中有冲突
作为一个快速提醒，让我们注意git的索引是构建下一个提交的地方。通常每个要提交的文件都有一个条目，因此如果下一次提交只包含三个名为 README、 file和 otherfile的文件，则将有三个索引条目。
注意，索引与工作树是分开的，工作树包含正常的、非gitty格式的文件。与索引和存储库文件的内部git格式不同，您可以编辑这些文件、编译它们、使用它们为web页面提供服务等等。（工作树还可以保存未跟踪的文件，这在重新定位期间并不重要。）
在冲突合并期间，每个索引项都会公开其各自的插槽。每个条目最多有四个插槽，并对其进行编号。槽零保存正常的、未冲突的文件（如果存在），否则它是空的。插槽1-3如果正在使用，则包含必须解决的三个冲突部分。1它们分别是基本版本（来自合并基版本）、“本地”或 --ours版本以及另一个或 --theirs或有时“远程”版本。您的工作是编辑文件的工作树版本，解决冲突，然后 git add结果。这会将调整后的工作树版本复制到索引中的slot zero中，删除slot 1-3条目。现在文件已解析并准备提交。
1因此，要么插槽0被占用，1-3为空，要么插槽0为空，插槽1-3被占用。有些奇怪的情况下，插槽1、2和/或3也可以为空，例如，如果您遇到修改/删除冲突或添加/添加冲突，但通常是“0空表示1-3已满”，反之亦然。
但只有一个索引
索引中的这个短语暗示只有一个。这基本上是真的。
因为未合并的状态是在这个（“the”）索引中，并且只有一个索引，所以在您解决冲突（然后提交）之前，任何需要使用该索引的操作都无法继续。
如果您愿意，您可以简单地 git add未修复/未解决的项和 git commit结果，以便排除冲突。这里的缺点是git不会保留哪些文件是冲突的：您将删除插槽1-3条目，git将认为您已经完成了。
您可以将索引保存为普通文件；您可以将其从 .git/index中复制到其他位置。但由于它是一个二进制文件，具有各种特殊的内部用途，因此索引也被称为“缓存”，它缓存内部文件系统数据以提高速度，这并不十分安全。（如果git有办法“导出”索引状态，然后稍后再“导入”它，这样您就可以真正保存和恢复合并冲突状态，那就太好了。但吉特没有。）
因此，为了安全起见（如果没有其他问题的话），建议完成此冲突合并状态的解决。或者，如果你还没有开始解决问题，甚至不要开始：那么就没有要保存的工作了。
你现在在哪
假设您启动了我在上面绘制的“branch b”rebase，并且当前正处于复制commit B2的过程中，有些冲突尚未解决。以下是你现在真正拥有的：

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

索引处于冲突状态。您还拥有一个“分离的头”：git正以这种方式构建新的提交链。名称 HEAD指向所有已完成的提交。
如果您已经完成了一些解析工作，那么您应该完成它（因为保存未解析状态太难了），或者至少记录未解析的内容（因为您可以将文件添加到下一次提交中），然后运行 git commit来创建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停止了rebase尝试并返回到 branchB：

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

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