企业官网建设流程全解析

如果你最近在用 Claude Code 写代码，估计你也有这种体验：它确实能帮你把活干完，但也真的让人提心吊胆——一句话下去，它可能一口气改掉十几个文件，你还没来得及反应，代码已经变了样。要是不小心把方向带歪了，想回到几分钟前的状态都难。解决办法说穿了就是一套东西：把 Git 纪律植入到和 Claude Code 协作的每一个环节。这篇我会从环境安装讲起，一直聊到团队协作和踩坑排查，把“Claude Code + Git”这套组合的完整玩法给你捋一遍。内容覆盖 git 安装与配置、Claude Code 安装、/checkpoint 与 git diff 的配合、git commit --amend 的真实用法，以及我在实际项目里见到最多的几个问题。不管你是刚把 Claude Code 装好的新手，还是已经用了一阵但总觉得版本控制一团乱的老手，这篇都值得你花十分钟看完。

1. 为什么 Claude Code 必须和 Git 绑在一起

1.1 编程代理的自主性，恰恰是失控的源头

先说清楚 Claude Code 是个什么东西。它和传统“聊天式补代码”的工具不一样，它是一个真正能动手的编程代理：读懂你的项目结构，修改源码，执行测试命令，甚至直接操作终端。这种自主性省心是真省心，但风险也被放大了。普通 AI 补全最多给你一段代码，你不满意删掉就行；Claude Code 不一样，它为了完成一个“重构订单模块”的需求，可能会动到接口定义、数据库查询、前端组件、测试用例，一改就是几十个文件。

这时候如果没有 Git，你面对的就是一地鸡毛：改乱了无法还原，改到一半想换个方案又舍不得之前的进度，AI 自己也无法准确告诉你“我到底改了什么”。我见过不少同事，第一次用 Claude Code 做大重构，改完运行报错，想回退却发现改动的文件太多，根本不知道从哪个文件开始收拾。这不是工具的问题，而是缺了一条最基本的底线。

Git 在这套协作里的角色，可以类比成“请了个手脚麻利但偶尔犯迷糊的实习生”。实习生干活快是好事，但你绝不能让他不经过审核就动生产代码，更不能让他改完东西连个记录都不留。你得给他一条工作边界，让他每一步都留下痕迹，改坏了可以随时还原。这就是版本控制对 AI 编程代理的意义：它给了 AI 足够的自由度，同时给了你兜底的安全网。

1.2 Checkpoint 机制：给每次改动拍照存档

Claude Code 自带了 Git 集成，最核心的机制就是自动提交和 Checkpoint。简单说，它在执行任务的过程中，会在关键节点自动创建一个 Git 提交，相当于给项目拍了一张快照。后面代码改崩了，你可以随时回到这个快照继续干活，而不是从头再来。

这里要理解一点：Checkpoint 不是给你提交历史充数的装饰品，它的定位是“临时存档”。你在打一个很难的游戏关卡，每过一个小阶段就存档一次，死了就回档重来，不用从第一关重新打。Claude Code 的 Checkpoint 解决的就是同样的问题，尤其是在 AI 自主执行多步操作时，它能让你放心地让 AI 试错，而不是每一步都盯着。

但我得提醒一句：Checkpoint 和正式提交是两个概念。Checkpoint 是 AI 在工作过程中的自动存档，信息可能很粗糙；正式提交是你确认代码没问题之后，亲手写下的“这一段完成了什么”。把 Checkpoint 当正式提交用，历史会变得非常混乱；完全不依赖 Checkpoint，又会失去快速回退的能力。最佳姿势是：让 AI 自己用 Checkpoint 兜底，你用人眼审查后做正式提交。

1.3 两套心智模型，决定你是“敢用”还是“怕用”

我自己用下来，觉得和 Claude Code 协作版本控制，本质上只有两种心智模式。

第一种是“私人沙盒”模式：每次接到新需求，开一个新分支，让 Claude Code 在这个分支上随便折腾。改好了，你审查、测试、合并回主干；改砸了，直接丢弃分支，当无事发生。这个模式适合需求边界清楚、改动范围较大的场景，比如新功能开发、模块重构。

第二种是“只读护栏”模式：让 Claude Code 只在当前工作区改代码，但提交决策始终由你掌握。AI 每次改完，你通过 git diff 仔细审查，确认无误后再手动 commit。这个模式适合改动敏感、影响面大的场景，比如线上 bug 修复、核心算法调整。

