如何管理主分支已一年未维护的多份个性化部署源码？

核心思路 #

先立即为所有已部署版本建立Git快照，再以快照为基础逐步合并所有特性到main分支，既满足“立即启用版本控制”的需求，又能最终统一代码版本。

第一步：为每个已部署版本创建独立快照分支 #

这一步能快速把所有现场代码纳入Git管理，同时保留各版本的完整状态：

• 从当前过时的main分支创建10个独立分支，命名建议清晰区分，比如release/deployed-01到release/deployed-10（后续能对应到具体机器时，再重命名即可）
• 依次将每台现场机器的代码，覆盖对应分支的所有文件，然后执行提交：

  git add .
  git commit -m "快照：现场已部署版本01的完整代码"
  

  这种方式不需要保留main的旧历史，直接生成对应部署版本的干净快照分支，完全符合你“不保留原分支历史创建release分支”的需求。

第二步：逐步合并特性到main分支 #

以快照分支为基础，快速让main积累所有所需特性：

1. 选择一个特性最完整、最稳定的快照分支（比如release/deployed-05），将其合并到main作为新起点：

   git checkout main
   git merge --allow-unrelated-histories release/deployed-05
   

   用--allow-unrelated-histories是因为main旧历史和快照分支无关联，强制合并后main就拥有了最新的基础代码。
2. 逐个对比其他快照分支与main的差异，确认需要保留的特性：

   git diff main release/deployed-02
   

3. 将特性合并到main，遇到冲突手动解决后提交：

   git merge release/deployed-02
   

   重复这个过程，直到main整合了所有10个版本的特性。

第三步：后续维护规范 #

• 所有新开发从main切出特性分支（比如feature/new-payment），开发完成后合并回main
• 后续部署时，从main切对应环境的release分支（比如release/prod-siteA），如果现场需要个性化修改，直接在该分支操作，同时将通用特性的修改同步回main
• 定期拉取现场分支的更新到仓库，避免再次出现版本失控

对您提出的三个方案的评价 #

• 方案1：不推荐。先整合所有特性再启用版本控制耗时久，期间现场代码若有变更会加剧混乱，且无法保留各部署版本的历史快照。
• 方案2：调整后可行。核心是先为每个部署版本创建快照分支，再基于快照逐步更新main，而不是直接覆盖main。你提到的“新建分支用release代码覆盖”正是创建快照分支的正确方式。
• 方案3：绝对不推荐。10个独立仓库会带来极高的维护成本，特性无法复用，后续统一版本的难度呈指数级上升。

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