Git工作流与分支管理

Claude Code 工作流专题 · 用Claude Code自动化Git操作

专题：Claude Code 工作流系统学习

关键词：Claude Code, Git, Git Flow, GitHub Flow, 分支管理, Conventional Commits, Git Hooks, Squash

一、概述

Git是现代软件开发中不可或缺的版本控制工具，而Claude Code作为AI编程助手，可以极大地提升Git工作流的效率。本文将全面介绍Git工作流的核心模式、分支管理的最佳实践、提交规范、合并冲突解决以及Git Hooks集成，并展示如何将这些实践与Claude Code的能力相结合，实现Git操作的自动化和智能化。

核心观点：将Git工作流的规范性与Claude Code的自动化能力相结合，可以显著提升团队协作效率、降低合并冲突风险、保证代码质量。规范化的流程配合AI辅助，是现代DevOps实践的重要方向。

一个健康的Git工作流应当涵盖以下几个维度：工作流模式的选择、分支命名与清理策略、提交信息规范、冲突解决机制、钩子脚本集成，以及AI工具的辅助配置。下面我们将逐一深入探讨。

二、Git工作流模式

不同的团队和项目需要选择不同的Git工作流模式。以下是四种主流的工作流模式，各有其适用场景和优缺点。

2.1 Git Flow

Git Flow是一种经典的分支模型，由Vincent Driessen于2010年提出。它定义了五类分支：master（主分支）、develop（开发分支）、feature（功能分支）、release（发布分支）和hotfix（热修复分支）。每种分支都有明确的职责和生命周期。

# Git Flow 典型分支结构
main (master) ──────●──────────────●──────────●──
                      \            / \        /
develop  ──●──●──●────●──●──●────●──●──●──●──
            |     |         |         |
         feature feature   release   hotfix
            |     |         |         |
            ●     ●         ●         ●

# 使用 git-flow 扩展初始化仓库
git flow init

# 创建功能分支
git flow feature start user-auth

# 完成功能分支（自动合并回 develop）
git flow feature finish user-auth

# 创建发布分支
git flow release start v1.2.0

# 完成发布（合并到 main 和 develop，打标签）
git flow release finish v1.2.0

# 创建热修复分支（从 main 创建）
git flow hotfix start security-patch-1.0.1

# 完成热修复（合并到 main 和 develop）
git flow hotfix finish security-patch-1.0.1

适用场景：大型项目、有固定发布周期的团队、需要同时维护多个版本的软件产品。缺点是分支较多，操作复杂，不适合持续部署。

2.2 GitHub Flow

GitHub Flow是一种更轻量的工作流模型，只有main一个长期分支，所有开发都在功能分支上进行，通过Pull Request（PR）进行代码审查和合并。它非常适合持续部署和快速迭代的团队。

# GitHub Flow 典型流程

# 1. 从 main 创建功能分支
git checkout -b feat/add-login-page main

# 2. 在分支上多次提交
git add .
git commit -m "feat: add login form component"
git commit -m "feat: add form validation"
git commit -m "feat: integrate auth API"

# 3. 推送到远程
git push -u origin feat/add-login-page

# 4. 创建 Pull Request（在 GitHub 网页上或使用 gh CLI）
gh pr create --title "feat: add login page" \
  --body "实现登录页面，包括表单验证和认证API集成"

# 5. 代码审查通过后合并（Squash merge）
gh pr merge --squash

# 6. 部署 main 分支的最新代码
git checkout main && git pull

最佳实践：GitHub Flow要求功能分支的生命周期尽量短（通常不超过一天），PR越小越好，便于代码审查。Claude Code可以在PR描述自动生成和代码审查中发挥重要作用。

2.3 GitLab Flow

GitLab Flow在GitHub Flow的基础上增加了环境分支（如staging、production）和版本分支的概念，适合需要多环境部署的团队。它通过"上游优先"原则确保代码变更从开发环境逐步流向生产环境。

# GitLab Flow 环境分支示例
# main → pre-production → production

# 环境分支策略：合并到 main 后，逐步向上游合并
git checkout main
git merge feat/add-payment
git push

# 部署到预生产环境
git checkout pre-production
git merge main
git push origin pre-production

# 部署到生产环境
git checkout production
git merge pre-production
git push origin production

# 版本分支策略（用于需要维护旧版本的情况）
git checkout v1-stable
git cherry-pick abc123def  # 从 main 挑选修复提交
git push origin v1-stable

2.4 Trunk-Based Development（主干开发）

主干开发是一种极简的工作流模式，所有开发者直接在main（主干）分支上提交，或者创建非常短命的特性分支（不超过几小时）。它要求团队具备高度的纪律性和自动化测试覆盖率。

