我帮团队规范Git分支：5人3周踩坑实录
前不久接了个内部工具重构项目，客户是个做电商SaaS的团队，大概5个人。说实话，他们的Git使用混乱到让我惊讶——main分支上直接改代码，feature分支随便创建又随便删，有次差点把生产环境的配置搞丢。我花了3周时间，帮他们把Git Flow分支模型落地，冲突率下降了差不多80%。今天就把这段经历整理出来，都是真实踩过的坑。
混乱的源头：没有规范就没有安全
刚接手的时候，我看了他们的提交历史，差点血压升高。main分支上混杂着测试代码、临时修复、甚至有人直接把本地调试用的配置文件push上去。更离谱的是，有2个开发者同时改了同一个工具类，谁也不通知谁，合并的时候才发现逻辑被覆盖了。
「你们怎么不早点发现？」我问。
「发现不了啊，每次合并都挺顺的，直到上线报错才知道有问题。」
我当时觉得这样就行，结果发现错了。问题不在于技术，在于没有流程约束。
项目实战决策：引入Git Flow还是简化版分支策略？
说实话，Git Flow本身比较复杂，有main、develop、feature、release、hotfix五个分支类型。我一开始也想直接上完整Git Flow，但试了一圈发现，5人小团队根本撑不起那么重的流程。最后我决定用简化版：
```
main → 生产环境代码，只接受merge，不接受直接push
develop → 开发主分支，feature分支从这里切，合并后回develop
feature/* → 功能分支，从develop切出，完成后merge回develop
hotfix/* → 紧急修复，从main切出，修复后同时merge到main和develop
```
这个决策的依据很简单：团队小、迭代快，太重流程会拖慢节奏。简化版既能保证main的纯净，又不会让开发者觉得麻烦。
落地过程中的坑：merge还是rebase？
规范定好了，执行的时候又出问题了。有个开发者习惯用git rebase来同步develop分支的代码，我觉得挺合理，提交历史干净。结果有次他rebase之后force push，把别人的feature分支搞乱了，大家的花了半小时才恢复。
「坑死了，rebase这玩意儿用起来真香，但teamwork里就是地雷。」
后来我定了个铁律：只有本地分支才能rebase，公共分支绝对不允许rebase和force push。
```bash
安全做法：用merge同步
git checkout feature/login
git merge develop
或者用pull --rebase，但仅限个人feature分支
git pull --rebase origin feature/login
```
另一个踩坑点是hotfix流程。有次线上出现个bug，开发者直接在main分支上修，改完测试没问题就push了。我一看提交记录，整个人都不好了——main分支上多了一个没有对应的develop分支的修复。
```bash
正确的hotfix流程
git checkout -b hotfix/payment-error main
修复代码...
git commit -m "fix: 修复支付超时问题"
git push origin hotfix/payment-error
合并到main
git checkout main
git merge --no-ff hotfix/payment-error -m "Merge hotfix: 支付超时修复"
合并回develop，确保develop也有这个修复
git checkout develop
git merge --no-ff hotfix/payment-error -m "Merge hotfix to develop"
```
我后来在团队里加了个pre-commit检查，强制要求所有merge必须有对应的分支，不允许直接在main上提交。这个规则一开始有人抱怨，但用了一周后，大家都习惯了。
规范落地的代价：有人不适应
说实话，推行规范的过程中不是没有阻力。有个老员工跟我说：「以前这么干也没出过问题，现在搞这么复杂干嘛？」
我当时没反驳，只是给他看了上个月因为分支混乱导致的生产事故记录——有3次回滚，2次数据修复，耗时加起来超过20小时。他看完没说话了。
我们用了大概3周时间，把规范写成了文档，配了几个常用的git alias：
```bash
.gitconfig 里的自定义命令
[alias]
br = branch -a
lg = log --graph --oneline --decorate --all
ff = merge --ff-only
cf = checkout -b feature/
ch = checkout -b hotfix/
```
这些alias看着是小改动，但实际上大幅降低了执行成本。开发者不用记那么多命令，输入git cf login就能创建功能分支，git lg就能看全局提交历史。
3周后回头看，冲突率从原来的每周3-4次降到了不到1次。main分支上的提交变得干净，每次release都能快速定位到对应的feature分支。说实话，一开始我也担心流程太重会拖慢开发速度，但实际运行下来，因为减少了解决冲突的时间，整体效率反而提升了。
本文基于实际项目经验整理，欢迎在评论区交流技术问题。
