Git terminal在重设基础期间随机尝试删除大部分/所有修改的文件

==更新：====

之前的更新说，将我的终端升级到当前版本解决了这个问题。但是今天又发生了，显然不是这样

///////////////////////////////////////////////////////////

原始问题：

这是随机发生的，但每当我尝试重新设置当前正在处理的分支的基础时，git有时（但并非总是）会告诉我存在合并冲突，

git status

会告诉我，我修改的大多数文件都会在冲突中被删除。实际上，检查这些文件表明它们实际上已经不存在了，但是在I

中止之后，所有内容都会返回，一切正常

我这样做了2-3次，有时，
rebase
实际上会正确发生，没有任何冲突，或者它会返回一个实际的合法冲突，我可以修复该冲突，
——继续，而不会发生意外


这就是我问题的要点。如果它只发生过一两次，我不会有任何想法，但它发生得越来越多，现在大约有80%的时间我在尝试重新设置基础时遇到了它，它影响了我的周转时间（和理智）

我绝对不是git大师，所以我不太明白问题的根源可能在哪里，但我最好的猜测是发生了某种种族状况。到目前为止，我刚刚尝试过使用
git-gc
（有时是
——侵略性的
），但我很怀疑它是否对这种情况发生的频率有多大影响

我通常在任何给定时间在10-15分支之间切换工作。我要重新调整的上游/主节点每天的合并次数在5-30次之间，这取决于事情的繁忙程度。我不知道这些细节是否与我的问题有关，但这就是问题所在


抱歉，如果这有点冗长。。。只是想确保我有足够的信息来说明我的问题

谢谢

============回应torek==========


您提到，当文件/文件夹在两端被实际删除或重命名时，可能会出现问题。如果我有一个修改了6个文件的分支，我的合并冲突将表明6个文件中的5个（或全部6个文件）在冲突期间已被删除，但我可以在
中止
后验证任何一端的文件均未被删除或重命名。尽管如此，它确实让我想到了你提到的第三个参考提交（最近的聚合点）。如果在获取提交时出现问题，是否会在git可能解释为删除所有文件的过程中造成某种干扰

虽然我不能直接谈论团队合并习惯的“纪律”，但我倾向于说事情是相当整洁的。我还可以说，据我所知，我是10人团队中唯一遇到这些问题的成员，直到几个月前，我还没有遇到任何这些问题


===============更多说明===========

当我们向主分支提交拉取请求时，公司的政策是我们的PRs始终只包含一个提交。因此，我们只是在工作时修改提交，而不是将多个提交堆叠到一个分支上

这仅仅意味着在git倒带之后的
重设基址期间，它只会重放来自工作分支的当前/最新提交。实际上，没有多次提交需要重新应用


我还要再次重申，如果出现“所有内容都被删除”的冲突，我会这样做：
abort
，
rebase
，冲突，
abort
，
rebase
，冲突，
abort
，
rebase
，“成功”。这就是我目前解决问题的方式，所以我很确定“发生了一些奇怪的事情”。
这绝对不是比赛条件（或者至少，不是你想的那种）

下面的内容很长，但可能会有所帮助。它不会解决问题，但可能会让你有所收获

背景：rebase是一种樱桃色的类固醇
当您执行rebase时，实际上是在执行一系列的
git cherry pick
操作。下面是提交图的一个简单示例图，您正在处理
功能
，并将其分支如下：

... *         <-- foo, origin/foo
     \
      A - B   <-- HEAD=feature

            A' - B'  <-- feature
           /
... * ... o          <-- origin/foo
     \
      A - B          <-- [abandoned]

（您的分支标签
foo
仍然指向标记为
*
的提交，直到您将其快进以匹配
源/foo
，因此我们现在将其忽略）。此时，您可能会选择执行重基，以使您的
功能-a
脱离新提示提交
o
，这样您将得到如下图形：

... *         <-- foo, origin/foo
     \
      A - B   <-- HEAD=feature

            A' - B'  <-- feature
           /
... * ... o          <-- origin/foo
     \
      A - B          <-- [abandoned]

cherry pick
所做的是将提交您的名字（
功能~1
，或者您可以将提交
A
，或任何东西的原始SHA-1）与该提交的父级（提交
*
在我们的图形中）。结果的差异是“更改为提交
A
的内容”，然后git尝试将其作为补丁应用于当前分支提示提交（
o
）。如果补丁运行良好，git将通过复制原始分支提示提交消息（即，从提交
a
复制消息）来进行新的提交

如果一切顺利，您只需使用commit
B
重复
cherry pick
操作，以便git生成一个新的
B'

git-rebase
命令简单地自动化了所有这一切（如果您不使用
-i
，则完全自动化；如果您使用
-i
，则交互自动化）：它查找commit
*
，签出一个新分支技术上是匿名签出，一个“分离头”，因此没有分支名称，但工作原理相同?
... * ... - o   <-- HEAD
     \
      A

              A'  <-- HEAD
             /
... * ... - o
     \
      A - B

git diff merge-base A'

    opts.rename_limit = o->merge_rename_limit >= 0 ? o->merge_rename_limit :
                        o->diff_rename_limit >= 0 ? o->diff_rename_limit :
                        1000;
    opts.rename_score = o->rename_score;

remote: A <-- B <-- C
local: A <-- D <-- E

remote: A <-- B <-- C
local: A <-- B <-- C [D, E]

remote: A <-- B <-- C
local: A <-- B <-- C <-- D'