企业官网建设流程全解析

先说我自己的习惯：每次写完需求准备提交，我几乎都不会用git add .这种无脑操作。因为改了一天代码，工作区里可能混着三四种东西——线上 bug 的修复、随手加的调试输出、临时改的配置参数，甚至还有半截没做完的重构。全塞进一个提交，后面 bisect 排查或者同事 review 的时候，一定会被骂。这里真正要解决的问题就是：如何选择性提交 git 工作区的代码，把文件级、代码块级、甚至单行级的改动精确地挑出来，让每个提交都干干净净、主题单一。

这篇内容适合所有用 Git 的开发者。不管是刚接触 Git 的新人，还是天天与合并冲突打交道的熟手，都应该掌握这套“挑着提交”的方法。我会从最常见的几个场景拆起，然后把git add -p的交互式操作、图形化工具、常见坑和工作流建议一次性讲透。后面写的命令、按键、步骤，都是我实际项目里用过的，可以直接照着敲。

1. 为什么需要选择性提交：场景拆解与方案选型

1.1 三个典型场景，你大概率至少撞上一个

第一个场景，多文件混合修改。比如我调一个订单计算的 bug，改完calculate.js之后，顺手在logger.js里加了一行调试日志，又在config.js里把本地联调地址换掉了。这三个文件属于同一个提交吗？显然不是。修复计算逻辑应该单独提交，调试日志和本地配置改动要么不提交，要么放到一个chore类型的提交里，绝不能混在一起。

第二个场景，单文件多逻辑混杂。这是最让人头疼的。你打开一个文件，发现 git 的 diff 面板里密密麻麻列了七八处改动，有些是需求要的，有些是你在改的时候顺手调整的缩进、顺带发现的常量提取、测试完之后忘了删的注释代码。这些逻辑边界在同一个文件里搅成一团，普通的git add <file>根本没法区分，只能进到改动块级别去挑。

第三个场景，需求与提交粒度的匹配。合作项目里一个迭代可能同时推进好几个需求，十几个文件的改动穿插在一起。如果全放在一个提交里，后面要单独回滚其中一个需求的改动几乎不可能。原子提交的意义就在这里：每个提交只做一件事、解决一个问题、对应一个需求片段，方便用git bisect定位问题，也方便按功能维度做 code review。

1.2 为什么不能直接 git add .：原子提交不只是洁癖

很多人图省事，一个git add .全部丢进暂存区，再写个“update”就推上去了。短期看确实快，长期看全是债。

先说排查问题的场景。线上出 bug 后，最常用的手段就是git bisect，在一个区间内通过二分法找到引入问题的那个提交。如果你的历史里到处是“大杂烩提交”——一个提交里同时改了三个功能、几十个文件——二分定位到的提交只能告诉你“这一堆东西里的某一个有问题”，至于具体是哪个文件、哪行逻辑，还得大海捞针。反观一个提交只改一件事，git bisect直接就能锁到那个提交，看下提交信息基本就明白了。

再说回滚场景。线上环境发现某次改动有问题，需要快速回退。如果混提交，git revert <commit>会把里面所有改动统统退回，包括那些本来没问题、不该动的文件。要是这些文件里还有后续提交依赖的新逻辑，那 revert 还会引发一堆冲突。干净的提交则完全没这些事。

1.3 三种提交粒度：文件级、代码块级、单行级

选择性提交本质上是选择“哪些改动进入这次提交”，按粒度由粗到细可以分成三层：

我自己的选择原则是：能文件级解决的绝不上 hunk 级，能 hunk 级解决的尽量别用行级。因为粒度越细，操作越繁琐、出错概率越高，千万不能为了炫技把简单事情搞复杂。下面几章重点讲 hunk 级和行级的实操。

2. 核心实操：git add -p 交互式暂存

2.1 动手前先看一下全局状态

进入交互式暂存前，我习惯先花十几秒确认整体局面：

git status # 看哪些文件被改了，哪些已暂存 git diff --stat # 看每个文件改动量，评估改动规模 git diff # 粗看未暂存的具体差异

这些命令不复杂，但能帮你建立全局概念。比如git diff --stat一出来，你就知道这次改动是大手术还是小修小补；如果某个文件显示改动行数特别多，大概率是格式化工具扫描过整个文件，这种和业务无关的改动要格外小心，属于经典的“不该提交的内容”。

有需要的话，还可以用git diff --word-diff=plain看单词级别的变化。有些改动整行 diff 里看起来是“删了旧行加了新行”，其实只是中间改了一个词，这个参数能帮你更精确地判断改动意图。

