Git 分支策略与协作规范

分支模型没有银弹，只有和团队规模、发布节奏匹配的取舍。本文给出两套可直接采用的模型，以及提交信息、合并、救场的具体做法。

一、两套主流模型

Trunk-Based（主干开发）：所有人频繁（至少每天）合入 main，未完成功能用 Feature Flag 隐藏，发布直接从主干打 tag。

Git Flow（分支开发）：main / develop 长期存在，配 feature、release、hotfix 三类临时分支。

选择建议：Web 服务、能随时发布 → Trunk-Based；有明确版本号、需同时维护多个线上版本（如 App、小程序、私有化交付） → Git Flow 或简化的 release 分支。

二、推荐的日常流程（Trunk-Based 简化版）

# 1. 从最新主干拉短命分支
git switch main && git pull --rebase
git switch -c feat/order-export

# 2. 小步提交，提交前先跑本地检查
git add -p                    # 分块暂存，避免夹带无关改动
git commit -m "feat(order): 支持按时间范围导出订单"

# 3. 推送并发起 MR/PR
git push -u origin feat/order-export

# 4. 合入前同步主干（保持线性历史）
git fetch origin && git rebase origin/main
git push --force-with-lease  # 比 --force 安全：远端有他人更新时会拒绝

git pull --rebase 与 --force-with-lease 是两条最值得写进团队规范的习惯：前者避免无意义的合并提交，后者避免覆盖同事的推送。

三、提交信息规范（Conventional Commits）

<type>(<scope>): <subject>

<body：为什么这么改，必要时写>
<footer：关联 issue / BREAKING CHANGE>

规范的实际收益是自动生成 changelog 和语义化版本号，以及半年后 git log 还能看懂。反例：update、fix bug、111、asdf。

四、合并方式怎么选

团队统一一种即可，混用最容易让 git log --graph 变成蜘蛛网。

五、常见救场命令

git reflog                       # 找回「误删分支 / 误 reset」的提交，第一反应应该是它
git restore --staged <file>      # 取消暂存
git commit --amend --no-edit     # 只改最近一次提交（未推送时）
git revert <sha>                 # 已推送的提交用反向提交撤销，不要 rewrite 公共历史
git stash push -m "WIP"          # 临时切任务
git bisect start / bad / good    # 二分定位引入 bug 的提交

红线：已推送到共享分支的历史，不用 rebase + force push 改写，用 revert。

六、常见坑与对策

七、落地检查清单

• [ ] 主干设置保护规则：至少 1 人评审 + CI 通过
• [ ] 团队统一提交信息格式，并有 lint 校验（commitlint）
• [ ] .gitignore 覆盖依赖目录、构建产物、本地环境文件、IDE 配置
• [ ] 每个版本打 tag，tag 能对应到发布记录
• [ ] 有文档写明「线上出问题时如何 cherry-pick / revert 热修」

八、小结

分支策略的目标只有一个：让集成尽可能早、尽可能频繁地发生。任何让代码在分支里躺更久的流程，都在把风险攒到最后一刻。