Git 工业化协作：分支策略、Commit 规范及 Rebase Merge 对比

极简工作流（适合微服务/CD）：

main (始终可部署) │ ├─ feature/加急需求 A (PR Review 后 Squash Merge 到 main，自动部署) └─ feature/优化需求 B (PR Review 后 Squash Merge 到 main，自动部署)

关键约束：

• CI/CD Gate：PR 必须通过自动化测试（单元测试 + 集成测试 + 安全检查）
• 特性开关（Feature Toggle）：未完成的功能通过配置中心关闭，允许半成品代码合并到 main

二、Commit 规范：Conventional Commits

2.1 结构化提交格式

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

标准类型（Type）：

示例：

feat(order): 增加订单批量导出功能
- 支持 CSV/Excel 格式导出
- 限制单次导出数量≤10000 条
- 添加导出任务异步队列
Closes JIRA-1234

fix(payment): 修复并发下单时库存超卖
使用 Redis 分布式锁替代数据库乐观锁，解决高并发场景下的竞态条件。
Refs: #456

2.2 工具链强制校验

Husky + Commitlint 配置：

// package.json
{
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
      "pre-commit": "lint-staged"
    }
  },
  "commitlint": {
    "extends": ["@commitlint/config-conventional"],
    "rules": {
      "scope-enum": [2, "always", ["user", "order", "payment", "infra"]],
      "subject-max-length": [2, "always", 72]
    }
  }
}

Gradle 项目替代方案（无 Node 环境）：

// build.gradle
plugins {
    id 'cz.alenkacz.gradle.gitpush' version '1.0.0'
}

gitHooks {
    hooksDirectory = file(".git/hooks")
    hook("commit-msg") {
        script = """
            #!/bin/bash
            commit_regex='^(feat|fix|docs|style|refactor|perf|test|chore)(\\(.+\\))?: .+'
            if ! grep -iqE "\${commit_regex}" "\$1"; then
                echo "ERROR: Commit message must follow Conventional Commits"
                exit 1
            fi
        """
    }
}

三、Rebase vs Merge：历史整饰的抉择

3.1 机制差异图解

Merge（合并提交）：

A---B---C (main)
       \
        D---E---M (feature，产生 Merge Commit)

• 保留完整分支历史，形成"分叉 - 合并"图形
• 优点：忠实记录开发轨迹，回滚整个分支方便
• 缺点：历史图呈"意大利面条"状，难以线性阅读

Rebase（变基）：

A---B---C (main)
       \
        D'---E' (feature，提交哈希重写)

• 将 feature 分支的提交"搬移"到 main 最新提交之后，形成线性历史
• 优点：历史干净，bisect 调试高效
• 缺点：重写历史，共享分支风险极高

3.2 决策树（When to Use）

是否已 Push 到共享远程分支？
├── 是 → 禁止使用 Rebase（使用 Merge）
│   └── 例外：个人 feature 分支且团队知晓
└── 否 → 本地未共享分支
    ├── 是否需要干净历史？ → Rebase
    └── 是否需要保留开发轨迹？ → Merge

3.3 交互式 Rebase（Interactive Rebase）

场景：功能开发完成，清理"wip"、"fix typo"等临时提交

# 假设当前 feature 分支领先 main 5 个提交
git checkout feature
git rebase -i main
# 进入编辑器，执行操作：
# pick a1b2c3d feat(订单): 初始化订单模块
# squash e4f5g6h fix(订单): 修复拼写错误
# squash i7j8k9l feat(订单): 补充校验逻辑
# drop m0n1o2p wip: 调试中勿合
# pick q3r4s5t feat(订单): 完成支付对接
# 结果：5 个提交压缩为 2 个干净提交

黄金法则：

永远不要对已经 Push 到公共仓库的提交执行 Rebase，否则会造成同事代码历史分叉，产生"幽灵提交"。

3.4 冲突解决策略对比

Merge 冲突：

• 一次性解决所有冲突（分支末端合并）
• 冲突信息保留在 Merge Commit 中