两种模式不冲突，实际项目里经常切换使用。关键是你要时刻清楚自己处在哪种模式下，这决定了你对 AI 改动的信任程度和审查力度。接下来就要把环境准备好，让这套方法论真正跑起来。

2. 环境准备：装好 Git 和 Claude Code

2.1 Git 安装：Windows、macOS、Ubuntu 三种姿势

很多人第一步就卡在环境上。Git 装不好，后面所有工作流都是空中楼阁。我把三个主流系统的安装方式都过一遍，都是我自己实际验证过的路子。

Windows 用户直接去 Git 官网下载安装包，如果官网下载慢，可以用国内镜像站，速度和稳定性都不错。安装过程有几个选项要特别注意：在“Adjusting your PATH environment”这一步，一定要选“Git from the command line and also from 3rd-party software”，否则后续在终端里敲 git 命令会提示找不到。其他选项保持默认，一路 Next 就行。装完打开 CMD 或 PowerShell，敲git --version，能输出版本号就说明装好了。

macOS 用户最简单的方式是先用 Homebrew，brew install git一条命令搞定。不想装 Homebrew 的，也可以去官网下载 pkg 安装包，双击安装，省心。

Ubuntu 用户先更新软件源，再安装：

sudo apt update sudo apt install git -y git --version

顺带提一句，Ubuntu 的 apt 源里 Git 版本可能偏旧，但对绝大多数日常操作没有影响。真想用新版本，加 Git 官方 PPA 再装即可，这里不展开。

2.2 身份配置和 SSH 密钥：不配好，提交必踩坑

Git 装完第一件事不是急着用，而是配置身份信息。很多新手第一次让 Claude Code 自动提交时报错，十有八九都是因为这里没配：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这两行配置会写进全局配置文件，之后所有仓库的提交记录都会带上你的身份信息。邮箱建议用和 GitHub 或 Gitee 绑定的邮箱，这样提交记录能正确关联到你的账号头像。

接着是 SSH 密钥。这一步是为了让你免密拉取和推送代码。生成密钥用这条命令：

ssh-keygen -t ed25519 -C "你的邮箱"

一路回车，默认生成到~/.ssh/id_ed25519。然后用cat ~/.ssh/id_ed25519.pub查看公钥内容，把它复制到 GitHub 或 Gitee 的 SSH Keys 设置页面里。配置完可以用ssh -T git@github.com测试连通性，看到欢迎信息就说明配好了。

2.3 Claude Code 安装：CLI、桌面版、VSCode 扩展三选一

Claude Code 的安装方式主要看习惯。命令行重度用户首选 CLI 方式，前提是电脑上要有 Node.js 18 或更高版本：

npm install -g @anthropic-ai/claude-code claude --version

如果 npm 安装速度慢，可以把 registry 切到国内镜像，npm config set registry https://registry.npmmirror.com，再重新安装，速度会快很多。

不喜欢命令行的，可以用官方桌面客户端，本质上是给 CLI 套了一层图形界面，适合想看界面、不想记命令的朋友。日常写代码用 VSCode 的话，直接在扩展市场搜 Claude Code，装好扩展后就能在编辑器里打开会话面板，Git 状态显示的集成度比终端里更直观。

第一次运行claude命令，会要求登录 Anthropic 账号授权，用浏览器完成 OAuth 流程即可。如果终端输出类似Claude Code might not be available in your country. Check supported countries的提示，说明当前地区的网络出口不在官方支持的范围内。这属于官方订阅和合规层面的限制，正确的做法是查看 Anthropic 官方文档确认支持地区，或通过团队/组织的合规渠道获取授权，不建议使用任何绕过工具，账号安全和代码安全都犯不上冒险。

2.4 接入第三方模型：DeepSeek 等兼容端点的配置

很多国内开发者没有 Anthropic 官方账号，但手里有 DeepSeek 等其他模型的 API Key。好在 Claude Code 支持通过环境变量切换到兼容端点，具体配置方式如下：

export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" export ANTHROPIC_AUTH_TOKEN="你的API Key" claude --model deepseek-chat

也可以把配置写进 Claude Code 的 settings.json 文件，这样每次启动都会自动加载：

{ "env": { "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic", "ANTHROPIC_AUTH_TOKEN": "你的API Key" } }

需要提醒的是，第三方兼容端点的模型能力与官方模型并不完全一致，尤其是涉及文件编辑、工具调用这类 Agent 核心能力时，兼容性可能有差异。正式项目里建议先跑几个典型任务验证一下，确认它能正确调起 Git、改文件、跑测试，再放心用。

