如何用另一个分支完全替换 main 分支
完全替换 main：git checkout main && git reset --hard <替换分支>，然后 git push --force-with-lease 强推。协作者应先备份并选择同步方式；仅替换内容可准备普通快照提交，ours 合并需核对祖先关系及后续合并影响。
硬替换：git checkout main && git reset --hard 替换分支名——main 的指针直接拨到替换分支的提交，然后 git push --force-with-lease 覆盖远程。历史就此改写。
操作步骤
# 先保存工作区/暂存区，确认团队授权改写与目标内容
git fetch origin
old_remote=$(git rev-parse origin/main)
git branch archive-old-main main
git checkout main
git reset --hard new-main-content
git push --force-with-lease=refs/heads/main:$old_remote origin main:main
更温和的替代：ours 合并
强推改写历史对团队不友好。如果只是想"内容上新分支赢，但历史保持连续"：
git checkout main
# 此方向保留main内容，不是要执行的替换命令：
# git merge -s ours new-main-content
实际上要"内容全用对方"应该反过来：
git checkout new-main-content
git merge --no-ff -s ours main # 需有可合并历史；已是祖先时不会制造新内容
git checkout main
git merge --ff-only new-main-content # 仅在祖先关系允许时快进
git push
这种操作会把被ours忽略的main变更标为已合并，影响后续合并，且需检查祖先关系。若只要替换快照，通常在main以 git restore --source=new-main-content --staged --worktree -- . 准备普通提交更直接；先保存本地工作，并审查删除/新增差异。
强推后的团队同步
# 每位协作者先备份自己的分支与未提交工作，比较远端并决定rebase/cherry-pick/重置
git fetch origin
# 只有明确放弃当前本地状态时才执行：git reset --hard origin/main
常见问题（FAQ）
Q：什么时候需要这种操作？
项目推倒重来但想保留仓库（issues、star）；主线误入歧途决定整体切换到重写分支。日常开发几乎用不到。
Q：GitHub 保护分支不让强推？
遵守仓库保护规则与团队审批流程；优先通过审查后的普通提交和合并请求更新内容，不要为了替换分支而绕过保护。
Q：旧 main 的历史会丢吗？
reset 前打个 tag 备份：git tag archive/old-main main——只要该引用及对象被保留就可回溯；应按需要推送备份引用，不能承诺永久恢复。