Rebase 冲突：

• 可能需多次解决（逐提交应用）：

git rebase main
# 解决冲突
git add .
git rebase --continue
# 应用下一个提交，可能再次冲突
# 若放弃：git rebase --abort

四、Cherry-Pick：精确提交搬运

4.1 使用场景

场景 A：热修复（Hotfix）

• main 分支发现严重 Bug，需紧急修复
• 但 develop 分支已包含大量未测试 feature，不能直接合并
• 方案：在 main 上修复，Cherry-Pick 到 develop 保持同步

场景 B：功能移植

• 客户 A 定制版本需要客户 B 已开发的某个功能，但不需要 B 的其他改动
• 方案：Cherry-Pick 特定提交（而非整个分支 Merge）

4.2 实战操作

# 1. 找到需要搬运的提交哈希（在源分支）
git log develop --oneline -10
# 输出：a1b2c3d feat(payment): 增加支付宝回调重试机制

# 2. 切换到目标分支
git checkout release/v2.0.1

# 3. 执行 Cherry-Pick（默认创建新提交）
git cherry-pick a1b2c3d

# 4. 若冲突：解决后提交
git add .
git cherry-pick --continue

# 5. 若放弃：git cherry-pick --abort

多提交区间搬运：

# 搬运从 oldest 到 newest 的所有提交（不包括 oldest）
git cherry-pick oldest..newest
# 示例：搬运最近 3 个提交
git cherry-pick HEAD~3..HEAD

4.3 Cherry-Pick vs Rebase：区别与选择

风险告警：

• Cherry-Pick 的提交若包含依赖（如依赖后续提交的文件），会导致编译错误或运行时异常
• 解决方案：使用 git cherry-pick -x（自动附加原提交信息，便于追溯）

五、工业化配置与 Hook

5.1 全局 Git 配置（团队规范）

# 1. 分支排序（按最近提交时间，而非字母）
git config --global branch.sort -committerdate

# 2. 强制 rebase 使用交互式（可视化编辑）
git config --global sequence.editor "code --wait"

# 3. Pull 策略（避免自动 Merge，强制 rebase 或仅 fetch）
git config --global pull.rebase true
# 或：git config --global pull.ff only（仅快进）

# 4. 提交模板
git config --global commit.template ~/.gitmessage
# 模板内容：
# [type](scope): subject
#
# Body...
#
# Refs: JIRA-XXX

5.2 分支保护规则（GitLab/GitHub）

# .gitlab-ci.yml 中的 Only/Except 已过时，改用 Rules+Protected Branches
# GitLab 设置 → Repository → Protected Branches：
# main:
#   - Push: Maintainers only
#   - Merge: 2 Approvals required + Pipeline must pass + No unresolved discussions
# develop:
#   - Push: Developers + Maintainers
#   - Merge: 1 Approval required

六、生产级 Checklist

□ 分支策略：团队是否明确使用 Git Flow/GitHub Flow，并在 README 中图示化
□ 分支命名：是否包含 JIRA ID（feat/JIRA-123-描述），便于关联需求
□ 提交信息：是否配置 Commitlint 强制 Conventional Commits 规范
□ Rebase 禁忌：是否在 CI 中检测 Force Push 到 main/develop（禁止操作）
□ Cherry-Pick 审计：关键修复是否双轨同步（main+develop），防止回归
□ 合并策略：PR 是否使用 Squash Merge（保持 main 线性）或 Merge Commit（保留轨迹）
□ 清理策略：已合并的 Feature 分支是否自动/定期删除（防止僵尸分支）
□ 大文件：是否配置 Git LFS（Large File Storage），防止仓库膨胀

核心认知：Git 协作的本质是历史管理的共识。Rebase 提供"精装书"式的可读历史，Merge 保留"手稿"式的开发轨迹，没有绝对优劣，只有团队约定的一致性。在微服务时代，GitHub Flow 因其与 CI/CD 的无缝集成，正逐步取代笨重的 Git Flow 成为云原生首选。