# Trunk-Based Development 典型流程

# 方式一：直接在主干提交（适用于极小型团队）
git checkout main
git pull --rebase
# 修改代码
git commit -m "fix: correct tax calculation"
git push

# 方式二：短命特性分支（推荐）
git checkout -b short-lived-feat main
# 快速实现功能
git commit -m "feat: add dark mode toggle"
git push -u origin short-lived-feat
# 立即创建 PR 并合并（不跨夜）
gh pr create --fill
gh pr merge --squash

# 方式三：使用特性开关（Feature Toggle）
# 代码中用条件判断控制功能是否可见
if feature_flags.is_enabled("dark_mode"):
    render_dark_mode_toggle()

四种模式对比：Git Flow适合复杂项目和多版本维护；GitHub Flow适合快速迭代的SaaS产品；GitLab Flow适合多环境部署的企业项目；主干开发适合成熟稳定的小团队。选择哪种模式取决于团队规模、发布频率和项目复杂度。

工作流模式	分支复杂度	发布频率	适用团队	CI/CD适配
Git Flow	高（5类分支）	低频（周期发布）	大型团队	中等
GitHub Flow	低（仅main+特性）	高频（持续部署）	中小团队	优秀
GitLab Flow	中（环境分支）	中频（按环境推进）	企业团队	良好
Trunk-Based Dev	极低（几乎无分支）	极高（每天多次）	精英小团队	必须优秀

三、分支管理自动化

分支管理是Git工作流中最容易被忽视但影响最大的环节。良好的分支管理策略包括命名规范、自动化清理、保护规则和合并策略。

3.1 分支命名规范

统一的分支命名规范让团队成员一眼就能看出分支的用途。推荐的命名格式为：<类型>/<描述>，其中类型包括feature、bugfix、hotfix、release、chore等。

# 分支命名规范示例

# 功能分支
feature/user-auth          # 新功能：用户认证
feature/add-search-bar     # 新功能：搜索栏
feature/stripe-payment-v2  # 新功能：Stripe支付V2

# 修复分支
bugfix/login-error         # Bug修复：登录错误
bugfix/null-pointer-fix    # Bug修复：空指针
bugfix/cors-issue          # Bug修复：跨域问题

# 热修复分支（从 main 创建，修复线上问题）
hotfix/security-patch-1.0.1   # 安全补丁
hotfix/payment-critical-fix   # 支付关键修复

# 发布分支
release/v1.2.0             # 版本发布
release/v2.0.0-rc1         # 发布候选

# 杂项分支
chore/upgrade-deps         # 依赖升级
chore/cleanup-logs         # 日志清理
docs/api-docs-refactor     # 文档重构
refactor/db-layer          # 代码重构

# 使用 Claude Code 自动生成分支名
# 功能描述 → 自动生成符合规范的分支名
# 例如："实现用户登录功能"
# Claude Code 生成: feat/user-login-page

3.2 分支清理自动化

长时间不清理的远程分支会造成仓库混乱，增加管理成本。可以通过脚本自动化清理已合并的分支和过期的陈旧分支。

# 清理本地已合并到 main 的分支（除了 main 和当前分支）
git branch --merged main | grep -v "\* main" | xargs -n 1 git branch -d

# 清理远程已合并的分支
git branch -r --merged origin/main | \
  grep -v "origin/main\|origin/HEAD" | \
  sed 's/origin\///' | \
  xargs -n 1 git push origin --delete

# 完整的自动化清理脚本：cleanup-branches.sh
#!/bin/bash
# 清理超过30天没有活动的陈旧分支
STALE_DAYS=30
echo "正在检查超过 ${STALE_DAYS} 天的陈旧分支..."

for branch in $(git branch -r | grep -v "origin/main\|origin/HEAD\|origin/production"); do
    last_commit=$(git log -1 --format="%ci" "$branch" 2>/dev/null)
    if [ -z "$last_commit" ]; then continue; fi
    commit_ts=$(date -d "$last_commit" +%s)
    now_ts=$(date +%s)
    age_days=$(( (now_ts - commit_ts) / 86400 ))
    if [ "$age_days" -gt "$STALE_DAYS" ]; then
        echo "陈旧分支: $branch ($age_days 天无活动)"
        # 询问是否删除
        echo "删除请按 y: "
        read -r confirm
        if [ "$confirm" = "y" ]; then
            remote_branch="${branch#origin/}"
            git push origin --delete "$remote_branch"
            echo "已删除: $remote_branch"
        fi
    fi
done

# Claude Code 可以自动执行上述清理操作
# 在 chat 中直接输入：
# "清理所有已经合并到 main 的分支"

3.3 分支保护规则

