一支五人的前端小组过去把代码放在各自电脑和U盘里。上线前一天，两名成员同时改了同一个登录页面，光是弄清谁改了什么就花掉一整天。这类问题通常出在没有统一的代码托管和协作流程上。下面用这个小组的改造过程，讲清楚在阿里云上用Git做代码管理的具体做法。
阿里云上用Git的三种方式
在阿里云上用Git，大致有三条路。
- 云效Codeup：阿里云云效平台自带的代码托管服务，基于Git。仓库管理、合并请求和代码评审都在网页上完成，大多数团队直接用就行。
- ECS自建Git服务：在云服务器上部署Gitea或GitLab等开源系统。数据完全在自己手里，但备份、安全补丁和服务可用性都要自己盯。
- 本地客户端直连：无论服务端是哪一种，开发者都用同样的git命令推送和拉取。换服务端时，本地的操作习惯基本不用改。
小组选了云效Codeup。理由很简单：没有专人维护服务器，权限和评审功能开箱即用。功能范围和价格会随版本调整，选型前请以阿里云官网的最新说明为准，这里不列具体数字。
第一步：创建仓库并完成首次推送
组长先在云效里建好项目和仓库，然后按下面的顺序操作：
- 进入本地项目目录，执行git init（已经是Git仓库则跳过），确认现有代码都已纳入版本控制。
- 从云效仓库页面复制HTTPS或SSH地址，执行git remote add origin 加上该地址，把远程仓库绑定到本地。
- 把默认分支推送到远程。推送成功后，网页端能看到全部提交记录，说明绑定正确。
这一步有个容易踩的坑。如果本地和远程各自已经有一段历史，直接推送会被拒绝。此时应先拉取远程内容，逐个解决冲突，再推送。不要用强制推送去覆盖别人的提交，那样丢掉的是别人的代码。
第二步：定下分支规则
没有分支规则时，所有人都往主分支直接提交。一次错误改动就能让整个团队停下来等修复。小组定了三条约定：
- 主分支只接收合并请求。在云效里开启分支保护，禁止直接推送，所有改动都走同一个流程。
- 每个需求单独建分支，命名统一为feature加需求编号，例如feature-1027-登录优化。看到分支名就知道它对应哪个需求，清理时也不容易误删。
- 合并前至少一人评审。评审意见留在合并请求里，过一段时间回头查，能看清当时为什么这样改。
实施两周后，小组统计发现，主分支的回滚次数从每月三四次降到了零。这靠的是评审把关，而不是某个人的记性。
合并请求怎么用
功能写完后，开发者在云效里发起合并请求，选好源分支和目标分支，填写改动说明和测试结果。评审人可以逐行留言。作者修改后推送到同一个分支，合并请求会跟着更新，不需要另开一个。
小组要求每个合并请求的说明里写清影响范围，比如改了哪些页面、接口有没有变化、是否需要重新配置。评审人不用通读全部代码，也能判断风险大小。说明写得越具体，评审越快。
第三步：安全管理访问凭证
访问仓库需要凭证。小组最初把访问令牌直接写进了项目配置文件，随代码一起提交到了仓库里。发现后，他们立刻在云效中吊销了这个令牌，重新生成了一个。这件事之后，小组定下几条规矩：
- 优先使用SSH密钥。每位成员用自己的密钥对。有人离开小组时，只需回收他的公钥，其他人不受影响。
- 令牌和密码放进环境变量或密钥管理服务，不写进代码，也不打印到日志里。
- 权限按最小化分配。多数成员只需要开发者角色，管理员权限留给真正需要的人。
凭证一旦被提交，删掉文件是不够的，历史记录里依然保留着它。正确的顺序是先轮换凭证，让旧值失效，再决定要不要清理历史。清理历史需要改写提交记录并强制推送，这会影响所有人的本地仓库。动手前要提前通知全组，并约好每个人如何同步。
第四步：让推送自动触发检查
代码托管的价值不止于存文件。小组把云效流水线接入仓库，每次合并到主分支都会自动执行构建和单元测试。测试失败时，合并请求会被标记为不通过，问题在进入测试环境之前就被拦下。以前这些检查要靠人手动跑，现在由系统完成，评审人可以把精力放在逻辑本身。
常见问题
推送被拒绝，提示non-fast-forward。远程有你本地没有的提交。先拉取远程更新，解决冲突后再推送，不要用强制推送绕过去。
仓库很大，克隆特别慢。多半是安装包、模型文件这类二进制文件被直接提交了。把它们放到对象存储，仓库里只保留引用路径。同时在.gitignore里排除编译产物和依赖目录，避免它们被误加入提交。已经进入历史的大文件，清理起来比预防麻烦得多。
分支越来越多，没人清理。合并之后立即删除对应的功能分支。另外定期检查长期没有更新的分支，确认是否还有保留价值，没有就删。
小结
阿里云上的Git协作本身不复杂。真正费工夫的是把仓库、分支、权限和自动化串成一条稳定的流程。这个小组大约用了两周完成改造，此后没有再出现因同时修改同一文件而丢代码的情况。规模不大的团队，从统一托管和分支规则开始做，见效通常最快。
