企业官网建设流程全解析

我见过太多人把 Git 当“存档/读档”工具用：写一段代码，git add .，git commit -m "update"，需要回退就git reset --hard。表面上看确实能跑通，可一旦遇到“为什么这个文件没提交进去”“为什么 status 同时显示两处修改”“为什么我 reset 以后工作区也不见了”这类问题，就完全抓瞎。问题的根源基本都指向同一个地方：对 Git 的三个分区——工作区、暂存区、本地仓库——缺乏直观理解。

这篇文章是我这些年带新人、自己也踩过坑之后的总结。我会先把三区的关系讲透，再围绕状态查看、add、commit、diff、reset 这五组命令分别拆解，最后用一个完整的开发场景把所有命令串起来，顺带分享一些日常工作中真正好用的习惯。无论你是刚接触 Git 的新手，还是已经用了一两年却偶尔被怪问题卡住的开发者，应该都会有收获。

1. 三个分区的底层逻辑：到底是谁在记录你的代码变化

很多人以为 Git 只有一个“仓库”，其实在你本地随便初始化一个项目，就已经存在三个逻辑区域：工作区、暂存区、本地仓库。搞清楚每一个区“存了什么”“谁在写它”，后面所有命令就都有了坐标。

1.1 工作区：你肉眼可见的文件夹

工作区就是你现在正在敲代码的那个目录。你在编辑器里改了文件、新建了文件、删了文件，这些操作全部发生在工作区。Git 能感知到这些变化，但不会主动保存任何版本记录——它只在需要的时候问你“要不要把现在的状态记下来”。

有一个细节值得注意：工作区的变化是不受 Git 管理的，只有当你执行命令，让 Git 把某个文件的内容“登记”进去，Git 才会针对这个状态建立记录。很多人一开始误以为“我保存了代码，Git 就自动备份了”，不是的，保存只是写进了文件系统，Git 并没有因此产生任何提交。

1.2 暂存区：下一次提交的候选清单

暂存区（Staging Area / Index）是 Git 里最容易让人迷惑的概念，因为它在文件系统里不是一个常规意义上的文件夹，而是.git目录下名为index的一个二进制文件。你可以把它理解为一个“待提交清单”：里面记录着“下一次 commit 时要带上哪些文件、这些文件的内容快照是什么”。

当你执行git add，Git 会把工作区里对应文件的当前内容打包成一个对象，然后把“路径 → 对象”的关联写进index。注意关键词是“当前内容快照”——它只记录你 add 那一刻文件的样子。之后哪怕你再修改文件，只要没有重新 add，暂存区里的快照依然是旧的。

1.3 本地仓库：真正的历史档案室

本地仓库，也就是.git目录里那些 objects、refs 等数据结构，保存的是每一次提交形成的历史快照。当你执行git commit，Git 会把暂存区里的所有内容打包成一个 commit 对象，挂到当前分支上，形成一个不可变的历史节点。

很多人以为 Git 保存的是“差异”，其实 Git 保存的是完整快照。每次提交，被跟踪文件的完整内容都会以对象形式存进.git/objects，只是相同的文件内容会被复用，不会重复占用空间。这也是为什么 Git 回滚历史版本速度极快——它不需要做增量计算，直接取对象出来即可。

1.4 为什么非要加一个暂存区？

这是初学者问得最多的问题：“既然 commit 能保存，为什么不直接提交？”答案在于暂存区给了你一次“整理”的机会。

首先，你可以把一次大的改动拆成多个逻辑独立的提交：改了两个需求的代码，先 add 与需求 A 相关的文件，提交一次；再 add 与需求 B 相关的文件，提交第二次。历史记录因此干干净净，后续要回滚其中一个需求也不至于牵连另一个。其次，暂存区允许你提交前再做一次复核，git diff --cached专门用来查看“即将提交的内容”，这一步能拦住大量低级错误。最后，它也给了你精细控制的空间，比如git add -p可以只挑选文件里的某些代码块进入暂存区，这在改动特别杂乱时非常有用。

