Necromanov团队里Git用得乱，十有八九不是命令不会敲，是没人把规则定明白。我在几个不同规模的团队里都见过类似的混乱：有人直接在master上改东西，有人一个分支能用三个月，有人merge上来一堆冲突然后挑能用的代码留，review的时候全是"LGTM"。这些问题的根源不在于谁技术差，而在于分支管理、代码合并、Code Review这三件事没有形成一个完整的闭环。这篇内容就是把我自己的实践和复盘整理出来，从分支模型怎么选，到合并冲突怎么处理，再到Review怎么落地，完整走一遍。
1. 分支管理不是命令问题，是协作契约问题
1.1 为什么"规范"往往死在第一步
Git的分支本质上只是一个指针，创建成本极低，但正因为太便宜了，大家用起来就随意。团队协作中分支管理真正要解决的，不是技术问题，而是"大家如何约定共享代码的边界"的问题。我见过太多团队把规范写在Wiki里，写得很完整，但实操起来完全是另一回事，这是因为规范没有和实际开发场景一一对应。
举个例子，开发人员小张接到一个需求，他习惯性地在本地master上直接改，改完直接push。这个流程单看没有错，因为仓库是他自己的，但当团队有10个人的时候，master就变成了一个"谁都能写"的公共区域，代码冲突、功能互相踩踏、发布前不知道主干上有什么东西，这些问题马上就来了。所以分支管理的第一条原则应该是：主干分支永远处于可发布状态，任何未完成的工作不允许直接进入主干。
1.2 分支命名的统一是第一步
我观察过很多团队的光秃秃的分支列表，看到的都是test、fix、new这种毫无辨识度的名字。分支命名统一这件事，看起来是小事，其实是整个协作契约的入口。建议的命名模式是这样的：
- 功能分支：
feature/需求编号-简短描述，例如feature/PAY-1024-微信支付回调 - 修复分支：
hotfix/问题编号-简短描述，例如hotfix/PAY-998-修复空指针 - 发布分支：
release/版本号，例如release/2.3.0
为什么功能分支要带需求编号？因为当你面对几十个分支时，需求编号能直接关联到项目管理工具，一眼就能看出这个分支对应什么工作内容。这个习惯养成之后，后面做Code Review、做发布清单、做分支清理都会轻松很多。
1.3 分支的生命周期管理
另一个常见的坑是分支只生不死。项目跑了半年，仓库里有几十个残留分支，没有人能说清楚哪些是已合并的、哪些是废弃的、哪些还在开发中。所以除了命名，还要约定分支的生命周期：
- 功能分支从主干拉出，开发完成并合并回主干后立即删除。
- 远程分支和本地分支同步清理，避免本地残留一堆
origin/feature/xxx的引用。 - 每周五下班前做一次分支清理，把已合并的分支统一删除。
我在团队里推这个规则的方式比较简单粗暴：在仓库的README里写清楚分支命名规范，然后在每次周会上看一次分支列表，看到不合规的就当场问。坚持三周，大家就形成肌肉记忆了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分支模型没有绝对标准，要看团队状态
2.1 从主干开发到Git Flow的演进逻辑
分支模型的选择没有银弹，我见过三种主流的模型，分别适合不同阶段的团队。主干开发模型（Trunk-Based Development）：所有人直接在主干上开发，通过特性开关控制功能上线。这是最轻量的方式，适合持续部署能力很强的小团队，但要求自动化测试覆盖率高、发布频率快，否则主干分分钟被搞挂。
Git Flow模型：经典的分支模型，有master（生产分支）、develop（集成分支）、feature、release、hotfix五类分支。它的优势是流程完整、职责清晰，适合有固定发布节奏、需要同时维护多个版本的团队。缺点也很明显，就是重，分支流转路径长，对快速迭代的互联网团队来说往往过度设计。
GitHub Flow模型：一种更轻量的方式，只有master和feature分支，feature分支完成后直接合入master并部署。它非常适合以持续交付为核心的团队，规则简单，容易执行。
2.2 怎么判断你的团队该用哪种
这里我给一个简单的判断标准：你的团队多久发一次版？
- 每天发布甚至一天多次 → 主干开发或GitHub Flow
- 每周或每两周固定发版 → Git Flow或GitHub Flow
- 需要同时维护线上多个版本（如传统企业软件）→ Git Flow
我现在的团队用的是GitHub Flow的变体，增加了一个develop分支作为集成分支，在发布前合入master。这个选择的原因很直接：我们规模在10人左右，每天有多次合并，但还没有做到完全自动化部署，需要一个稳定的集成环境来做回归测试。加一个develop分支的成本很低，但能显著降低主干的不稳定性。
2.3 分支模型的落地细节
不管选哪种模型，有几个细节是通用的：
- 分支拉取时机：功能分支必须从最新的主干或集成分支拉取。如果拉取时已经落后了，先合并或变基一次再开始开发。
- 分支保活时间：一个分支的生命周期建议控制在3天内。超过3天的分支，代码合并成本会指数级上升。如果需求太大，应该拆分成多个小分支。
- 分支的上下游关系：明确只有集成分支（develop）允许被合入，功能性分支之间不要互相合并。如果两个功能分支有依赖，应该先后合入develop，再由develop统一分发。
我记得有一次两个前端分支因为互相合并，导致了一堆重复代码被提交到集成分支，害得整个团队花了一个下午来清理。后来立了规矩：功能性分支之间禁止互相合并，有依赖就排队。
3. 代码合并的原则和操作细节
3.1 合并的频率和信息质量决定了冲突的代价
代码合并这件事，等得越久，痛得越深。一个分支如果开发了两周才合并回主干，冲突几乎是必然的，而且冲突的解决成本非常高。所以我一直强调：频繁、小批量地向集成分支合并，而不是一次性推一大坨。
具体怎么落地呢？我建议开发者每完成一个子任务（通常半天到一天的工作量），就做一次提交并推送到远程分支。每天早上开始开发前，先拉取最新的develop合并到自己的分支。这样做的本质是每天都把"冲突成本"分摊掉一部分，而不是攒到最后一天一次性爆发。
3.2 Merge还是Rebase：两条路线各有各的账
这是团队里最容易吵架的技术选择。我的观点很明确：公共分支上用merge，私有分支上用rebase。公共分支（如develop、master）是共享的，使用rebase会重写提交历史，可能导致其他人的本地仓库出现混乱，这绝对不可接受。而在自己的功能分支上，rebase可以把杂乱的提交整理成一条清晰的线，让最终合入的提交记录更干净。
实际操作中我还会用squash merge来收尾功能分支。比如一个功能分支已经产生了20个提交，里面可能有很多"wip"、"fix typo"、"临时提交"这类信息量很低的提交，如果全量merge进develop，历史会非常嘈杂。通过squash merge，把整个分支压缩成一个提交再合并，主干的历史就清晰很多。具体的命令如下：
bash复制# 先把功能分支更新到最新develop
git checkout feature/PAY-1024
git fetch origin develop
git rebase origin/develop
# 切回develop并执行squash合并
git checkout develop
git merge --squash feature/PAY-1024
git commit -m "feat: 完成微信支付回调功能 (#PAY-1024)"
这里要留意的是：如果功能分支有多个逻辑上独立的小改动，squash之后会丢失这些粒度。这种情况更推荐git merge配合--no-ff（保留合并提交），让主干上能清楚看到功能的合并节点。
3.3 合并时如何处理冲突：先理解后动手
冲突是躲不掉的，但解决冲突的思路可以提前训练。很多新手遇到冲突的第一反应是"把两边的代码都保留"，这个做法非常危险。冲突解决的核心原则是：冲突是两个人的代码在逻辑上产生了分歧，你需要理解两边的意图，而不是机械地拼凑。
具体的处理步骤我建议这样：
- 运行
git status确认冲突文件列表，一个一个解决，不要跳。 - 打开冲突文件，找到
<<<<<<<、=======、>>>>>>>标记的部分，分析每一处冲突。 - 如果冲突涉及同一段逻辑的两版实现，需要和对方沟通确认保留哪一版，而不是自己一拍脑袋决定。
- 解决完所有冲突后，运行
git add，然后提交。
提示：很多初学者调IDE里的"Resolve Conflicts"按钮，看到能编译过就提交了。编译过不代表逻辑对，更不代表没有双份重复代码。合并后务必跑一遍相关功能的测试用例，这个环节省不了。
4. Code Review不是秀肌肉，是质量闸门
4.1 从"看完点个通过"到"标准明确再动手"
很多团队的Code Review流于形式，根本原因是没有明确的Review清单。评审人打开Pull Request，看了一遍看不懂，又不好意思说，就点个通过，这是最没价值的结果。
我把Review清单写成了固定格式，提交Pull Request的时候必须自己先对照一遍：
- 功能的实现思路是否清晰，是否有过度设计或未来主义（YAGNI原则）
- 是否有明显可以复用的方法或组件，而不是到处粘贴复制
- 是否有潜在的性能问题，如不必要的循环、重复的数据库查询、N+1问题
- 是否有并发安全隐患，如共享状态未被保护
- 是否有完善的错误处理和日志输出，而不是直接吞掉异常
- 是否有对应测试用例，且测试覆盖住了关键逻辑路径
这个清单的意义不只是给评审人看，更是给提交人做自检的。很多时候作者写完代码自己过一遍清单，就能发现一堆问题，不需要等评审人来指出。
4.2 如何让Code Review高效而不惹人烦
Review中最大的敌人是"大而全"。一个Pull Request动辄上千行改动，评审人看半小时就看不下去了，最后草草通过，或者无限期挂起。所以Code Review的第一准则是：提交规模必须控制，单次Review能接受的合理范围在200-400行以内，超过这个量级就应该拆分。
具体到Review节奏，我自己的习惯是这样的：
- 先看描述，了解需求和改动范围。
- 先看测试，确认测试覆盖了哪些场景，这一步能快速建立代码行为的认知。
- 再看主逻辑，对照实现是否和描述一致。
- 最后看细节，检查命名、边界处理、异常处理。
整个流程大概20到30分钟。如果超过一个小时还没看完，说明这个Pull Request太大了，应该让作者拆开。
4.3 评审话术：对事不对人的表达技巧
Review中发现问题的表达方式，直接决定了团队氛围。我见过一些技术很强的同事，Review的时候说话很冲，最后搞到团队里没人愿意提Pull Request，这是很可惜的事。推荐用"建议"而非"要求"的口吻，把问题指向代码而非个人。比如：
-
不太合适："你这个变量名起的是什么鬼？"
-
较合适："这个变量名
data的含义比较宽泛，建议改成paymentData，方便阅读。" -
不太合适："这逻辑有问题，重写。"
-
较合适："这里的分支处理感觉有些绕，是否可以先判断异常情况再走主逻辑？"
说到底，Code Review是团队协作的润滑剂，不是技术比拼的竞技场。好的Review文化能让人愿意提交代码、愿意接受反馈，这本身就是团队成长的重要机制。
4.4 自动化工具先挡一轮，人肉Review只做高价值判断
Code Review如果在风格问题上花太多时间，是对人力成本的浪费。现在很多问题可以交给工具自动处理：格式问题交给prettier或eslint（前端）、gofmt（Go）、black（Python），通用的静态问题可以交给SonarQube、CodeQL等工具扫描一遍。人肉Review只关注逻辑正确性、架构合理性、安全性这三件事。
我通常在CI流水线里配置了以下检查阶段：
- 代码格式检查（Style Check）
- 单元测试和覆盖率门槛（Test Coverage Gate）
- 静态代码分析工具（Static Analysis）
- 安全检查（如依赖漏洞扫描）
这些自动检查过了，再进行人工Review，人工Review的质量会显著提升，因为注意力可以集中在真正需要人类判断的问题上。
5. Pull Request工作流：让分支合并和Review形成闭环
5.1 一次标准的Pull Request从创建到合并
Pull Request是分支管理和Review的连接点。没有它，分支就是一堆孤立的代码；有了它，分支流转的每个环节都有了记录和审查。下面是一套我验证过的Pull Request工作流：
- 从最新的develop拉出分支：确保你的起点是最新代码。
- 开发完成，推送分支：推送后执行
git push -u origin feature/PAY-1024。 - 创建Pull Request：标题格式用
[类型] 简述 (需求编号)，描述部分写清楚需求背景、改动范围、自测情况。 - 关联自动检查：确保CI已全部通过。
- 至少一个Reviewer确认通过：个人经验是让熟悉这块代码的同事做Reviewer，比随机分配有效得多。
- 冲突检查：如果CI提示有冲突，先把develop合并进功能分支解决掉，再请求重新审核。
- 合并：使用squash merge合入develop，删除远程分支。
- 本地清理：执行
git branch -d删除本地分支，git fetch --prune清理远端引用。
这里有一个我特意强调的细节：Pull Request的描述不是走过场，而是给Reviewer和其他同事节省时间的核心文档。写不清楚描述就相当于让10个人花时间猜你在干什么，这是团队效率最大的隐性损耗。
5.2 保护分支规则：把规范固化到工具里
光靠人记规范都不靠谱，必须把规范固化到远端仓库设置里。GitLab和GitHub都支持分支保护规则（Protected Branches），我建议对develop和master都开启以下保护：
- 禁止直接推送，只允许通过Pull Request合并。
- 至少需要一个评审人的批准。
- 所有讨论必须解决后才能合并。
- 合并前CI必须通过。
把规则固化到工具层面之后，规范的执行就不再依赖个人自觉，而是流程的硬性要求。这也让新成员一进来就按照正确的路径操作，不需要你一遍遍口头交代。
5.3 小型团队与大型团队的Review策略差异
团队规模不同，Review策略需要调整。3-5人的小团队，每个人对全代码库都比较熟悉，可以让任何一个成员当Reviewer，主要目标是"查漏补缺"而非"审查陌生人代码"。
10-20人的团队，代码开始出现明显的模块边界，Reviewer需要有对应模块的知识。这个阶段建议在CODEOWNERS文件里明确每个模块的负责人，Pull Request创建时自动分配给对应Owner。
20人以上的团队，跨模块Review几乎不可执行，此时Review策略必须分层：模块内部Review由Owner负责，跨模块改动还必须有架构层面的评审，避免某个人改了公共接口导致下游一片红。
6. 团队落地六件事：从规范到执行的经验清单
6.1 写一份极简的团队Git规范，而不是大而全的文档
规范文档写得越长，执行的人越少。我见过30多页的Git规范文档，从命令入门讲到子模块管理，看起来非常全面，实际上没人能看完，更没人能记住。团队规范只需要覆盖三块内容：分支命名规则、Pull Request流程、合并约定。每块不超过十行，直接明确"该怎么做"，不要太讲道理。
6.2 用模板降低所有人的操作成本
Pull Request模板是实现规范落地最有效的工具。在仓库的.github/pull_request_template.md（或GitLab对应的Merge Request模板）里写好固定的描述结构，提交人只需要填空。这样每个人提交的Pull Request信息完整度都会提高，评审人也不需要问东问西。
模板内容建议包括：
- 需求背景（为什么做）
- 改动范围（改了哪些模块）
- 自测清单（哪些场景自己验过了）
- 风险点（哪些地方需要重点Review）
6.3 每周代码复盘，把问题摊开说
只靠工具和规范还不够，人与人之间的对齐仍然需要一次面对面的会议。我推荐团队每周固定一个30分钟"代码复盘"会，不是批斗会，而是把这一周合入主干的所有Pull Request过一遍，挑出1-2个有代表性的案例做技术分享。
这种会议的价值有三个：一是让团队所有人了解彼此在做什么；二是把共性问题（比如人人都会犯的边界错误）暴露出来；三是给新人一个低门槛的学习机会。执行时注意控制氛围，重点是"从案例中学习"，不是"你怎么又这样"。
6.4 常见误区清单
最后整理几个我实际踩过的坑，供各位参考：
- 不要在周五下午做大型合并。周末前合入一个大功能，如果出问题，整个周末都会在救火。
- 不要把别人的代码改得面目全非。Review时如果需要大改，先和作者沟通，一起确认方向，而不是自己直接动手重写。
- 不要用一个巨型Pull Request"一锅端"。超过800行的Pull Request要强制拆分，哪怕拆完逻辑上暂时不完整，也要保证每次Review的粒度合理。
- 不要忽视提交信息的质量。
git commit -m "更新"是团队协作中最没营养的提交信息，建议使用feat、fix、refactor、docs、test、chore等结构化前缀。 - 不要把合并的提交历史搞得太乱。公共分支上禁止rebase、禁止force push，这会破坏所有人的本地仓库。
- 不要让Review卡太久。Pull Request打开超过48小时还未被Review，就是流程的阻塞点，应该主动提醒或升级处理。
6.5 从命令到制度，再到习惯
把Git分支管理和Code Review落地到团队里，根本上要经历三个阶段：第一阶段靠命令——大家先把命令敲熟，知道怎么创建分支、怎么合并；第二阶段靠制度——把规范明确写下来，在工具里配置强制规则；第三阶段靠习惯——当团队成员都体会到清晰工作流带来的效率提升之后，规范就不再需要反复强调，变成自然而然的行为。
我现在的团队已经运行这套流程接近两年，最大的体会是：一开始觉得规则多、繁琐，但坚持下来之后，新成员上手速度快了很多，代码质量稳定了很多，最直观的变化是"救火"的频率大幅下降。大家把精力花在写业务逻辑和设计架构上，而不是每天解决"谁的代码把谁改了"的问题。这就是协作规范最终应该带来的价值——它不是束缚，而是整个团队高效运行的地基。