我正处于git rebase的中间。我所依据的分支有很多更改，涉及到与我修改过的相同代码。我花了很多时间在基础上工作，我快要完成了。但是我在现在正在处理的提交中添加了一个新功能，该功能不再起作用。我写此功能的方式与现有功能类似，并且可以看到现有功能的功能已由我根据其改编的代码进行了更改。
我想找到更改现有功能的提交。我想先检查一下最后一次提交，然后再开始编写代码，以确保确实更改了现有功能。但是，当我尝试签出其他提交时，出现一条错误消息，告诉我我需要从合并的当前步骤中合并文件，并且需要首先解析当前索引。但是，直到弄清楚现有功能的修改方式之后，我才能解析当前索引。我该怎么办？
答案 0 :(得分：1)
您有两个评论（至少到目前为止）是在此处继续前进的关键。
已暂停（出于任何原因，包括交互式变基“编辑”选项）的变基工作树处于分离式HEAD 模式。这是一种微妙的状态，干扰这里的HEAD设置（其他分支或提交的git checkout会这样做）是不明智的。
由于合并冲突而暂停的rebase更加糟糕：它不仅具有断开的HEAD模式，而且 index 处于冲突状态。由于索引对于提交至关重要，因此您可以使用此工作树执行的 only 操作要么解决冲突并继续，要么终止重新设置基础，然后将所有内容放回开始的方式。
您不想执行这些操作：您想要完成重新设置基准，因为：
我花了很多时间进行基准测试，我快要完成了。
那么，解决方案是获得一个不同的工作树。
在现代Git（自Git 2.5版开始）中，有一个命令git worktree，带有用于创建新工作树的子命令。每个工作树都有其自己的HEAD和其索引。这意味着您可以将现有的存储库完整地保留在原处，并具有正在进行的rebase及其分离的HEAD和可能有冲突的索引，而只需添加一个具有其他分支已签出的新工作树即可。
自git worktree的2.5版本以来，已经发现了许多错误；在固定this rather nasty bug之前，大约要在Git 2.15左右才使用它。 1 对于查看另一个分支，甚至是Git 2.5版本还可以。
如果您的Git版本早于2.5，或者您对上述错误感到不安，则只需克隆现有的存储库即可。与添加的工作树相比，克隆要花更多的磁盘空间和时间，但花的时间并不多，并且它们可以在每个版本的Git中工作。
1 我自己被这个虫子咬了。但是，值得注意的是，如果您的对象（git gc可能认为未引用的对象）早于修剪过期时间（默认为14天），这是无害的。寿命短的侧面工作树通常不会触发这些git worktree错误（此错误和其他一些错误固定在2.5和2.15之间）。