3. 核心实操：在 Claude Code 里跑通完整 Git 工作流

3.1 起步姿势：初始化仓库和项目说明书

环境准备好之后，第一步是建仓库。新项目直接git init，老项目git clone拉下来。初始化前记得先把.gitignore写好，node_modules、.env、构建产物这些目录必须排除掉，否则 Claude Code 的一次批量提交会把几千个依赖文件全部塞进仓库，Git 立刻卡成幻灯片。

进入交互界面后，有一个很值得用的命令：/init。它会让 Claude Code 通读一遍项目结构、技术栈、构建命令，然后在根目录生成一份CLAUDE.md文件。这份文件相当于给 AI 用的“项目操作手册”，以后每次会话它都会先读这个文件，按里面的约定来操作。

我实际用的体会是：CLAUDE.md写得越具体，AI 的产出就越贴合项目规范。比如在里面写清楚“测试统一用 pnpm test，不要用 npm test”“路由文件放在 src/router 目录下”，Claude Code 就不会乱跑命令、乱猜目录。这比每次对话都重复交代上下文要高效得多。

3.2 变更速览：用 /status 快速掌握 AI 动了什么

Claude Code 在完成一个阶段性任务后，你可以输入/status，它会调用 Git 的力量，总结当前工作区相比上一次提交具体发生了哪些变化。这个命令的价值在于：它不给你看干巴巴的git status文件列表，而是用自然语言概括“我把订单模块的查询逻辑抽出来了，删掉了已废弃的接口，新增了三个边界条件测试”。对人来说，这种总结能让你快速建立对改动的整体认知。

但要记住一个原则：AI 的总结再漂亮，也只是“它的视角”。改动特别大、涉及文件特别多的时候，它的概括可能有遗漏或者偏差。我习惯在/status之后，自己再抽查一遍关键文件的实际内容，特别是被删除的代码——有时候 AI 觉得某个函数“废弃”了，实际上还有老页面在调用它。

3.3 生成检查点：/checkpoint 的时机和边界

/checkpoint是 Claude Code 里我使用频率最高的命令之一。它的作用相当于手动创建一个还原点，内部实现就是一次 Git 提交。什么时候用？我的经验是：在让 AI 执行大重构之前，必须先打一个 checkpoint。比如“把支付模块从同步改成异步”这种动辄几十个文件的操作，做完之前先存档，改崩了直接回退，肉痛程度能小一半。

使用起来很简单，会话里输入：

/checkpoint

Claude Code 会创建一次提交并提示你当前进度已保存。后续恢复时，可以通过/checkpoint列出的历史记录选择要回退到的位置。

但这里有个容易踩的坑：Checkpoint 本质是提交在当前分支上的，如果你手动执行了git reset、git rebase这类改写历史的操作，checkpoint 可能会被清掉。所以重要节点除了打 checkpoint，我还要强调“真正要保住的东西，务必自己提交一次”，不要把鸡蛋都放在同一个篮子里。

3.4 逐行审查：git diff 是质量的最后一道闸门

在决定提交之前，必须看一眼 AI 的实际改动。这个环节绕不开传统 Git 命令，也是人和 AI 协作里最不能省的一步。

查看未暂存的改动：

git diff

查看已暂存的改动：

git diff --staged

我几乎每次都会在 VSCode 的源代码管理视图里逐文件看一遍 diff，重点盯三件事：一是有没有删掉不该删的代码，二是有没有引入未经说明的新依赖，三是有没有把密钥、路径这类敏感信息写进代码。AI 生成的代码里偶尔会出现凭空多出来的依赖包，或者把本地调试用的绝对路径写死进去，这些必须人眼筛查。

顺带解释一个很多 IDE 图形工具里见到的参数组合：

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks ...

mnemonicprefix=false让 diff 输出里的 a/ 和 b/ 前缀保持常规样式；core.quotepath=false让中文文件名正常显示而不是被转义成八进制；--no-optional-locks避免某些 Git 操作在后台上锁，影响并发性能。你在 VSCode 里看到中文文件名没乱码、diff 显示正常，背后就是这些参数在起作用。

3.5 提交落地：commit 规范和 amend 的正确用法

diff 审查通过后，就到了提交环节。我习惯让 Claude Code 先总结变更内容，我会手动执行提交命令：

git add . git commit -m "feat: 订单模块支持批量导出"

提交信息建议遵循约定式提交规范，feat 代表新功能，fix 代表修复，refactor 代表重构，chore 代表杂务。这不算什么高深技巧，但对后续回溯历史、自动生成 changelog 都帮助很大。