在GitHub/GitLab中配置分支保护规则，可以防止意外的强制推送和直接推送到重要分支。至少应对main和production分支启用保护。

# 使用 GitHub CLI 配置分支保护规则（需要管理员权限）
# 设置 main 分支保护规则
gh api repos/:owner/:repo/branches/main/protection \
  --method PUT \
  --input - <<'JSON'
{
  "required_status_checks": {
    "strict": true,
    "contexts": ["continuous-integration", "code-review"]
  },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "required_approving_review_count": 1,
    "dismiss_stale_reviews": true,
    "require_code_owner_reviews": true
  },
  "restrictions": null,
  "required_linear_history": true,
  "allow_force_pushes": false,
  "allow_deletions": false,
  "block_creations": false
}
JSON

# GitLab CI 中的分支保护配置（.gitlab-ci.yml）
variables:
  GIT_DEPTH: 50

# 只在 main 分支上运行部署任务
deploy-production:
  stage: deploy
  script:
    - echo "Deploying to production..."
  only:
    - main
  environment:
    name: production

3.4 Squash 合并策略

Squash Merge（挤压合并）将特性分支上的多个提交压缩为一个提交，保持主分支提交历史的整洁。这是GitHub Flow推荐的做法。

# Squash 合并的三种方式

# 方式一：GitHub PR 合并时选择 Squash and merge（推荐）
gh pr merge --squash --subject "feat: add user authentication" \
  --body "实现用户登录/注册功能，包括：
- 邮箱密码登录
- OAuth 第三方登录
- JWT Token 管理"

# 方式二：手动 Squash 合并
git checkout main
git merge --squash feat/user-auth
git commit -m "feat: add user authentication"

# 方式三：交互式 Rebase Squash
git checkout feat/user-auth
# 将最近4个提交压缩为1个
git rebase -i HEAD~4
# 在交互界面中将 pick 改为 squash（保留第一个为 pick）
# pick abc123 feat: init auth
# squash def456 feat: add login form
# squash ghi789 feat: add validation
# squash jkl012 feat: integrate API

# 使用 Claude Code 进行 Squash 合并的提示模板
# "请将分支 feat/user-auth squash 合并到 main，提交信息为：
# feat: add user authentication
#
# 实现用户登录/注册功能，包括邮箱密码登录、OAuth 和 JWT Token 管理"

注意：Squash合并会丢失特性分支上的中间提交历史。对于需要保留详细开发记录的场景（如审计需求），建议使用普通的merge commit而非squash。选择何种策略应在团队内达成共识并写在CLAUDE.md中。

四、提交规范

规范的提交信息不仅让Git历史更加可读，还能自动化生成changelog、辅助版本管理。Conventional Commits（约定式提交）是目前最广泛采用的提交规范标准。

4.1 Conventional Commits 约定式提交

Conventional Commits规范定义了一种结构化的提交信息格式：<类型>[可选作用域]: <描述>，配合可选的正文和脚注。常见的类型包括feat、fix、docs、style、refactor、test、chore等。

# Conventional Commits 格式
# <type>[optional scope]: <description>
#
# [optional body]
#
# [optional footer(s)]

# 示例一：新功能
feat: add user login page

实现邮箱密码登录功能，包括表单验证和错误提示。
Closes #123

# 示例二：Bug修复（带作用域）
fix(api): handle null response from payment gateway

当支付网关返回空响应时，之前会抛出NullPointerException。
现在返回默认错误信息。
Fixes #456

# 示例三：破坏性变更
feat(api)!: change authentication endpoint structure

将 /api/v1/auth/login 改为 /api/v2/auth/sign-in
旧的端点将在 v1.2.0 版本中弃用。

BREAKING CHANGE: 认证端点URL结构变更

# 示例四：文档更新
docs(README): add installation guide for Docker

# 示例五：代码重构
refactor(db): migrate from MongoDB to PostgreSQL

# 示例六：性能优化
perf(cache): implement Redis caching for product queries

减少数据库查询次数，商品查询响应时间降低 80%

# 示例七：测试
test(auth): add unit tests for JWT token validation

# 常用类型速查表
# feat      新功能
# fix       Bug修复
# docs      文档变更
# style     代码格式（不影响功能）
# refactor  代码重构
# perf      性能优化
# test      测试相关
# chore     构建/工具变更
# ci        CI配置变更
# build     构建系统变更
# revert    回退提交

4.2 Commitizen 与 Cz 工具

Commitizen是一套帮助开发者编写符合Conventional Commits规范的交互式工具。通过命令行提示引导开发者填写提交信息的各个部分，避免格式错误。

# 安装 Commitizen CLI（全局）
npm install -g commitizen

