如果每个分支都引用了它的初始基本提交（比如） ，那么git 上游 rebase “硬案例”问题是否会得到解决branch@{base}？
这个初始的基本提交（branch.<name>.base例如，存储在配置文件中）将首先是分支最初创建时指向的那个。
然后，任何git rebase new_base_commit branch人实际上都可以git rebase --onto new_base_commit branch@{base} branch在更新branch@{base}到new_base_commit.
它只会自动化文档的“硬案例”解决方案。
我想如果这样一个简单的解决方案还没有实施，应该有充分的理由不这样做。既然我什么都看不到，那一定意味着我误解了什么。
那么，如果有，这些原因是什么？
编辑：阅读bk2204 的回答让我意识到这种行为只会对跟踪分支的特殊用例有用和预期（我应该早点意识到，因为它是关于上游变基的），所以应该记录初始基数只用于跟踪分支，仅用于使用隐式的命令@{upstream}，例如git rebase不带参数的命令。
编辑：我刚刚发现实际上，git pull --rebase并且git rebase已经使用 的算法做了类似的事情git merge-base --fork-point，但后者使用可以被垃圾收集的 reflog 来动态计算分叉点。
所以我仍然想知道：为什么不简单地将它存储在旁边branch.<name>.remote呢branch.<name>.merge？
例如，当用户开始跟踪另一个分支*时，可以使用 和 来计算分叉点git merge-base --fork-point upstream local并将其存储在git config branch.local.forkPoint（或任何其他名称）git config branch.local.remote下git config branch.local.merge。
然后，当用户执行 agit pull --rebase或 agit rebase时，它可以做**：
git rebase --onto local@{upstream} `git config branch.local.forkPoint` local
如果用户尝试执行 agit pull或 a git merge，它可以首先检查local@{upstream}没有重新设置基础，使用：
git merge-base --is-ancestor `git config branch.local.forkPoint` local@{upstream}
如果它被 rebase，它可能会中止，并建议改为执行 rebase 或编写完整的合并命令来强制它（例如）。
编辑：我认为，为了能够正确处理文档此页面中“变基的危险”中描述的情况，当使用合并而不是变基将分支“同步”到其上游时，最后一次“同步”点”应该被检查以验证上游也没有从那时起重新定位。
因此，每个git pullorgit merge还应该在应用合并后将来自上游分支的合并父提交存储在某个地方（比如branch.local.lastSyncPoint可能）。在应用合并之前，它还应该检查：
git merge-base --is-ancestor `git config branch.local.lastSyncPoint` local@{upstream}
实际上，它可以使对分叉点的检查无用。
编辑：此外，我认为变基应该丢弃从最后一个“同步点”可到达的所有提交，这些提交未包含在（变基）上游（local@{upstream}..`git config branch.local.lastSyncPoint` ）中。在丢弃提交的情况下，它将使其按照预期工作。
* 带有git switch --create local --track upstream或git checkout -b local upstream或git branch --track local upstream或git branch --set-upstream-to upstream local
** 而不是即时：
git rebase --onto local@{upstream} `git merge-base --fork-point local@{upstream} local` local