问题的措辞（“重新基于......其他东西”）表明您要么不确定，要么不相信什么fork-point应该做的。如果我们从清楚地了解它的作用开始（如果我们假设它工作正常并且没有破坏性的副作用），那么使用它作为默认值的动机可能看起来更清楚。
（说实话，我从来没有费心去弄清楚什么fork-point在看这个问题之前先做。最好的解释似乎是在git merge-base文档 -https://git-scm.com/docs/git-merge-base https://git-scm.com/docs/git-merge-base.)
在深入讨论之前，先看两个“大局”观察：
1）我认为 git 开发人员不会同意使用fork-point意味着你正在“针对其他东西重新建立基础”；我想他们可能会说你仍然在针对上游进行 rebase，但是对于在新基础上重写哪些承诺更加有选择性。
2) 同时fork-point可能并不总是有用，我不清楚在什么情况下它会导致你的提交消失[1]。看到任何显示问题的最小测试用例将会很有趣（因为上面我提到“假设没有破坏性的副作用”作为认为这是一个合理的默认值的条件）。
所以进入其中...
fork-point 试图做什么？
简短的答案是，如果提交以前是上游的一部分，并且通过历史编辑从上游删除，那么--fork-point告诉 rebase 留下该提交，因为 (1) 它实际上不是分支的一部分，(2) 它已经被上游拒绝，以及 (3) 我们可能不会尝试撤消某人的历史重写。
它通过从转发日志中推断信息来做到这一点。因为重新登录是本地的、临时的，所以这有点混乱；您尝试变基可能会得到与其他人尝试在看似相同的存储库克隆中执行相同变基的结果不同的结果。
如果您的引用日志似乎表明您的提交实际上曾经是上游的一部分，那么这可能会导致问题。
那么为什么要使用它作为默认值呢？
我想底线是，开发人员假设如果提交之前位于上游并从上游删除，则该删除是确定的。这是否“通常是正确的”可能取决于开发人员。
奇怪的是，中使用的示例merge-base文档（上面引用的）看起来很奇怪。它显示上游为origin/master，这意味着在某个时刻遥控器的master被重写 - 这是上游变基情况，通常不鼓励这样做。
由于不相关的原因，我习惯在变基时总是指定我的上游。这意味着，取决于您如何看待它，我错过了违约的好处和/或永远不会遭受违约的风险fork-point option.
[1] 我确实提出了一个潜在的案例，但我不确定您是否遇到了这种情况。如果你在 master 上，并且开始开发一个功能，只有在提交之后你才意识到你忘记了创建功能分支；所以你“就地”创建分支然后倒回master取消混合您的更改；然后使用分叉点重新调整功能来掌握可能会做错误的事情。
一种可能对这种情况有所帮助的解决方案是，在倒回 master 之后，您可以执行强制变基，以从不在 master 引用日志中的新提交重新生成分支。
