将origin/master迁移至新分支归档v1版本启动v2的最佳方法是什么？

以下操作均基于现有仓库完成，无需新建仓库，可完整保留v1历史记录同时获得v2的全新开发起点：

第一步：归档v1代码到独立分支 #

• 先同步本地v1主分支和远端代码，确保是最新状态：

git checkout main
git pull origin main

• 从当前v1主分支新建归档分支，建议采用统一命名规范，比如archive/v1-stable：

git checkout -b archive/v1-stable

• 将归档分支推送到远端origin：

git push origin archive/v1-stable

• 可选操作：给v1最终版本打标签，方便后续快速回溯快照：

git tag -a v1.0.0-final -m "v1版本最终归档快照"
git push origin v1.0.0-final

第二步：重置主分支为v2开发起点 #

根据需求可选择两种实现方式：

方案A：创建完全无历史的空白分支 #

适合v2和v1代码差异极大、不需要继承v1提交历史的场景：

• 新建无提交历史的孤儿分支：

git checkout --orphan v2-main

• 清空当前工作区所有v1相关文件：

git rm -rf .

• 添加v2初始代码、基础配置文件后提交，强制覆盖远端主分支：

git add .
git commit -m "feat: v2版本初始提交"
git push -f origin v2-main:main

注意：强制推送前请确认所有团队成员已备份本地v1代码，避免误操作丢失数据

方案B：保留通用配置文件仅删除v1业务代码 #

适合需要继承LICENSE、README、.gitignore等通用配置的场景：

• 切回原主分支，删除所有v1业务代码，仅保留通用配置文件，修改README标注v2开发状态、v1归档分支位置
• 提交变更并推送到远端：

git add .
git commit -m "chore: 清除v1业务代码，初始化v2开发环境"
git push origin main

• 归档分支设置权限保护：在GitHub/GitLab等仓库的后台设置中，给archive/开头的归档分支设置禁止直接推送、禁止删除、仅管理员可修改的只读权限，避免误操作覆盖或丢失归档的v1历史代码
• 明确分支命名规则：归档分支统一使用archive/[版本号]-[状态]格式，比如archive/v1-stable、archive/v1-lts，后续v1的修复分支统一使用v1/xxx格式，和v2的分支命名体系完全区隔，避免合入错误
• 归档前完成v1收尾工作：合并所有v1的待合入PR、关闭已完成的v1相关issue，在仓库首页README的显眼位置标注v1的维护状态、归档分支入口，以及后续v1问题的反馈路径
• 提前同步团队变更：操作前提前告知所有协作者仓库结构变更的时间点，操作完成后同步主分支拉取方式、v1修改的提交规则，避免成员本地代码和远端冲突
• 完整保留提交历史：不要删除v1的原有提交记录，归档分支需完整保留所有v1的提交日志，方便后续问题溯源、跨版本缺陷修复
• 规范v1后续维护流程：如果后续需要给v1出修复补丁，直接从归档分支拉取特性分支开发，修改完成后合入归档分支、单独打v1的小版本标签即可，不要合入v2的主分支

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