# 初始化项目使用 cz-conventional-changelog 适配器
commitizen init cz-conventional-changelog --save-dev --save-exact

# 或者在 package.json 中配置
# package.json
{
  "scripts": {
    "commit": "cz"
  },
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }
}

# 使用 Commitizen 提交
git add .
npm run commit
# 或直接使用
cz

# 将会出现交互式提示：
# ? Select the type of change that you're committing:
#   feat:     A new feature
#   fix:      A bug fix
#   docs:     Documentation only changes
#   style:    Code style changes
#   refactor: Code refactoring
#   perf:     A code change that improves performance
#   test:     Adding missing tests
#   chore:    Changes to the build process
# ? What is the scope of this change? (e.g., auth, api, db)
# ? Write a short description:
# ? Provide a longer description:
# ? Are there any breaking changes?
# ? Does this change affect any open issues?

# 使用 Claude Code 生成符合 Conventional Commits 规范的提交信息
# "请帮我生成 git commit 信息，改动了：
# 1. 添加了用户登录表单组件
# 2. 集成了 JWT 认证 API
# 3. 添加了表单验证逻辑"

4.3 提交信息模板

通过Git的commit.template配置，可以为团队提供统一的提交信息模板，帮助开发者写出规范的提交信息。

# 创建提交信息模板文件 .gitmessage
cat > .gitmessage << 'EOF'

# <type>(<scope>): <subject>
# |<---- 尽量控制在50字符以内 ---->|
#
# |<---- 正文每行72字符 ---->|
# 详细描述本次提交的内容和原因。
# 可以写多行，每行不超过72个字符。
#
# 关闭的 Issue: #123, #456
# Breaking Changes: 描述破坏性变更
#
# 类型可选值:
# feat, fix, docs, style, refactor, perf, test, chore, ci, build
EOF

# 配置 Git 使用模板
git config --global commit.template .gitmessage

# 现在每次执行 git commit 时，编辑器会自动加载模板内容

# Claude Code 推荐的提交信息模板配置
# 在 CLAUDE.md 中添加以下规则：
#
# ## Git 提交规范
#
# 所有 Git 提交必须遵循 Conventional Commits 规范：
#
# 1. 格式：(): 
# 2. type 可选值：feat, fix, docs, style, refactor, perf, test, chore
# 3. subject 使用英文或中文，首字母不大写，末尾不加句号
# 4. 关联 Issue 使用 Closes/Fixes/Refs 关键字
# 5. breaking changes 必须在类型后加 ! 并在脚注中说明

4.4 自动生成 Changelog

基于Conventional Commits的提交历史，可以自动化生成changelog文件。standard-version和semantic-release是两种常用的工具。

# 使用 standard-version 自动生成 changelog

# 安装
npm install -g standard-version

# 生成 changelog 并自动 bump 版本号
standard-version

# 指定发布类型
standard-version --release-as minor
standard-version --release-as patch
standard-version --release-as major

# 版本号 bump 规则（基于提交类型自动判断）
# feat → 增加 MINOR 版本号
# fix → 增加 PATCH 版本号
# BREAKING CHANGE → 增加 MAJOR 版本号

# 使用 semantic-release 进行自动化发布
# .releaserc.json
{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/github",
    "@semantic-release/git"
  ]
}

# 生成的 CHANGELOG.md 示例
# # Changelog
#
# ## [1.2.0] - 2026-05-08
#
# ### Features
# * add user login page (abc123)
# * implement payment gateway (def456)
#
# ### Bug Fixes
# * handle null response in payment API (ghi789)
#
# ### Documentation
# * add Docker installation guide (jkl012)

# 使用 Claude Code 从提交历史生成 changelog
# "请基于 main 分支最近10个提交，生成 CHANGELOG.md 内容"

# Claude Code 可以直接读取 git log 并结构化输出
git log --oneline --no-merges HEAD~10..HEAD --format="%s"

"良好的提交规范是团队协作的基础设施。Conventional Commits不仅让Git历史变得可读，更是自动化版本管理和changelog生成的前提。用Claude Code辅助编写提交信息，可以确保每次提交都符合规范。"

五、合并冲突解决

合并冲突是Git协作中不可避免的挑战。掌握冲突检测、自动合并策略和解决技巧，可以显著减少冲突带来的困扰。

5.1 冲突检测与预防

尽早检测冲突并采取预防措施，比事后解决冲突要高效得多。以下是一些实用的冲突检测和预防策略。

# 在合并前检测冲突
# 方法一：使用 git merge --no-commit --no-ff
git checkout main
git merge --no-commit --no-ff feature/login-page
if [ $? -ne 0 ]; then
    echo "检测到冲突，正在中止合并..."
    git merge --abort