三区之间的关系可以简单类比成厨房流程：工作区是你炒菜的操作台，所有切配、烹饪都在这里发生；暂存区是备菜盘，你决定哪些食材可以下锅；本地仓库是已经做好的成品菜，每做一道就拍个照存在档案册里。理解了这条流动链路，下面所有的命令都是围绕“如何让内容在这三个区之间流动”来展开的。

2. git status 实战：一眼看懂三个区的当前状态

在所有 Git 命令里，git status是我使用频率最高的一条，没有之一。它的核心价值是告诉你“当前三个区各处于什么状态”，尤其是“有哪些改动还没被 Git 记录”。

2.1 三种最核心的状态输出

新仓库里只要还没提交过，你大概率会看到三类提示：

• Untracked files：工作区里有 Git 从来没跟踪过的新文件。它存在，但 Git 对它一无所知，必须 add 一次之后才进入版本管理。
• Changes not staged for commit：某个已经被 Git 跟踪的文件，你在工作区里做了修改，但这个修改还没有进入暂存区。
• Changes to be committed：已经 add 过的内容，它躺在暂存区里，等待下一次 commit 写入仓库。

很多新手分不清第二和第三类的区别。简单说，第二类代表“你改了，但 Git 还没准备记录”，第三类代表“你改了，而且已经明确告诉 Git 把这次改动列为候选提交项”。

2.2 add 之后又改文件，会出现两个状态同时存在

这是最容易引发困惑的场景：你执行了git add demo.txt，status 里显示Changes to be committed。然后你又继续编辑这个文件，再跑一次 status，就会出现两行相关提示——暂存区里是 add 时的旧快照，工作区里是修改后的新内容。换句话说，同一个文件既“待提交”又“未暂存”。

用git status -s可以查看紧凑格式，两列状态码分别代表“暂存区列”和“工作区列”。这个输出习惯一旦养成，扫一眼就能定位问题。

2.3 让 status 更好用的配置

我强烈建议给 status 配置一个别名，如果你日常用命令行比较多，这个习惯每天能省不少事：

git config --global alias.st "status --short --branch"

之后敲git st，输出变成一行行紧凑状态，同时显示当前分支和与上游的领先/落后关系。我个人几乎所有的日常操作里，第一步都是git st——动手前看一次，add 后看一次，commit 前再看一次。你会发现这比任何“防止误操作”的第三方工具都可靠。

3. git add 细节拆解：从工作区到暂存区最容易踩的坑

add 是把工作区内容送进暂存区的唯一入口，但很多人在这一步埋下隐患。最典型的就是无脑git add .，把所有文件一股脑塞进暂存区。

3.1 add 的常用姿势和适用范围

git add <文件名>精确添加某个文件；git add src/添加目录下所有改动；git add .添加当前目录下所有改动（包括未跟踪的新文件）；git add *.js添加符合通配符的文件。

这里要特别提醒：git add .是无差别添加，如果你没配好.gitignore，很容易把临时文件、编译产物、IDE 配置甚至带有敏感信息的文件一起打包进暂存区。我见过某同事把target/目录加进去然后 commit，导致几百个编译产物进入历史记录，后续清理费了很大功夫。更稳妥的做法是：能用文件名就用文件名，能按目录就按目录，实在要用git add .，操作前一定先跑一次git status，确认列表里没有不该进的东西。

3.2 add 保存的是快照，不是引用

再强调一遍：git add缓存的是“那一刻文件的内容快照”，而不是对文件的引用。这个特性可以用一个最小实验说清楚：

echo "第一版" > demo.txt git add demo.txt git status # 显示 Changes to be committed: new file: demo.txt echo "第二版" >> demo.txt git status # 同时显示 Changes to be committed 和 Changes not staged for commit git commit -m "add demo" git show HEAD:demo.txt # 输出只有"第一版"

如果你 commit 这个文件，仓库里保存的是“第一版”，而不是你最后看到的“第一版换行第二版”。很多“我明明提交了为什么代码没更新”的问题，根源就在这里。

3.3 git add -p：只挑一部分改动进入暂存区

