在一家创业公司做开发，项目进度紧，功能迭代快。刚来的时候，大家提交代码全靠 master 分支，结果上线前总出问题——有人改了登录逻辑，有人删了接口字段，合并时冲突一堆，测试环境跑不起来是常事。
后来我们引入了 Git 分支策略，情况立马好转。不是什么高深理论，就是几个简单规则，但让协作变得清晰多了。
主干分支：master 和 develop
我们定了两个长期分支：master 和 develop。master 只用来发布稳定版本，每次上线打 tag；develop 是日常开发的集成分支，所有新功能都往这儿合。
开发小张要做个用户头像上传功能，他不会直接在 develop 上改，而是从它拉出一个新分支：
git checkout -b feature/user-avatar-upload develop功能做完，提 PR（Pull Request）到 develop，等同事 review 通过再合并。这样主分支始终可部署，不怕某人半途提交个半成品炸掉整个系统。
临时分支：feature、release、hotfix
除了功能分支，我们还有三种临时分支。
一个是 release 分支。比如下周五要发 v1.2 版本，就从 develop 切出 release/1.2。这时候新功能停止合并，只修 bug。测试发现问题，直接在这个分支上改，稳定后再同时合回 master 和 develop。
另一个是 hotfix。有次线上突然登录不了，必须立刻修复。我们就从 master 拉出 hotfix/login-bug，修完验证通过，马上合并回 master 并打新版本号，然后再同步到 develop，避免同样的问题再出现一次。
这些分支用完就删，不堆积垃圾分支。每个人本地定期执行：
git fetch --prune
git branch -d feature/user-avatar-upload远程分支清理也由 CI 脚本自动完成，省得谁忘了删。
命名规范也很重要
分支名不能乱起。我们约定：
- 功能分支：feature/功能简述，比如
feature/order-refund - 发布分支：release/版本号，如
release/1.3 - 紧急修复：hotfix/问题描述，如
hotfix/token-expire
这样一看名字就知道分支用途，PR 审核时也不容易搞错。
有次实习生提交了个叫 test1 的分支，大家都不知道是干啥的，还得专门去问。后来团队统一规定，不符合命名规则的分支不允许推送，直接在 pre-push 钩子里拦截。
现在每周三下午是固定发版时间，流程清楚，谁都不慌。分支策略不是死规矩，但我们这套方法用了快一年，没再因为代码混乱耽误过上线。