如果你提交完之后发现信息写错了，或者漏掉了一个小文件，这时候就用得上git commit --amend：

git add 漏掉的文件 git commit --amend

不加-m参数时，amend 会打开编辑器让你修改提交信息；想直接改信息不涉及补文件，就带上：

git commit --amend -m "feat: 完成订单导出，并修复金额精度问题"

注意，git commit --amend的本质是改写最近一次提交历史。如果这个提交已经推送到了远端，amend 之后再次推送会被拒绝，需要git push --force-with-lease。在团队公共分支上，千万别对已经推送的提交乱用 amend，否则队友拉代码时会一脸懵。

4. 高级玩法：分支策略、Hook 与团队协作

4.1 给 Claude Code 建一个专属工作分支

个人项目里直接在主分支上用 Claude Code 问题不大，但团队项目就必须有分支纪律了。我强烈建议：每一次让 Claude Code 动手干活之前，先开一个独立的分支：

git checkout -b feature/order-export

这样 Claude Code 的探索、试错、自动提交、checkpoint，全部发生在这个分支上。改好了，你审查、测试、合并；改崩了，直接丢弃分支重新开一个，干净利落。

还有一个很多人忽略的问题：同时开多个 Claude Code 会话会让 Git 状态变得非常混乱。两个会话同时改同一个文件，后提交的人很可能默默覆盖前一个人的工作。解决办法是让每个会话工作在独立分支上，最后统一人工合并。这算是我踩过几次坑之后总结出来的血泪教训。

合并回主干时，我喜欢用--no-ff保留合并记录：

git checkout main git merge --no-ff feature/order-export

这样每次合并都留下一个“合并节点”，后期看历史能清楚知道哪些功能是在哪个分支上开发出来的。

4.2 Git Hooks：用自动化拦住危险操作

AI 生成的代码质量再高，也可能踩到规范和测试的红线。Git Hooks 就是在提交和推送之前自动跑检查的机制。最常用的是 pre-commit 钩子，在提交前自动执行格式化检查、lint 检查或者单元测试。

在项目.git/hooks/pre-commit里写一个简单脚本：

#!/bin/sh npx prettier --check . npx eslint .

然后给脚本加执行权限：

chmod +x .git/hooks/pre-commit

这样每次执行git commit，都会先跑一遍格式和 lint 检查，不通过就不让提交。对于 Claude Code 这种大批量改文件的场景，钩子能有效拦住它生成的代码里风格不一致、明显的低级错误。

不过团队项目里，.git/hooks目录不会跟着仓库共享，所以更推荐用 pre-commit 框架或前端项目常用的 husky + lint-staged，把钩子配置写进仓库，所有人都能统一执行。

4.3 让 AI 帮你生成 commit message，但必须做人工校对

写提交信息是很多人的痛点，但其实 Claude Code 天然适合干这件事。你可以在会话里让它总结这次变更，并输出成符合约定式提交规范的 commit message，比如这样说：

“帮我把这次的改动总结成一条 git commit message，按约定式提交规范来，用中文。”

Claude Code 会分析 diff，生成类似fix: 修复订单金额精度计算问题这样一条信息。格式化、总结摘要这种工作，它做得比很多人手工写还要规范。

但提交信息里有个反直觉的风险点：AI 可能把不该写进去的细节也写进去。有一次它把“临时绕过接口鉴权做本地联调”这种带有安全隐患的描述写进了提交信息，如果推到公共仓库，相当于把自己的调试后门广而告之了。所以提交信息生成之后，我永远会亲自扫一眼再提交，绝不大脑放空直接复制。

4.4 用 CI/CD 把 AI 的代码挡在质量门外

本地 Hooks 能拦住一部分问题，但真正统一的质量门槛还得靠 CI。在 GitHub Actions 或 GitLab CI 上配置流水线，让每次合并请求自动跑 lint、测试、构建，任何一个环节挂了都不能合入。

一个精简的 GitHub Actions 示例：