当你一个文件里混了两块互不相关的改动，git add -p会逐块询问是否要暂存。这个交互式命令很适合保持提交的原子性：把属于需求 A 的代码块 add 进去，提交一次；再把属于需求 B 的代码块 add 进去，提交另一次。虽然也可以在 IDE 的 Git 面板里手动勾选代码块实现，但命令行下的add -p不受图形界面限制，在服务器环境也一样能用。

3.4 取消暂存：add 错了怎么办

如果 add 错了文件，不要慌，改动并不会丢失。直接：

git reset <file> # 把文件移出暂存区，工作区改动保留 git restore --staged <file> # 新版命令，效果相同

早期文档里常写git reset HEAD <file>，但现在 Git 已经支持省略 HEAD，直接写git reset <file>就够了。这类操作最权威的提示其实藏在 status 输出里——当你处于已暂存状态时，Git 自己会提示你下一步可以用什么命令，善用这个提示。

3.5 误把生成目录提交了，怎么补救

如果已经 commit 了，处理思路是先“移除跟踪”，再提交这次移除：

git rm --cached -r target/ echo "target/" >> .gitignore git commit -m "chore: remove build artifacts from tracking"

--cached参数保证磁盘上的target/目录仍然保留，只是不再被 Git 跟踪。补上.gitignore之后，以后不会再误加。这一步做完，你的历史记录里旧版本仍然含编译产物，但新提交开始就干净了——如果这是刚提交还没 push 的情况，也可以选择用git reset回退重来，是否要重写历史需要自己权衡。

4. git commit 正确姿势：从暂存区到本地仓库，让历史记录干净可用

commit 是把暂存区内容落进本地仓库的瞬间。它应该是深思熟虑的“存档动作”，而不是随手一按的“快照热键”。

4.1 commit 到底提交了什么

git commit只处理暂存区里的内容。工作区里未 add 的改动、未跟踪的新文件，它一概不闻不问。所以如果你git add了部分文件，commit 后另一部分改动依然留在工作区和暂存区之外，不会被带入这次提交。

如果暂存区是空的，Git 会提示nothing to commit, working tree clean。这个提示本身很有价值——它说明工作区、暂存区、仓库三处完全一致。

4.2 commit message 的写法确实值得讲究

很多团队的提交信息写得像聊天记录：update、fix、改一下。三个月后回看，除了知道“改过”，完全不知道改了为什么。我常用的格式是：

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

type 常见的取值有：feat（新功能）、fix（修复）、docs（文档）、style（格式调整）、refactor（重构）、test（补充测试）、chore（杂项）。subject 用祈使句，写清楚这次提交“做了什么以及为什么”，而不是只罗列文件。

• 反面示例：update login
• 正面示例：fix(login): avoid expired token being retried twice

后者让同事和未来的自己都能立刻理解变动的意图。提交信息不是写给 Git 看的，是写给人看的。

4.3 用 --amend 补救最后一次提交

提交完发现漏了一个文件，或者 message 写错了，没必要慌，更没必要再补一条“fix typo”的提交。正确做法是：

git add 遗漏文件 git commit --amend

--amend会用当前暂存区内容替换上一次提交，生成一个新的 commit 对象，旧提交被替换掉，历史里不会留一条多余的记录。注意，这只适用于还没推送到远端共享分支的情况。如果提交已经 push 出去并在团队分支上，amend 会重写历史，导致协作者拉取时发生冲突，建议不要那么干。

4.4 原子提交：一次提交只做一件事

“原子提交”是我在带新人时反复强调的习惯。每次提交的改动量，应该控制在能用一句话说清的范围内。好处是显而易见的：回滚精确、审查容易、用git bisect定位历史 bug 时误差也小。

实现原子提交的技巧就是前面提到的git add -p和精确 add：先梳理需求，再分块缓存，最后用清晰的信息逐个提交。一开始会觉得麻烦，养成习惯后你会发现自己搜索历史时的效率高非常多。

4.5 git commit -a 的陷阱