另外确认一下你的 Git 版本，git add -p这个交互式功能从很早的 2.x 版本就有了，只要是 2.17 之后的版本都放心用。没装 Git 或者版本太老的，去官网下个对应平台的安装包，装完在终端跑一下git --version确认。

2.2 git add -p 的交互界面：每个按键都有存在意义

git add -p的核心原理是：Git 把工作区里未暂存的改动按连续区域拆成若干块，每个块叫一个 hunk，然后逐块询问你是否要暂存。先看一个典型界面长什么样：

diff --git a/src/order.js b/src/order.js index a1b2c3d..e4f5a6b 100644 --- a/src/order.js +++ b/src/order.js @@ -12,8 +12,10 @@ function calcTotal(items) { const price = getPrice(item); const qty = item.quantity; - if (price <= 0) continue; + if (price <= 0) continue; + if (item.discount && item.discount > 1) { + log("unexpected discount", item.discount); + } total += price * qty; } Stage this hunk [y,n,q,a,d,s,e,?]?

光标停在最后的?前，等着你输入指令。这里的按键作用是：

整个流程走一遍大概是：文件一个接一个地出现，每个文件里的 hunk 逐个问你。你按y把那几处属于本次需求的改动放进去，按n跳过调试日志和无关配置。等全部问完，再git status看一下，暂存区里是干净的、要提交的内容；工作区里剩下的，是你后面要继续处理或者永远不想进版本库的东西。

这里有个细节很容易被忽略：交互式选择完成后，已暂存的内容和未暂存的内容仍然是同一个文件的两个不同“版本”。比如一个文件里有 5 个 hunk，你暂存了头两个，那么这个文件在暂存区里是“只有前两处改动的版本”，在工作区里是“全部 5 处改动都有的完整版本”。后续再提交，相当于只把暂存区里的版本固化进了历史。

2.3 split 拆分与 edit 手动编辑：真正精细到行的姿势

先说s。当一个 hunk 里存在“看起来可以被逻辑隔离”的多个部分时，按s可以让 Git 尝试拆成更小的 hunk。Git 拆分的依据是上下文和空行边界，不是语义边界。比如两段改动之间隔了三行没动的代码，大概率能拆开；但如果两处改动紧紧挨在一起，中间没有足够的未改动行，Git 会提示拆不动。所以s解决的是“物理可分”的问题，解决不了“同一区域里混着两套逻辑”的问题。

这时候就要上e编辑模式。进入e后，Git 会打开一个临时文件让你手动改补丁内容。这里要理解 diff 补丁的格式：

• @@ -l,s +l,s @@开头的行表示改动位置，l是起始行号，s是块的行数
• 以空格开头的行是上下文行，表示前后没变化的代码
• 以-开头的行是删除内容
• 以+开头的行是新增内容

你可以在编辑窗口里删掉不想提交的-行和+行，只保留目标改动。看个简化的例子。假设原始 hunk 里既有“删除旧逻辑”又有“新增新逻辑”，但新逻辑独立成立，旧删除和它无关。把编辑窗口里的内容改成：

