由于某种原因，每当我尝试使用rebase时，它最终都会丢弃我所有的功能分支提交。这是交互式基于母版显示的示例：
pick 05973319 First commit
pick 62341efd Second commit
pick e1c1a080 Third commit
pick 2b5285f7 Fourth commit
请注意，所有这些提交都是在功能分支上进行的。现在，当我退出交互模式时，由于冲突，重新设置失败。但是，$ git log不显示任何功能分支的提交。而且，如果我查看在功能分支中修改的文件，所有这些更改都将被丢弃。
我每次使用基于多个存储库的rebase时，似乎都会发生这种情况。在其他不存在冲突的情况下，Git只会删除我的所有更改并指出没有错。
我不明白这种解决冲突的方式在远程上是可以接受的。是否存在某种可能导致此错误的错误配置或反模式？请注意，与$ git merge master合并始终可以按预期进行。
答案 0 :(得分：4)
...现在，当我退出交互模式时，由于冲突，重新设置失败。
它尚未失败。在应用了零个或多个pick命令后，它已停止。
在任何现代Git中，git status命令都将告诉您，您现在处于尚未完成的交互式资源库中。 （在过去的糟糕时期git status并没有告诉您这些事情，您只需要知道或猜测。）
$ git log不显示任何功能分支的提交。
这表明问题发生在第一次选择樱桃时，因此，所有选择的提交都没有在进行中的，正在构建的分支中。也就是说，到目前为止，您的四个pick中有零个成功。 pick 05973319目前正在进行中，git status会告诉您，在Git弄乱了您的文件之后，哪些文件需要手工按摩才能修复。
您的工作就是修复它们-也许使用工作树中留下的混乱，也许使用git mergetool和一些喜欢的合并工具；该方法取决于您。但是 you 必须解决问题。修复它们之后，并在必要时运行git add，您的git status 1 会告诉您所有冲突都已解决，您应该运行git rebase --continue来完成对基准的确定摘下樱桃，然后转到下一个。下一个可能有也可能没有冲突。如果不是这样，Git将自行完成pick并继续进行到第三步，否则整个过程将重复。
这种变基行为是正常的，尽管这种变迁的普遍程度取决于您的工作模式和输入文件。有些人经常遇到它，有些几乎从来没有。
1 如果您使用git mergetool，通常会为您执行适当的git add。我更喜欢避免使用git mergetool：我将merge.conflictStyle设置为diff3，通常，只需要在工作树中留下的混乱中使用我的编辑器即可。设置diff3样式会将标记的冲突更改为包括 first 或基于合并的输入。默认样式仅保留 second ，--our和第三--theirs部分。因此，与我们及其版本不同的合并基础代码是不可见的，这有时使冲突非常难以理解。但这全都是个人喜好。