Git 工程化实战：从提交规范到分支策略与团队协作

Git 是每个开发者的基本功，但"会用"与"用好"之间隔着一条清晰的鸿沟：提交信息混乱、分支随意、冲突频发、历史不可读。本文沉淀一套可落地的 Git 工程化实践，让版本历史成为团队的技术资产而非灾难现场。

一、提交信息规范：让历史可读、可追溯、可自动化

1.1 Conventional Commits 约定

统一采用"类型(范围): 描述"的格式：

feat(article): 新增文章定时发布功能
fix(book): 修复章节拖拽后消失的问题
perf(list): 优化文章列表分页查询，深翻页提速 40%
docs(readme): 补充部署说明
refactor(auth): 拆分认证中间件，抽离角色校验
test(core): 为 slugify 补充边界用例
chore(deps): 升级 gin 到 v1.10

Why：人类可读 + 机器可解析。配合工具可自动生成 CHANGELOG、语义化版本号、按类型过滤提交。

1.2 提交的原子性

一条提交只做一件事：一个 bug、一个特性、一次重构。不要混入无关改动。

判断标准：提交能否被单独回滚而不影响其他功能？ 如果不能，说明粒度太大。

二、分支策略：选择适合团队的那一套

2.1 三套主流模型对比

| 模型 | 适用规模 | 特点 | |------|----------|------| | GitHub Flow | 小团队、持续部署 | main + feature 分支，PR 即发布单元，简单直接 | | Git Flow | 有版本节奏的产品 | main / develop / feature / release / hotfix 五分支 | | Trunk-Based | 中大型、高发布频率 | 所有人提交主干，短命分支 + 特性开关 |

2.2 命名规范

feature/{issue-id}-{描述}    # 功能分支：feature/123-article-schedule
fix/{issue-id}-{描述}        # 修复分支：fix/456-chapter-dnd
hotfix/v{major}.{minor}.{patch}
release/v{major}.{minor}.0

分支生命周期原则：功能分支应短命（几天内合并），长期存活的分支是技术债。

2.3 保护规则

• main 分支禁止直接 push，只允许 PR 合入；
• PR 必须通过 CI（lint + test + build）才能合并；
• 合并方式按团队偏好统一（squash / merge / rebase），别混用。

三、解决冲突的正确姿势

冲突本身不可怕，可怕的是乱 merge 出来的冲突。推荐原则：

1. 小步提交、频繁同步：每天至少 rebase 一次 main，把冲突消解在"小范围"里；
2. 优先 rebase 而不是 merge 上游：

git fetch origin
git rebase origin/main   # 把自己的提交"叠"到最新 main 之上

3. 冲突解决后逐个检查：git status 列出 unmerged 文件，git diff 对比双版本，确认语义正确而非机械保留一方；
4. rebase 遇到大冲突时果断止损：git rebase --abort，改用 merge 或重新开分支。

四、拯救混乱历史：交互式 rebase

把多个碎提交整理成清晰的提交序列：

git rebase -i HEAD~5

在编辑器中调整：

pick 1a2b3c feat: 实现用户注册
fixup 4d5e6f 修正注册表单校验       # fixup 合并到上一个并丢弃信息
squash 7f8a9b 补测试                 # squash 合并但保留信息
reword 0c1d2e 调整提交说明

注意：只整理尚未推送的本地提交；已推送的共享提交不要 rebase，否则团队历史错乱。

五、找回丢失的提交：reflog

git reflog 是本地操作的"后悔药"，记录所有 HEAD 移动历史：

git reflog
# 2b1c3d4 HEAD@{0}: reset: moving to 2b1c3d4
# 5e9a8b7 HEAD@{1}: commit: 糟糕，误删了配置

git cherry-pick 5e9a8b7   # 找回误删的提交

只要提交曾在本地存在过，reflog 里就能找到——删除不可怕，可怕的是不会找回。

六、与 CI/CD 结合的门禁

6.1 PR 检查清单（GitHub Actions / GitLab CI）

jobs:
  quality:
    steps:
      - run: go vet ./... && go test -race ./...
      - run: npm run typecheck && npm run lint
      - run: ./scripts/check-commit-style.sh   # 校验提交信息规范

6.2 自动版本与发布

基于 Conventional Commits 自动 bump 版本：

• feat → minor；fix → patch；BREAKING CHANGE → major；
• 标签 vX.Y.Z 触发构建与部署流水线；
• CHANGELOG 由工具从提交信息生成，无需手工维护。

七、团队协作的十条纪律

1. 不在 main 上直接开发，所有改动走 PR；
2. PR 描述写清背景、方案、验证结果，别只甩一个标题；
3. review 他人代码时关注意图而非风格，风格交给 linter；
4. 提交信息讲"为什么"，代码注释讲"怎么做"；
5. 敏感文件立即进 .gitignore（.env、密钥、构建产物），误提交立即轮换密钥；
6. 大文件不入库（用 Git LFS 或对象存储）；
7. 每周至少同步一次上游，避免分支腐烂；
8. hotfix 从 main 拉分支，修复后同时合回 main 和 develop；
9. tag 只打不可变版本，不移动已发布的标签；
10. 保持仓库整洁：定期清理已合并分支、大文件、悬空对象。

结语

Git 的威力 20% 来自命令，80% 来自约定。一套团队认可的提交规范 + 分支模型 + 门禁机制，能让"协作"从互相干扰变成并行推进。与其在冲突泥潭里反复挣扎，不如先把规范和纪律立起来——工程化的本质，就是把偶然的熟练变成必然的可靠。