见过最糟糕的情况是：网站源码靠压缩包传来传去，文件名叫"网站最终版""网站最终版2""网站真正最终版"。出问题想回退时，根本不知道哪个是最新的。
用版本控制系统是底线，而怎么用，决定了协作是顺畅还是混乱。
分支不用搞复杂
小团队不需要照搬大厂的复杂模型，三到四类分支足够：
- 主分支：始终对应线上正在运行的版本，任何人不能直接改
- 开发分支：日常集成的地方，功能完成后合并进来
- 功能分支：每人每个功能开一条，做完合并回开发分支
- 紧急修复分支：线上出问题，从主分支拉出来改，改完同时合回两边
命名上约定简单规则就行，比如 feature/product-filter、fix/form-submit、hotfix/homepage-error。看名字就知道在干什么。
提交信息写给人看
"修改""更新""fix bug"这类提交信息，三个月后毫无价值。一条有用的提交信息应该说明改了什么以及为什么：
fix: 修复手机号校验未排除空格导致提交失败表单提交时用户输入带空格的手机号会被拒绝，现在提交前先去除首尾空格再校验。第一行是摘要，空一行后写详情。日志能这样读的时候，排查问题会快很多。
合并前过一遍代码
代码评审的目的不是挑刺，而是在合并前发现问题。评审时重点看：
- 逻辑是否正确：边界条件处理了吗，异常分支覆盖了吗
- 有没有安全隐患：用户输入是否校验，权限是否判断
- 是否重复造轮子：已有工具函数为什么又写一遍
- 命名是否清晰：三个月后还能看懂吗
- 改动范围是否可控：顺手改了不相关的代码，要问清楚
几条规定要写进团队约定
- 主分支保护：禁止直接推送，必须走合并请求
- 提交前本地自测：至少确认改动相关功能能跑
- 不要提交大文件和密钥：图片、视频走资源服务器，密码和密钥走环境变量
- 合并前先拉取最新代码：减少冲突
- 冲突要沟通解决：别看都不看就选"用我的版本"
关于密钥这条要特别强调，一旦把数据库密码提交进仓库，即使后来删掉，历史记录里仍然存在，正确的做法是立刻更换密钥。
打标签，留退路
每次上线后给当前版本打一个标签，比如 v1.2.0，写上这个版本做了什么。线上出问题时，你能立刻知道该回退到哪个点，也能快速对比两个版本之间改了哪些文件。
文档放仓库里
部署步骤、环境配置说明、常见问题，都放在代码仓库里随代码一起维护。写在聊天记录或者某个人的电脑里的文档，一定会丢失。
版本管理的价值，在你最需要它的那一天才体现出来。而那一天通常是出事的时候。
—— 一位从压缩包时代走过来的技术负责人