Git重写master分支旧提交后如何让所有关联分支同步变更？

现有操作评估 #

你当前的操作没有错误，只是只完成了master分支的历史重写，没有处理下游关联的Feature分支。
Git的交互式rebase本质是复制旧提交生成带新哈希的新提交，只会修改执行命令时所在分支的提交指向，不会自动更新其他从旧提交分叉的分支，所以切到Feature看到旧历史是重写过程中的正常中间状态。
注意你在修改B提交后，原B后面的C提交因为父节点变更，实际哈希也已经变化（只是内容和原来一致，标记为C'），此时本地的真实提交结构是：

A - B' - C' (master)
 \
  B - C - D - E - F (Feature)

全分支同步修改的操作步骤 #

所有基于旧提交链分叉的下游分支，都需要通过rebase --onto把分支独有的提交迁移到新的提交链上，Git没有自动同步的机制，具体操作：

1. 先查两个关键哈希：在master分支通过git log --oneline查到修改后生成的B'、C'的哈希，在Feature分支查到旧B、旧C的哈希。
2. 迁移Feature分支到新提交链，执行命令：

   # 如果Feature是从旧B节点分叉的用这个
   git rebase --onto <B'的哈希> <旧B的哈希> Feature
   # 如果Feature是从旧C节点分叉的用这个
   # git rebase --onto <C'的哈希> <旧C的哈希> Feature
   

   命令逻辑是：取出Feature分支上所有比指定旧基点提交新的独有提交，整体剪切后拼接到新的目标提交后面。如果过程中出现冲突，正常解决冲突后执行git add <冲突文件>，再跑git rebase --continue即可走完流程。
3. 所有分支迁移完后，执行git log --oneline --graph --all查看全分支提交图，确认最终结构符合预期：

   # Feature从B分叉的最终结构
   A - B' - C' (master)
         \
          D' - E' - F' (Feature)
   

强制推送到GitHub的防混乱规范 #

1. 推送前必须做本地校验：通过上面的git log全分支图确认所有分支都已经挂到新的提交链上，没有分支还指向旧的B、C节点。怕操作失误可以先打个备份标签：git tag backup-before-force-push，真搞乱了随时能通过这个标签回滚到重写前的状态。
2. 用安全强制推送替代裸force：不要直接用git push --force，改用git push --force-with-lease。这个参数会自动检查远程分支的状态和你上次拉取的状态是否一致，如果有其他协作者在你重写历史期间往远程推了新提交，会直接拒绝推送，避免把别人的新代码覆盖掉。
3. 提前同步协作者操作规则：因为所有提交的哈希都变了，必须提前通知所有仓库协作者历史被重写，让他们本地同步时按以下步骤操作，避免产生重复提交：
   • 先拉取全量远程更新：git fetch --all
   • 切到本地对应分支，执行git reset --hard origin/<对应分支名>对齐远程历史。注意这个操作会丢弃分支上所有未推送的本地提交，执行前一定要把未提交的改动通过stash或者临时提交做好备份。
4. 就算操作出错也不用慌，Git默认会保留所有提交记录至少30天，通过git reflog就能找到旧提交的哈希回滚，不会出现代码彻底丢失的情况。

内容的提问来源于stack exchange，提问作者CyberUser