git commit -a会先把所有“已跟踪文件”的修改自动加入暂存区再提交，省掉了手动 add 一步。但它有两个坑：一是对未跟踪的新文件完全无效，二是会把所有已跟踪文件的改动一股脑带入提交，容易把不相关的修改混在一起。我很少使用它。如果你喜欢高效，推荐先git add明确范围，再git commit，不要贪图这半秒钟。

5. git diff 三种视角：提交前到底应该看哪一份差异

diff 的核心价值是在提交前让你看清“将要提交的到底是什么”。很多低级错误（误提交配置文件、临时开关、调试代码）都是可以靠 diff 拦住的。

5.1 三条命令对应三种比较范围

需要特别注意git diff和git diff --cached的区别。前者显示的是“还没 add 的改动”，后者显示的是“已经 add、等待 commit 的改动”。如果两者同时存在，它们各看各的，不会互相包含。把两条命令都跑一遍，才能拼出工作区的完整改动全貌。

5.2 常用参数组合

• git diff --stat：只看改动了哪些文件、增删了多少行，不展开具体内容。适合快速浏览改动范围。
• git diff --name-only：只显示文件名列表，适合确认“是不是只有预期中的文件被改动”。
• git diff -w：忽略所有空白字符差异。有时候编辑器自动换行符或缩进调整会制造大量噪音，这个参数能把真实改动暴露出来。
• git diff --check：检查是否存在结尾空白或冲突标记，可以作为提交前的卫生检查项。

5.3 我的提交流程中 diff 被用在哪个节点

我个人的标准流程是：写完代码先git diff自己审一遍；确认改动合理后git add；commit 前再跑git diff --cached复核暂存区内容。第二道复核最重要的任务是排除误入的配置文件和敏感信息文件——尤其是带密钥、连接串之类的文件，一旦进历史就很麻烦。push 之前，我还会看一次git log --oneline --stat确认这段提交的总体规模是否符合预期。

5.4 和指定分支对比改动

在准备合并或做 code review 时，常用三点语法比较两个分支：

git diff main...feature/login

三个点表示以 main 和 feature/login 的共同祖先为基准，只显示 feature 分支上相对主分支多出来的改动。这样不会把 main 上已经独有的改动也混进来。这个技巧在合并请求场景里几乎是每天都要用到的。

6. git reset 撤销体系：把一个错误提交拉回来的完整方案

撤销操作是 Git 里风险最高也最需要讲清楚的部分。很多人一遇到问题就git reset --hard，结果把辛辛苦苦写的代码直接抹掉，真要命。

6.1 reset 的三个级别：soft / mixed / hard

git reset的核心是“把 HEAD 指针移回某个提交”，同时可选地影响暂存区和工作区。三个级别区别如下：

用例子说明：你刚提交了一次包含三个文件改动的 commit，但突然觉得应该拆成两个提交。这时git reset --soft HEAD~1，三个文件的改动会回到暂存区里，git status会提示你有待提交的改动，你可以重新 add、重新提交。整个过程不丢任何代码。

如果你提交后又改了工作区文件，想放弃上一次提交的错误内容但保留之后的工作区修改，那就用git reset --mixed HEAD~1。默认情况下，它会让暂存区回到目标提交的状态，但工作区改动原封不动，出现的是“Changes not staged for commit”，重新 add 即可。

而--hard是真正的“核按钮”。它会把 HEAD、暂存区、工作区三处全部重置到目标提交的状态，所有未提交的改动即刻消失，而且没有回收站可翻。任何情况下执行它之前，我都建议先考虑一句：

git stash push -m "backup before hard reset"

先把当前工作区改动临时存起来，之后再不想用了直接丢弃 stash，想用还能随时弹回来。

6.2 具体撤销场景的应对方案

• 提交信息写错了：git commit --amend直接改，不要 reset。
• 提交后漏了文件：git add 遗漏文件 && git commit --amend。
• 提交后想拆成多次提交：git reset --soft HEAD~1，再逐步 add、commit。
• 提交后想重来并且保留内容：git reset --mixed HEAD~1。
• 彻底放弃这一次提交且丢弃工作区改动：先git stash push，再git reset --hard HEAD~1。或者确认备份后直接 hard。

