我帮团队规范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不接受直接pushdevelop → 开发主分支feature分支从这里切合并后回developfeature/* → 功能分支从develop切出完成后merge回develophotfix/* → 紧急修复从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/logingit 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合并到maingit checkout maingit merge --no-ff hotfix/payment-error -m Merge hotfix: 支付超时修复合并回develop确保develop也有这个修复git checkout developgit merge --no-ff hotfix/payment-error -m Merge hotfix to develop我后来在团队里加了个pre-commit检查强制要求所有merge必须有对应的分支不允许直接在main上提交。这个规则一开始有人抱怨但用了一周后大家都习惯了。规范落地的代价有人不适应说实话推行规范的过程中不是没有阻力。有个老员工跟我说「以前这么干也没出过问题现在搞这么复杂干嘛」我当时没反驳只是给他看了上个月因为分支混乱导致的生产事故记录——有3次回滚2次数据修复耗时加起来超过20小时。他看完没说话了。我们用了大概3周时间把规范写成了文档配了几个常用的git aliasbash.gitconfig 里的自定义命令[alias]br branch -alg log --graph --oneline --decorate --allff merge --ff-onlycf checkout -b feature/ch checkout -b hotfix/这些alias看着是小改动但实际上大幅降低了执行成本。开发者不用记那么多命令输入git cf login就能创建功能分支git lg就能看全局提交历史。3周后回头看冲突率从原来的每周3-4次降到了不到1次。main分支上的提交变得干净每次release都能快速定位到对应的feature分支。说实话一开始我也担心流程太重会拖慢开发速度但实际运行下来因为减少了解决冲突的时间整体效率反而提升了。本文基于实际项目经验整理欢迎在评论区交流技术问题。 我帮团队规范Git分支：5人3周踩坑实录
我帮团队规范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不接受直接pushdevelop → 开发主分支feature分支从这里切合并后回developfeature/* → 功能分支从develop切出完成后merge回develophotfix/* → 紧急修复从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/logingit 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合并到maingit checkout maingit merge --no-ff hotfix/payment-error -m Merge hotfix: 支付超时修复合并回develop确保develop也有这个修复git checkout developgit merge --no-ff hotfix/payment-error -m Merge hotfix to develop我后来在团队里加了个pre-commit检查强制要求所有merge必须有对应的分支不允许直接在main上提交。这个规则一开始有人抱怨但用了一周后大家都习惯了。规范落地的代价有人不适应说实话推行规范的过程中不是没有阻力。有个老员工跟我说「以前这么干也没出过问题现在搞这么复杂干嘛」我当时没反驳只是给他看了上个月因为分支混乱导致的生产事故记录——有3次回滚2次数据修复耗时加起来超过20小时。他看完没说话了。我们用了大概3周时间把规范写成了文档配了几个常用的git aliasbash.gitconfig 里的自定义命令[alias]br branch -alg log --graph --oneline --decorate --allff merge --ff-onlycf checkout -b feature/ch checkout -b hotfix/这些alias看着是小改动但实际上大幅降低了执行成本。开发者不用记那么多命令输入git cf login就能创建功能分支git lg就能看全局提交历史。3周后回头看冲突率从原来的每周3-4次降到了不到1次。main分支上的提交变得干净每次release都能快速定位到对应的feature分支。说实话一开始我也担心流程太重会拖慢开发速度但实际运行下来因为减少了解决冲突的时间整体效率反而提升了。本文基于实际项目经验整理欢迎在评论区交流技术问题。