fi

# 方法二：使用 git diff 比较分支差异
git diff main...feature/login-page --stat

# 方法三：频繁 rebase 特性分支到最新的 main
git checkout feature/login-page
git fetch origin
git rebase origin/main
# 如果 rebase 过程中出现冲突，逐一解决后继续
git add .
git rebase --continue

# 使用 git rerere（复用已记录的冲突解决方案）
git config --global rerere.enabled true
# 开启后，Git 会自动记录并复用冲突解决方式

# Claude Code 辅助冲突预防
# 在 CLAUDE.md 中配置冲突预防规则：
#
# ## 冲突预防
# 1. 特性分支每天至少 rebase 一次 main
# 2. 大功能拆分为多个小 PR，每个 PR 不超过 200 行变更
# 3. PR 描述中标注可能冲突的模块

5.2 自动合并策略

Git提供了多种合并策略，合理选择可以最大化自动合并的成功率。recursive策略是默认的合并策略，而ours、theirs等特殊策略适用于特定场景。

# Git 合并策略

# 默认递归策略（两个分支合并时自动使用）
git merge feature/login-page
# 等价于
git merge -s recursive feature/login-page

# 快进合并（仅当分支线性时使用）
git merge --ff-only feature/login-page
# 如果无法快进，则失败（不会创建合并提交）

# 非快进合并（始终创建合并提交）
git merge --no-ff feature/login-page
# 推荐用于保留分支历史

# 子树合并（适用于将一个仓库合并到子目录）
git merge -s subtree feature/external-lib

# 自定义合并驱动（用于特定文件的自动合并）
# .gitattributes 中配置
*.json merge=json-merge
# 然后在 .gitconfig 中定义 json-merge 驱动
git config merge.json-merge.driver "python merge-json.py %O %A %B %L"

# 使用 git-merge自动化策略
# 如果某个文件的变更互不冲突，Git 会自动合并
# 对于冲突的文件，以下策略可以尝试：
#
# 1. 保留我们的版本（丢弃对方的）
git merge -X ours feature/login-page

# 2. 保留对方的版本（丢弃我们的）
git merge -X theirs feature/login-page

# 3. 使用 patience 算法（更精确的差异计算）
git merge -X patience feature/login-page

5.3 三方合并与冲突解决

Git的三方合并算法以共同祖先为基准，比较两个分支的变更。当同一行内容在两个分支上都被修改时，就会产生冲突。理解这一机制有助于更有效地解决冲突。

# 三方合并原理
# 共同祖先 (Base)   分支A (Ours)     分支B (Theirs)
# line1               line1             line1
# line2               line2_MODIFIED    line2_MODIFIED  ← 冲突！
# line3               line3             line3_UNCHANGED

# 查看冲突文件
git status
# 或查看具体的冲突内容
git diff

# 冲突标记格式
# <<<<<<< HEAD
# 当前分支的内容
# =======
# 合并目标分支的内容
# >>>>>>> feature/login-page

# 使用 vimdiff 解决冲突
git mergetool --tool=vimdiff

# 使用 VSCode 解决冲突
git mergetool --tool=vscode

# 使用 nvimdiff
git mergetool --tool=nvimdiff

# 手动解决冲突的步骤
# 1. 编辑冲突文件，保留正确的代码
# 2. 删除冲突标记（<<<<<<<, =======, >>>>>>>）
# 3. 标记为已解决
git add resolved-file.js
# 4. 继续合并
git merge --continue
# 或
git commit

5.4 Claude Code 冲突解决提示

Claude Code可以读取冲突内容并帮助分析如何解决冲突。以下是一些实用的提示模板。

# Claude Code 冲突解决提示模板

# 提示 1：分析冲突
"请分析以下 Git 合并冲突，给出解决建议：
<<<<<<< HEAD
function calculateTotal(items) {
    return items.reduce((sum, item) => sum + item.price, 0);
}
=======
function calculateTotal(items, discount = 0) {
    const subtotal = items.reduce((sum, item) => sum + item.price, 0);
    return subtotal * (1 - discount);
}
>>>>>>> feature/add-discount
"

# 提示 2：自动合并策略建议
"当前分支 feature/payment-v2 与 main 有冲突，
冲突文件为 src/payment/checkout.ts。
请分析两个版本的差异并推荐合并策略。"

# 提示 3：批量冲突处理
"项目中 src/utils/ 目录下有多个文件存在合并冲突，
请读取冲突内容并逐一给出解决建议。"

# 在 CLAUDE.md 中配置冲突解决规则
#
# ## 冲突解决原则
# 1. 优先保留双方功能而非二选一
# 2. 删除冲突标记后必须验证代码可编译
# 3. 解决冲突后运行相关测试用例
# 4. 有疑问时在 PR 评论中标注并请求复审

