小团队刚用 Git 时，多半只是想留一份版本记录。项目一多、人一多，问题就来了：分支越来越乱，部署全靠手工，服务器上跑的代码和仓库对不上。这篇文章记录一个五人电商后端团队如何把 git 和阿里云的代码托管、流水线串起来，从本地仓库迁到云端，最后做到合并即部署。
从本地仓库迁到云端托管
这个团队原来把代码放在一台开发机上，改动靠 U 盘和聊天工具来回传。第一步是把仓库迁到阿里云云效 Codeup。Codeup 支持标准 Git 协议，本地仓库已有提交记录的话，只要加一个远程地址就能推送：
git remote add origin 你的Codeup仓库地址
迁移之后，成员改用 SSH 密钥访问仓库，不再共用账号密码。每个人在自己机器上执行 ssh-keygen 生成密钥对，把公钥加到个人账号的 SSH 设置里，私钥只留在本机。好处是，哪台笔记本丢了，只需要在后台吊销那一把公钥，其他人不受影响。
分支规则和合并请求
代码上云以后，新问题很快出现：大家都直接往 main 推送，线上因为未经测试的代码被合入，出过两次故障。团队于是定了一套简单的分支规则：
- main：随时可以发布，只接受合并请求，禁止直接推送。
- develop：日常集成分支，功能做完先合到这里。
- feature/*：每个需求开一个分支，名字带上需求编号，例如 feature/order-coupon-201，半年后翻记录时一眼能对上需求。
- hotfix/*：线上紧急修复从 main 切出，修完同时合回 main 和 develop，避免 develop 上仍是有问题的旧代码。
在 Codeup 里可以给 main 设保护规则：合并请求至少要一名成员审核通过，并且流水线检查通过，才能合入。开发者的日常流程大致是：
- 从 develop 切出 feature 分支，编码完成后推送到云端。
- 在 Codeup 发起合并请求，写清楚改了什么、影响哪些模块。说明写得越具体，审核的人越容易判断风险。
- 同事审核代码，同时流水线自动运行单元测试。
- 审核和测试都通过后合入 develop，每周把 develop 合并到 main 发布一次。
流程不算复杂，但它把“谁改的、为什么改、测过没有”都留在了合并请求的记录里。半年后回头查问题，基本能直接定位到那一次改动。
用流水线把代码部署到 ECS
分支规则管住了代码质量，部署却还靠人。运维同事每次要登录阿里云 ECS，手动拉代码、构建、重启服务，偶尔会漏掉一步。团队于是在云效流水线里把这些步骤写成自动任务。
流水线的核心逻辑很直接：代码合入 main 后触发构建，打出产物，通过 SSH 上传到 ECS 的指定目录，再执行重启脚本。下面是一个简化的部署脚本：
#!/bin/bash
set -e
APP_DIR=/srv/order-service
cd “$APP_DIR”
git pull origin main
npm ci –production
pm2 restart order-service
set -e 的作用是，任何一步失败就立刻中止，不会在服务器上留下一半新一半旧的状态。部署账号只给该目录的读写权限和重启服务的权限，没有 root。这是安全评审时团队明确提出的要求。
上线之后，一个功能从合并到生效，时间从原来的半天缩到十几分钟，每次部署也都能在流水线记录里找到对应的提交号。
几个容易忽略的地方
- 密钥不进仓库：数据库密码、AccessKey 这类信息不要提交。可以通过 KMS 或运行时环境变量注入，本地配置文件记得写进 .gitignore。
- 大文件单独放：安装包、视频不适合进 Git。放到 OSS 里，仓库只保留下载地址或版本号。
- 误提交密钥先换密钥：发现密钥被提交，第一件事是在阿里云侧轮换。改写仓库历史是后面的事，而且会影响所有协作者，不要抢在前面做。
- 定期备份仓库：托管平台本身比较可靠，但团队还是会定期把仓库镜像到另一个地域或存储，留一份兜底。
小结
小团队用 git 管代码，阿里云管托管和部署，两者配合并不需要复杂架构。先把仓库迁上云，再定下分支规则，最后用流水线替掉手工操作，多数协作和发布的问题都能明显改善。团队变大以后，再考虑代码扫描、灰度发布这些能力也不迟。
