这带来的最大问题是你 * 应该 * 摆脱从旧的上游分支重写的修订，这样当你推送你的特性分支时，它们就不再存在了。
如果你尝试在新分支上重定你的分支（比如git checkout branchX; git fetch some-remote; git rebase some-remote/base-branch）git不仅会重定你的特性分支的修订版本，* 而且 * 还会重定那些已经从新的重写分支中移出的修订版本...这是一个不可行的。（合并或重组）不会让你摆脱困境......实际上，你很可能会把自己挖得更深。
如果你决定保留它们 * 就像什么都没发生过 *，你将进入 * 新的 * 上游分支的历史记录，这些修订已经从分支中删除了，而且 * 很有可能 *，没有必要保留它们（因为...为什么分支的历史记录一开始就被重写了，对吗？如果被重写了，那些旧的修订就不会再出现了）。
这看起来好像是一个大问题，但是坦白地说，摆脱这种情况并不难。诀窍是将你的特性分支的 * 仅仅 * 修订移到新的重写分支之上，而将旧分支留在后面。所以，这是一个过程，假设你的特性分支是一条没有合并的直线：
∮誓言∮
在 * 你的 * 特性分支的历史记录中找出（比如说，用git log或gitk或任何其他必要的方法），你的特性分支中的旧上游分支的最后一个修订版本，假设你得到了那个修订版本的ID，让我们称之为old-base-rev。
从远程获取以获得上游分支的新重写历史记录。

git fetch some-remote # adjust to the name of your remote, of course

∮转弯
这就是奇迹发生的地方：

git rebase --onto some-remote/base-branch old-base-rev branchX

这样git只会对feature分支本身而不是上游分支上的修订版本进行重定基。
∮威望∮
就这样，你可以继续在你的分支上工作，就像什么都没发生过一样。
□ □其他可能性
如果您正在处理一个 * 不 * 直的要素分支（它已经合并了上游分支，而不是重定基），你可以使用我提供的同样的方法，但是，如果你必须在合并上游分支时解决冲突，那将是棘手的。如果你想避免再次处理冲突，也许你能尝试的最好的方法是把你对你的特性分支的修改放到一个单独的版本中，然后尝试这个魔术。2在找到你的特性分支中 old base分支的最后一个ID之后：

git reset --soft old-base-rev
git commit -m "Single revision for feature X"

现在所有的修改都被压缩到old-base-rev之上的一个版本中了，然后就可以按照方法执行fetch/rebase步骤了。

git fetch some-remote
git rebase --onto some-remote/base-branch old-base-rev branchX