最佳实践：解决冲突后，建议运行完整的测试套件以确保代码功能正常。可以使用 git diff --check 检查是否残留了冲突标记。

六、Git Hooks 集成

Git Hooks是在Git操作的关键节点上触发的脚本，可以在提交前运行lint检查、在推送前运行测试、在提交信息录入后验证格式等。结合Claude Code，可以实现更智能的钩子逻辑。

6.1 pre-commit 钩子

pre-commit钩子在用户执行git commit时触发，常用于代码格式检查、lint检查和敏感信息检测。推荐使用pre-commit框架管理钩子。

# 使用 pre-commit 框架管理 Git Hooks

# 安装 pre-commit
pip install pre-commit

# 创建 .pre-commit-config.yaml
cat > .pre-commit-config.yaml << 'EOF'
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files
        args: ['--maxkb=500']
      - id: detect-private-key

  - repo: https://github.com/commitizen-tools/commitizen
    rev: v3.12.0
    hooks:
      - id: commitizen
        stages: [commit-msg]

  - repo: https://github.com/golangci/golangci-lint
    rev: v1.55.0
    hooks:
      - id: golangci-lint

  - repo: local
    hooks:
      - id: claude-code-review
        name: Claude Code Review
        entry: claude review --diff
        language: system
        stages: [pre-commit]
        verbose: true
EOF

# 安装钩子
pre-commit install

# 安装 commit-msg 钩子（用于验证提交信息）
pre-commit install --hook-type commit-msg

# 手动运行所有钩子
pre-commit run --all-files

# 手动运行指定钩子
pre-commit run trailing-whitespace --all-files

# 跳过钩子（紧急情况用，不推荐）
git commit --no-verify -m "fix: critical hotfix"

6.2 pre-push 钩子

pre-push钩子在执行git push时触发，适合运行完整的测试套件、代码构建和安全性检查。相比pre-commit，pre-push可以运行更耗时但更全面的检查。

# .git/hooks/pre-push 示例

#!/bin/bash
# pre-push 钩子: 推送前自动运行测试

echo "=== Running pre-push checks ==="

# 运行单元测试
echo "Running unit tests..."
npm test
if [ $? -ne 0 ]; then
    echo "❌ 单元测试失败，推送已中止"
    exit 1
fi

# 运行集成测试
echo "Running integration tests..."
npm run test:integration
if [ $? -ne 0 ]; then
    echo "❌ 集成测试失败，推送已中止"
    exit 1
fi

# 代码构建验证
echo "Building project..."
npm run build
if [ $? -ne 0 ]; then
    echo "❌ 构建失败，推送已中止"
    exit 1
fi

# 检查是否有敏感信息泄露
echo "Scanning for secrets..."
if git diff --cached --name-only | xargs grep -l "AKIA\|password\|secret" 2>/dev/null; then
    echo "⚠️  检测到可能的敏感信息！"
    exit 1
fi

echo "✅ 所有检查通过，正在推送..."
exit 0

# 保存为钩子文件
# chmod +x .git/hooks/pre-push

6.3 commit-msg 钩子

commit-msg钩子在提交信息编辑完成后触发，用于验证提交信息是否符合Conventional Commits规范。

# .git/hooks/commit-msg 示例
# 验证提交信息是否符合 Conventional Commits 规范

#!/bin/bash

COMMIT_MSG_FILE=$1
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

# 正则验证：(): 
PATTERN="^(feat|fix|docs|style|refactor|perf|test|chore|ci|build|revert)(\(.+\))?!?: .+$"

if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
    echo ""
    echo "❌ 提交信息不符合 Conventional Commits 规范！"
    echo "格式: (): "
    echo "示例: feat(auth): add user login page"
    echo "      fix(api): handle null response"
    echo "      docs: update installation guide"
    echo ""
    echo "类型: feat | fix | docs | style | refactor | perf | test | chore"
    echo ""
    exit 1
fi

