仓库乱不乱，很多时候不是代码写得差，而是"合并规则"没立好：谁都能直接推主分支、功能分支无人 review 就合、冲突天天靠人肉解、发布时不知道哪些代码上去了。Git 提供了强大的分支/合并能力，但"要不要用、怎么用、约定什么"是需要策略的。分支策略（branching strategy）解决的是"多人协作时，如何让主线稳定、功能可并行、发布可回溯"。这篇讲清 Git 分支策略解决什么、三种主流模型怎么选、提交/合并规约怎么立，以及常见坑与边界。
一、Git 分支策略解决什么：让"主线永远可发布、功能不互相踩"
分支策略不是"复杂度高的就高级"，而是"匹配团队大小与发布频率"的一套约定。它要解决的痛点：一是"主线被污染"——谁都能直接改 main，坏代码一推就上生产；二是"并行踩踏"——多人同时改同段代码，天天解不完的冲突；三是"发布失控"——上线时不知道哪些提交算数、出问题不知回滚到哪。分支持模型的核心是给"主线、功能、发布、修复"划分不同的分支与合并规则：功能在分支开发、review 后合回，主分支保持随时可部署，紧急修复走单独快速通道。对自托管/小团队，重点是"立够用的约定"，别被重流程压垮。
二、三种主流模型的取舍
Git 分支模型有谱系，从简到重各有适用：一是"主干/Mainline（或 GitFlow 变体）"——所有功能都在主干上小步提交、配 feature 分支与 PR/MR 合入，配合 tag 发布（类似主干开发、频繁发布，Instagram/Netflix 式），最适合"小步高频、每次都能发"的团队；二是经典 GitFlow——有 main（只收发布）、develop（集成）、feature/release/hotfix 五类分支，负责、可回溯，但流程重，适合周期性发布、需严格管理的项目；三是"GitHub Flow / Trunk-Based 简化"——只有 main + feature 短分支，feature 合入前务必过 CI 与 review，发布靠 tag/自动流程，最轻量。小团队/自托管我推荐"简化主干 + tag 发布"：main 长期可发布、功能分支短命、合入必须过 CI 与 review、回头用 tag 定位版本——既守住秩序又不背 GitFlow 的仪式感。
# 一种"轻量主干 + tag 发布"的最小约定
# 1) 从最新 main 切功能分支
git checkout main && git pull
git switch -c feat/xxx
# 2) 本地小步提交，合入前先跑 CI / review
git add . && git commit -m "feat(xxx): 说明改动"
git push -u origin feat/xxx # 在 Git 平台发起 MR/PR
# 3) 合回 main 后打 tag 标记一个可发布版本
git checkout main && git pull
git tag v1.4.2 && git push origin v1.4.2GitFlow 的场景也有存在价值（比如必须"定期发版本、官网与补丁分离"），但前提是团队真需要那套高度与纪律；很多小团队套 GitFlow 只学会了仪式、没换来自我它的收益。
三、提交/合并规约：把"约定"固化成每个人都在用的习惯
策略落地靠两块：提交规范与合并规矩。提交规范用 Conventional Commits 这类统一格式（`feat/fix/chore/...：描述`），让日志可读、可自动生成 changelog、配合 PR 标题可见意图；合并规矩一般是"function 分支合 main 必须过 CI + 至少一人 review + 保持最近提交"（少用大 rebase、多用合并或 squash），CI 挡掉明显错误、review 挡掉设计问题，top 分支不崩版。把都能推 main 的权限收掉，推分支 + MR/PR 成唯一合入通道，是最好的纪律。别让"谁都能直接改 main"成为常态。
# 用 pre-commit / commitlint 之类把提交信息规范固化成钩子（示例 commitlint cfg）
# .commitlintrc.json
{ "extends": ["@commitlint/config-conventional"] }
# 常见约定：合入 main 前要过 CI；功能分支必须短命（改完即合/即删）
# 保护 main：禁止直接 push，只允许 MR/PR + review 后合入四、典型坑与边界：策略服务于"发布与协作"，别被工具绑定
分支策略的坑多来自"过度设计"与"纪律缺失"。过度设计：小团队硬套五类分支 GitFlow，日常一半精力耗在分支切换与合并上，收益远小于开销；缺纪律：定了策略但谁都能绕过（直接 push main、review 走过场），等于没有策略。另一个坑是"把长期 feature 分支拖成大分支"——分支越久越难合、冲突越多，应尽早拆小、频繁合入主干减少分叉。边界要认清：策略管"怎么协作与合并"，不替代工程能力（测试、CI 质量、review 深度）；"主干可变/不可变"、合并要求严格，都要匹配团队真实规模。把"信息传递清晰 + 主线常绿 + 发布的纯净"当成目标，选最轻的够用模型执行到位，是 Git 协作的长久之道。