name: ci on: [pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm run lint - run: npm test

这个流程的意义在于：Claude Code 在本地再怎么打招呼“我改好了”，都不算数。CI 里跑一遍全量测试，过了才算真的完成。我见过太多本地跑得好好的、推到 CI 就挂的情况，比如依赖版本不一致、环境变量缺失、平台相关路径问题。让 CI 做最后一道自动质检，能省掉很多“我觉得没问题”的错觉。

5. 常见问题排查：坑我都替你踩过了

5.1 自动提交太频繁，历史像流水账怎么办

Claude Code 的 checkpoint 机制加上你手动提交，很容易让提交历史变得跟流水账一样。很多人的第一反应是“这太乱了”。我的看法恰恰相反：在 AI 协作场景下，频繁提交永远比不提交好。历史乱，可以用工具整理；没有历史，出了事故只能干瞪眼。

如果提交历史确实太碎，可以用git rebase -i HEAD~n合并提交，把同一个功能的多条碎提交压缩成一条。比如要合并最近三条：

git rebase -i HEAD~3

编辑器里会列出三条提交，把后面的改成squash或s，保存退出就能合并。但这里一定要记住：rebase 会改写历史，只适合还没推送的提交。已经推到公共远端的历史，绝对不要用 rebase 去动。

5.2 误删代码、误恢复之后如何找回

这是我最想展开讲的一个场景。有一次我在 Claude Code 会话里误点了一个恢复操作，直接把一版写好的代码给回退了，当时整个人是懵的。后来靠git reflog救了回来。

git reflog会记录 HEAD 指针每一次移动的历史，包括提交、回退、硬重置。哪怕你在界面上把某个分支删了，只要提交对象还在 Git 对象库里，reflog 里就还有记录。操作流程：

git reflog

输出结果里每一行都是一个操作记录，找到你要找回的那个提交号，然后用分支或 cherry-pick 把它恢复：

git branch rescue 3f2a9b1 git checkout rescue

或者只把某一次提交的改动拿过来：

git cherry-pick 3f2a9b1

这个经验我反复对团队里的人讲：Git 里几乎没有“彻底删除”，只有“你还没找到恢复的方法”。遇到意外回退，先冷静跑git reflog，大概率有救。

5.3 git 命令报错速查表

以下是我在实际使用中遇到频率最高的几个报错，整理成速查表，值得收藏：

前三条最容易在 Claude Code 新手期遇到，本质都是环境没配好。把这些配置完，后续工作流基本就顺畅了。

5.4 Skills 技能包装不上怎么办

Claude Code 支持 Skills 机制，简单说就是把一组指令和脚本打包成“技能”，让 AI 在特定任务里调用。GitHub 上有很多开源技能包，下载之后手动安装，放的位置有两个：

• 用户级目录：~/.claude/skills/你的技能名/
• 项目级目录：.claude/skills/你的技能名/

技能包目录里一般包含SKILL.md描述文件和若干脚本。从 GitHub 下载的包，先看 README 里推荐的安装位置，通常就是上面两个路径之一。放好后重启 Claude Code 会话，然后用自然语言描述你要执行的任务，让它调用对应技能试试效果。

这里必须提醒一句：技能本质上是可执行代码，来源不明的技能包可能带着恶意脚本。安装前打开脚本读一遍，确认没有可疑操作。团队项目里，我建议把技能包提交到仓库统一管理，跟着代码评审流程走，而不是每个人私下装一堆来路不明的东西。

5.5 大仓库上下文爆炸，Claude Code 反应变慢

项目变大之后，Claude Code 可能因为上下文窗口限制而“顾头不顾尾”，改 A 模块时忘了 B 模块的依赖关系。这个问题一方面靠 CLAUDE.md 的说明来补偿，另一方面也可以在 Git 层面做文章。

对超大仓库，可以用git sparse-checkout只拉取部分目录到本地，减少无关代码对 Claude Code 上下文的干扰：

git sparse-checkout init --cone git sparse-checkout set src/server src/shared

这样本地工作区只剩你关心的目录，Claude Code 读文件时上下文更聚焦，输出质量会明显提升。代价是其他目录的文件不在本地，需要调整时再临时扩展范围。

最后说几句实在话

这套 Claude Code + Git 的组合拳我用了大半年，最大的体感变化是：从“怕 AI 把代码改坏”变成“随便改，反正能回退”。能做到这一点靠的不是某个神奇命令，而是把版本控制的意识前置到 AI 协作的每个瞬间。我个人实际使用中的体会是，最好的工作方式就是给 AI 足够的自由度，但死死守住 Git 这条底线——脏提交也比没有提交强，Checkpoint 再乱也比裸奔安全。每次让 AI 动手前，先想清楚“改崩了我怎么回来”，有了这个安全感，你才敢真正把活交给它。另外一个小技巧：提交前养成看一眼 git diff 的习惯，哪怕只花三十秒，这可能是 AI 时代代码审查性价比最高的三十秒。