# 检查 subject 长度
SUBJECT=$(echo "$COMMIT_MSG" | head -n 1)
SUBJECT_LEN=${#SUBJECT}
if [ "$SUBJECT_LEN" -gt 72 ]; then
    echo "⚠️  subject 超过 72 字符（当前 ${SUBJECT_LEN} 字符）"
    echo "建议精简描述内容"
    exit 1
fi

echo "✅ 提交信息格式验证通过"
exit 0

6.4 CLAUDE.md 中 Git Hooks 配置

将Git Hooks的规则写入CLAUDE.md中，可以让Claude Code在每次会话中自动遵循这些规则，实现AI辅助的Git操作。

# CLAUDE.md 中的 Git Hooks 配置示例

## Git 操作规则

### 提交规范
- 所有提交必须符合 Conventional Commits 规范
- 提交信息格式：(): 
- 请使用中文编写 subject 和 body
- type 可选值：feat, fix, docs, style, refactor, perf, test, chore

### 分支命名
- 格式：/
- 类型前缀：feature/, bugfix/, hotfix/, release/, chore/, docs/
- 使用 kebab-case 命名

### 合并策略
- 特性分支使用 Squash Merge 到 main
- 修复分支使用普通 Merge
- 合并前确保分支已 rebase 到最新的 main

### 钩子脚本
- pre-commit: 运行 lint 检查和格式化
- pre-push: 运行测试套件（单元测试 + 集成测试）
- commit-msg: 验证提交格式

### Claude Code 自动化
- 生成 git commit 时自动遵循 Conventional Commits
- 创建分支时自动使用规范命名格式
- 合并前检查冲突并给出建议
- 推送前验证测试是否通过

Git Hooks 最佳实践总结：pre-commit适合运行快速检查（lint、格式），pre-push适合运行完整检查（测试、构建），commit-msg专注于提交信息验证。将关键规则写入CLAUDE.md，实现Claude Code与Git Hooks的协同工作。

七、CLAUDE.md 中 Git 规则配置

CLAUDE.md是Claude Code项目中的核心配置文件，它定义了Claude在项目中的行为规则。在CLAUDE.md中配置Git相关规则，可以让Claude Code在每次会话中自动遵循团队的Git工作流规范。

7.1 常用 Git 规则配置

以下是一个完整的CLAUDE.md Git规则配置示例，涵盖提交规范、分支命名、冲突解决和钩子集成。

# CLAUDE.md Git 规则完整配置示例

# ============================================
# Git 工作流规范
# ============================================

## 工作流模式
- 使用 GitHub Flow（main + 特性分支）
- 特性分支生命周期不超过1天
- PR 大小不超过 200 行变更

## 分支命名规范
- feature/<功能名称>     # 新功能
- bugfix/<问题描述>       # Bug修复
- hotfix/<紧急修复描述>   # 线上紧急修复
- release/<版本号>        # 版本发布
- chore/<维护任务>        # 杂项维护

## 提交规范（Conventional Commits）
- 格式：(): 
- 类型：feat, fix, docs, style, refactor, perf, test, chore, ci
- subject：中文描述，不超过72字符
- 关联 Issue：使用 Closes/Fixes/Refs 关键字

## 合并策略
- 特性分支 → main：Squash Merge
- 修复分支 → main：普通 Merge（保留提交历史）
- 合并前必须 rebase 到最新的 main

## 冲突解决原则
1. 优先保留双方功能逻辑
2. 解决冲突后必须运行测试
3. 删除所有冲突标记

## Git Hooks
- pre-commit：运行 eslint 和 prettier
- pre-push：运行完整测试套件
- commit-msg：验证 Conventional Commits 格式

## Claude Code 自动化指令


当用户请求执行任何 Git 操作时，自动遵循以下规范：

1. **创建分支**：自动使用规范命名格式
   用户说"创建分支实现登录功能"
   → git checkout -b feature/user-login

2. **提交代码**：自动生成 Conventional Commits 格式的提交信息
   用户说"提交代码"
   → 分析变更内容，生成格式化的提交信息

3. **合并分支**：先检查冲突，再按策略合并
   用户说"合并 feature/user-login 到 main"
   → 先 rebase，再 squash merge

4. **清理分支**：检查已合并的分支并清理
   用户说"清理分支"
   → 删除已合并的本地和远程分支

5. **解决冲突**：分析冲突内容并给出解决建议
   用户说"有冲突"
   → 读取冲突文件，分析差异，推荐解决方案

7.2 高级配置：自定义 Git 命令

可以通过CLAUDE.md定义自定义的Git命令，让Claude Code执行复杂的多步骤Git操作。

# CLAUDE.md 高级 Git 配置示例

## 自定义 Git 命令（通过 Claude Code 执行）


运行步骤：
git checkout main
git pull
git checkout {branch_name}
git rebase main
如果出现冲突，读取冲突文件并协助解决
git checkout main
git merge --squash {branch_name}
git commit -m "feat: {description}"
git push
git branch -d {branch_name}
git push origin --delete {branch_name}



运行步骤：
git checkout main
git pull
git checkout -b hotfix/{description}
提示用户修改代码
修改完成后执行：git add . && git commit -m "fix: {description}"
git push -u origin hotfix/{description}
创建 PR 到 main
合并 PR
打标签：git tag v{version} && git push --tags



运行步骤：
git log --oneline --no-merges --format="%s" HEAD~{count}..HEAD
分类 feat/fix/docs/refactor/perf
按 Conventional Commits 格式生成 CHANGELOG 内容
输出结构化的 changelog 文本

实践建议：CLAUDE.md中的Git规则应当与团队的实际工作流保持一致，并定期更新。规则不宜过于复杂，否则会增加学习成本和执行难度。建议从核心规则开始，逐步完善。

八、实际工作流全景示例

以下是一个完整的实际开发工作流示例，展示从创建分支到合并交付的全过程，将前面介绍的所有概念融会贯通。

# 完整的 Git + Claude Code 工作流示例

# === 场景：实现用户资料编辑功能 ===

# Step 1: Claude Code 自动创建规范命名的分支
# 用户输入："开始开发用户资料编辑功能"
# Claude Code 执行：
git checkout main
git pull
git checkout -b feature/user-profile-edit

# Step 2: 功能开发，Claude Code 协助编码
# 用户输入："帮我实现用户资料编辑的API接口"
# Claude Code 生成代码并协作完成

# Step 3: 使用 Conventional Commits 提交
# 用户输入："提交代码"
# Claude Code 自动分析变更并生成规范提交信息
git add .
git commit -m "feat(profile): add user profile editing API

实现用户资料编辑的 RESTful API，包括：
- GET /api/v2/profile 获取用户资料
- PUT /api/v2/profile 更新用户资料
- 支持头像上传到 OSS

Closes #234"

# Step 4: 提交后发现需要修复
# 用户输入："修正拼写错误"
git add .
git commit -m "fix(profile): correct field name spelling

将 'avator' 修正为 'avatar'"

# Step 5: 准备合并，先 rebase 到最新 main
git fetch origin
git rebase origin/main
# 如果没有冲突则继续，有冲突则 Claude Code 协助解决

# Step 6: Squash 合并到 main
git checkout main
git merge --squash feature/user-profile-edit
git commit -m "feat(profile): add user profile editing API

实现用户资料编辑功能，包括获取资料、更新资料和头像上传。

Closes #234"

# Step 7: 推送并删除特性分支
git push
git branch -d feature/user-profile-edit
git push origin --delete feature/user-profile-edit

# Step 8: 打标签（如果是重要版本）
git tag -a v1.3.0 -m "v1.3.0: add user profile editing"
git push --tags

效率提升：使用Claude Code配合上述Git工作流，可以将分支创建、提交信息生成、冲突解决等操作的时间缩短50%以上。开发者可以将更多精力集中在代码逻辑本身，而非Git操作的细节上。

九、核心要点总结

工作流模式选择：Git Flow适合复杂项目，GitHub Flow适合快速迭代，GitLab Flow适合多环境部署，主干开发适合精英团队。根据团队实际情况选择最适合的模式。
分支命名规范：统一格式 <类型>/<描述>，自动化清理陈旧分支，保护重要分支不被误操作。
Conventional Commits：结构化提交信息格式，配合Commitizen工具实现交互式提交，自动生成changelog和版本号。
Squash合并：保持main分支历史整洁，特性分支的中间提交在合并时压缩为一条有意义的提交信息。
Git Hooks：pre-commit运行快速检查，pre-push运行完整测试，commit-msg验证提交格式，三层防护确保代码质量。
CLAUDE.md配置：将Git规则写入CLAUDE.md，让Claude Code自动遵循团队规范，实现AI辅助的标准化Git操作。
冲突解决：频繁rebase到main减少冲突规模，使用rerere复用解决方案，借助Claude Code分析冲突内容。

十、进一步思考

Git工作流不是一成不变的，它应该随着团队和项目的成长而演进。一个小型创业团队可能从GitHub Flow开始，随着团队扩大到50人以上，可能需要引入更严格的分支策略和代码审查流程。

演进建议：

1-5人团队：Trunk-Based Development 或简化版GitHub Flow，强调快速迭代
5-20人团队：标准GitHub Flow，引入PR Review和Squash Merge
20-50人团队：GitLab Flow或Git Flow，增加环境分支和版本管理
50人以上：Git Flow，严格的分支保护、自动化测试和发布流程

Claude Code在Git工作流中的角色也在不断进化。从简单的辅助提交信息生成，到自动化的分支管理和冲突解决，再到完整的CI/CD流水线集成，AI正在重新定义开发者的Git操作体验。未来的Git工作流将更加智能化和自动化，开发者可以更专注于创造性的编码工作。

"最好的Git工作流是让开发者感觉不到它存在的工作流。当规范变成习惯，当自动化覆盖了所有重复性操作，团队才能真正专注于交付价值。"