Node.js应用迁AWS Lambda：新建Git仓库还是分支？团队协作场景

嘿，这种从传统架构完全重写为无服务器版本的场景，我在之前的团队项目里也遇到过，结合你们多人协作的情况，给你梳理下最合理的方案：

先明确：别新建独立仓库 #

新建两个仓库确实会带来很多后续问题：

• 团队成员需要在两个仓库间切换上下文，容易出现提交到错误仓库、找不到对应文档/配置的情况；
• CI/CD、代码规范、文档等基础配置需要重复维护，增加额外工作量；
• 同个服务的不同版本割裂在两个仓库，后续追溯历史、对比版本差异都会变得麻烦。

所以在现有仓库内用分支策略是更优的选择，具体操作可以这样来：

1. 新建独立的v2开发分支 #

从当前的master分支拉出一个专门的分支，比如命名为release/v2.0或者feature/full-serverless-refactor，所有v2的开发工作都在这个分支上进行：

git checkout master
git pull origin master
git checkout -b release/v2.0

这样做的好处是完全不影响v1版本的日常维护（比如bug修复、小迭代），团队成员可以在各自的feature分支开发v2功能，然后PR到这个v2主分支，保持和平时一样的协作流程。

2. v2稳定后的master分支处理 #

当v2版本完成测试、准备上线替代v1时，分两种情况处理：

• 如果v1不再需要维护：

  1. 先给当前的master分支归档，创建一个archive/v1.0分支留存历史：

     git checkout master
     git checkout -b archive/v1.0
     git push origin archive/v1.0
     

  2. 把master分支完全替换为v2的内容：

     git checkout master
     git reset --hard release/v2.0
     git push origin master --force
     

     👉 注意：执行强制推送前一定要和所有团队成员同步，确保没人在master上有未提交的本地修改，避免代码丢失。
  3. 给master打一个v2.0.0的标签，方便后续版本追溯：

     git tag -a v2.0.0 -m "Release serverless version 2.0"
     git push origin v2.0.0
     

• 如果v1还需要并行维护一段时间：
  暂时让master继续保留v1代码，把release/v2.0作为v2的主要开发分支，日常的v2迭代都在这个分支上进行。等v1完全下线、不再需要维护时，再按照上面的步骤把v2合并/重置到master分支。

3. 团队协作的关键提醒 #

• 提前和所有同事同步这个分支策略，明确各自的开发分支归属；
• 在CI/CD配置里单独给v2分支配置部署流水线，指向Lambda的测试/预发布环境，和v1的部署完全隔离；
• 归档v1分支后，可以在仓库README里标注清楚版本分支的归档情况，避免新成员混淆。

这种方案既避免了多仓库的混乱，又能妥善处理新旧版本的过渡，同时保持团队协作的流畅性。

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