@@ -10,7 +10,6 @@ function saveUser(user) { const name = user.name; - const legacy = localStorage.getItem('legacy_user'); - if (legacy) migrateLegacy(legacy); // TODO remove + // new dedupe logic + const key = keyOf(user); + db.cache(key); db.save(user); return user; }

当然实际编辑更要小心。一个常见的报错是“您的补丁不适用”，原因通常是：你把某些-行删了，但剩余的上下文行不足以让 Git 在文件中唯一定位；或者新旧行数统计对不上@@头里的数字。解决这类问题的最好办法是保留尽可能多的上下文行，尤其是被改动区域前后的两三行没动过的代码，这样补丁应用起来就不容易失配。

还有一个备选方案：手动生成 patch 文件来应用。先跑git diff -- src/order.js > change.patch，然后用编辑器改这个 patch 文件，把不想提交的部分删干净，最后用git apply --cached change.patch只应用暂存区。这个方法比e模式更可控，适合想反复斟酌的场景，缺点是多几步操作。

2.4 stash -p 与 commit -p：两个容易被忽略的交互模式

交互式暂存不只add -p一个入口。git stash默认是把整个工作区的改动藏起来，但加上-p参数后，它也会启动交互式 hunk 选择——你可以只藏一部分改动，另一部分继续留在工作区里。这个场景我是真遇到过：下午改到一半的 A 功能暂时没法收尾，结果线上突然有个紧急 bug 要切分支去修。A 功能的半成品代码不能丢，又不能污染接下来的 hotfix 提交。这时候git stash push -p逐块挑出 A 相关的改动，把一个分支上的工作区变干净，剩下的留给另一个分支去处理。

另外还有git commit -p，它跳过暂存这步，直接让你在提交阶段选择 hunk。效果等价于git add -p之后再git commit，但少敲一条命令、少一次状态切换。我的个人习惯是：要提交的内容比较明确时就git add -p先看一眼，临时起意要直接提交时就用git commit -p。两者底层是一样的交互模式，掌握一个，另一个自然就会用。

3. 其他可靠的“挑着提交”姿势：图形化与终端工具

3.1 VS Code 里怎么操作：图形化不一定比命令行慢

很多同事用 VS Code 写代码，却不太清楚它自带一套相当顺手的暂存工具。打开源代码管理面板，能看到所有变更文件。想按文件暂存，点文件旁边的加号就行；想按改动块操作，直接打开这个文件看编辑器左侧的装订线——有改动的行旁边会有彩色竖条，点上去会弹出操作菜单，里面有“暂存更改”“还原更改”这类选项。

如果你觉得自带的还是不够细，可以装 GitLens 插件，它能把暂存操作做得更精细。不过这属于锦上添花，VS Code 内置的“点击装订线色块选择暂存或还原”基本就能覆盖日常需求。实际操作的时候，我反而觉得比命令行更直观，因为你能同时看到上下文代码，判断这个 hunk 到底是不是属于当前提交。

3.2 git gui：Windows 老开发者的老朋友

git 自带一个图形客户端叫git gui，启动后界面分几个区：左上角是未暂存变更列表，下方是 diff 详情面板，右边是暂存区和提交区。它真正拿手的是精细暂存：选中未暂存的某个文件后，diff 面板里右键点击某个 hunk，选“Stage Hunk for Commit”，就能把这个改动块单独暂存。更极致的是，你还能在 diff 面板里选中具体行，右键选“Stage Line for Commit”，做到真正单行暂存。

在 Windows 环境下，git gui 是很多老项目的标配工具，不依赖 IDE，启动快，操作路径也短。如果你不习惯纯命令行交互，但又要处理鲜明的“单文件混合改动”，git gui值得花十分钟上手。

3.3 三条路对比：什么场景用什么工具

把命令行、VS Code、git gui 放在一起比一比：

对于经常要在服务器上改东西、或者需要通过 SSH 连远程环境的开发者，命令行是绕不开的；而对于日常坐在 IDE 里写业务代码的人，VS Code 的图形化操作已经很够用。我的建议是：命令行要作为基本功，图形化工具作为辅助。至少要保证，在任何一个没有图形界面的环境里，你也能用git add -p完成一次干净的选择性提交。

4. 常见问题排查与避坑实录

4.1 .gitignore 没有作用：不是选择性提交的锅，但与它息息相关

这个热词出现频率极高：“git 的过滤文件没有作用”。大多数情况下，原因是文件已经被 Git 跟踪了。.gitignore只对未跟踪的文件生效，一个文件一旦进入过版本库，之后修改它，Git 依然会提示变更。这时候你想用选择性提交把它排除是不够的，得先把这个文件从版本库中移除跟踪。

git rm --cached <file> # 保留工作区文件，仅移除版本库跟踪

之后再把这个文件加进.gitignore，提交一次，后续改动就不会再出现在git status里。补充一个小命令：git check-ignore -v <file>可以查看是.gitignore里的哪条规则命中了某个文件，排查规则写没写对很有用。

和你实际挑提交的关系在于：如果你发现某个“不该出现”的文件总是混进改动列表，优先考虑是不是跟踪策略出了问题，而不是每次都在git add -p里费力地按n跳过它。治标还得治本。

4.2 add 多了、暂存错了、想放弃改动：回退的完整姿势

做选择性提交的时候，我很常见的一个失误是：交互式暂存时手滑按了a，导致当前及后续所有 hunk 全被暂存；或者按y时没仔细看 diff，把一个调试用的改动放进了暂存区。回退的办法很简单：

git restore --staged <file> # 取消暂存，工作区里的改动仍然保留 git reset HEAD <file> # 老版本写法，效果相同

这个操作只影响暂存区，不影响工作区的文件内容，可以放心用、反复用。但如果要丢弃工作区里某个文件的改动，就要小心了：

git restore <file> # 危险！会用暂存区内容覆盖工作区，未暂存改动直接丢失 git checkout -- <file> # 老版本写法，同样危险

这类操作不可恢复，执行前最好先git diff <file>确认里面没有你想要的内容，或者干脆把文件先复制一份备份。git reset --hard属于终极武器，会丢所有未提交改动，我在做选择性提交时基本不会碰它。万一真的把不想提交的内容提交了，还有一招是git commit --amend修改上次提交，把不需要的内容从提交里移除，但要注意这也要小心处理，因为--amend会改变提交哈希，多人协作的分支上不要随便用。

4.3 基于灰度故障场景：SSH 认证失败时先稳住状态

热词里还有一个高频问题：“SSH 认证失败 git”。这和选择性提交本身关系不大，但值得专门提一句：当你发现git fetch、git pull、git push突然报认证错误时，别慌，也别立刻做任何会改动工作区状态的操作。先看远程地址是哪种类型：

git remote -v

如果是https://开头的地址，认证走的是用户名密码或 token；如果是git@xxx:开头的地址，走的是 SSH key。SSH 认证失败通常涉及 key 文件权限、agent 加载、公钥是否正确登记等问题。排查期间，你的工作区、暂存区是完全独立的，不会因为远程访问失败而丢失。等认证问题修复后，再做你要的选择性提交，流程照旧。

4.4 分支合并冲突时怎么挑提交

合并冲突是另一个高频词。合并时冲突标记会写进工作区文件，比如这种形态：

<<<<<<< HEAD const price = basePrice; ======= const price = getPromoPrice(item); >>>>>>> feature/discount

这时候最忌讳的就是git add .把所有文件一锅端。正确的姿势是：打开每个冲突文件，逐段判断保留哪一个版本，或者手动融合两边逻辑，把冲突标记删干净后再选择性提交。冲突解决后的提交本来就是一个“合并两个意图”的动作，这时候更需要用 hunk 级操作去确保各个改动块都符合解决冲突时的意图，而不是把一份没理顺的文件直接塞进历史。

5. 工作流建议：选择性提交不该是补救动作

5.1 提交前问自己三个问题

我在团队里推行过一个简单的约定：每次提交前，对着git status和git diff问三个问题。第一，这个提交里有没有跟当前需求无关的改动？第二，被删掉的行里，有没有之后可能还要用上的逻辑？第三，只看提交信息，能不能明确知道这个提交解决了什么、为什么这么改？

这三个问题看着简单，却能把大多数脏提交挡在门外。第一个问题靠选择性提交解决，第二个问题靠git stash -p或暂存区回退解决，第三个问题靠提交信息的规范化解决。每个问题都有对应的标准动作，就不会事到临头手忙脚乱。

5.2 提交信息怎么写：类型、范围、动机

既然要做到“每个提交只做一件事”，提交信息就要能清楚描述这一件事。我自己常用的格式是：类型加英文括号加模块名，再加冒号加一句简洁的改动说明。类型常见的有feat、fix、chore、refactor、test、docs。举个例子：

fix(order): 修复会员折扣计算未覆盖积分抵扣场景 原逻辑只考虑了折扣价，没有判断用户是否使用积分；在启用积分抵扣的 订单中，总价会被错误抬升。修复后在折扣基础上扣除积分抵扣金额。

第一行控制核心主旨，正文说明背景和影响范围。这样写出来的历史，配合干净的选择性提交，Git 历史的可读性会有一个质的提升。你想想，半年后你自己回来看这段提交，能一分钟还原当时的改动上下文，这笔时间投资太值了。

5.3 把选择性提交固化到日常流程里

最后说说我个人的工作习惯。每次开始动代码前，先git status看下工作区是不是干净；写完一个独立的逻辑单元，马上做一次选择性提交，不等攒到一堆才处理。这个习惯刚开始会觉得很繁琐，因为一个上午可能要提交四五次。但坚持下来之后，你会有两个明显的感受：一是你的改动思路会更清晰，因为为了拆分提交，你必须先把逻辑边界想明白；二是后续排查问题时舒服太多，git log浏览起来一目了然。

我还有个固执的小偏好：所有临时调试代码都尽量集中在少数几个文件里，提交时直接对这几个文件按n跳过即可。这样比每次在几十个文件里大海捞针地找“哪些是调试改动”高效太多。

实际上“选择性提交”这个能力，在协作开发里更是硬通货。别人怎么信任你的提交记录，就是从这些细节里一点点建立起来的。把git add -p用熟练之后，你大概率会跟我一样，再也回不去无脑git add .的日子。挑提交这件事，说到底就是对自己的代码负责，也对看代码的同事负责。