注意HEAD~1表示当前提交的父提交，也就是“上一个版本”。数量可以往上加，比如HEAD~3回退三个提交。如果想回退到任意一次提交，用git log找到那个 commit 的哈希值，替换HEAD~n即可。

6.3 checkout / restore 与 reset 的分工

git reset主要作用于提交级别，而“想撤销单个文件的修改”要用另一组命令：

• git checkout -- <file>：把工作区某个文件恢复成暂存区或 HEAD 里的状态，丢弃工作区未提交修改。新版推荐写git restore <file>。
• git restore --staged <file>：把文件从暂存区取消（撤销 add），工作区改动保留。
• git restore <file>：默认丢弃工作区改动，效果等同于git checkout -- <file>。

这里特别提一件我遇到过的真实案例：某同事想放弃某个文件的修改，执行了git restore --staged <file>，以为工作区也还原了，结果文件依然处于修改状态。他又顺手执行git checkout .，把另一个文件的未提交改动一起抹掉了。问题就出在没分清“取消暂存”和“还原工作区”是两件不同的事。所以动手前，永远先用git status看清当前处于哪个区，再选命令。

7. 完整工作流串联：用一次真实的登录功能提交走完全部命令

到这里，三区逻辑和核心命令都讲完了。最后用一个日常开发场景，把整个流程串一遍，你可以当脚本一样跟着跑。

7.1 场景设定

模拟项目 X 需要新增一个登录接口。代码已经写在本地，分支还没建。目标是：基于主分支切一个功能分支，添加两个文件，再提交成一条干净的记录。

7.2 从开工到提交的完整命令序列

# 1. 开工前先看状态：当前分支、有没有遗留改动 git status -sb # 2. 基于 main 创建并切换功能分支 git checkout -b feature/login # 3. 写代码：改 LoginController.java，新增 LoginService.java # 4. 快速看下这次改动的范围 git diff --stat # 5. 只添加与登录需求相关的文件，不放杂项 git add src/controller/LoginController.java src/service/LoginService.java # 6. commit 前检查即将提交的内容 git diff --cached --stat git diff --cached # 7. 提交 git commit -m "feat(login): add login api with token validation" # 8. 检查历史记录 git log --oneline --graph --decorate -5 # 9. 如果发现漏了一个文件 git add src/util/TokenUtil.java git commit --amend

7.3 每个步骤背后，三区到底发生了什么

第 2 步执行后，HEAD 从 main 分支指针移向新创建的 feature/login 分支，但工作区和暂存区没有变化。第 5 步 add 后，两个文件的内容快照进入暂存区。第 6 步的git diff --cached展示了这些快照和当前 HEAD 的差异，也就是“本次提交将新增的内容”。第 7 步 commit 后，快照被打包进仓库，暂存区清空，HEAD 前移。此时工作区应该是干净的——git status 不会显示任何待提交或未跟踪文件。

如果你在第 4 步就发现改动的文件比预期多，说明可能有无关文件混进来了。先git status看清楚，再决定是继续还是撤销，不要硬着头皮提交。

7.4 小步提交的日常习惯

最后分享几个我多年实战里沉淀下来的习惯：

第一，一次提交的改动量要控制在“一句话能说清”的范围。说不清就拆。第二，提交前跑一次git diff --check，把结尾空白和冲突标记这种细碎问题挡在门外。第三，如果事情做到一半但临时要切换分支，用git stash push -m "wip: ..."保存进度，而不是git commit -m "wip"制造垃圾提交。第四，每次 commit 之后立刻git status -sb看一眼，确认工作区干净，这个动作两秒钟，能避免很多“我以为提交了其实没有”的尴尬。

带过几个新人之后，我最大的感受是：Git 命令其实不多，难的是理解数据在三个区之间如何流动。如果你能自己在脑子里顺畅地复述一遍“改代码是进入工作区，add 是让当前内容快照进入暂存区，commit 是把暂存区快照写入仓库历史，reset 是根据级别决定哪几个区回退”，那绝大多数 Git 困惑你都能自己推导出答案。这比记住任何命令列表都管用。