企业官网建设流程全解析

先聊个场景：功能做了一半，测试时顺手加了几行日志，又顺手把同事写的一个小bug改了。这时候线上突然报问题，你只想提交那个bug修复，把半成品和调试日志留在工作区。很多人遇到这种情况会手足无措，要么把不该提交的一股脑推上去，要么笨拙地复制粘贴文件备份。其实git早就提供了完整的选择性提交能力，只不过大部分教程只会教你git add和git commit，从来没讲清楚怎么“挑着提交”。这篇我把自己常用的几种选择性提交方式、踩过的坑、以及背后的原理一次讲透，看完你就能在工作区里随心所欲地挑代码提交，而且不出幺蛾子。

1. 先搞清楚为什么要选择性提交

1.1 一个真实的“翻车现场”

我印象很深的一次翻车，是给一个老项目做重构时，顺手在一个公共工具库里加了两个没写完的新函数。当时逻辑上觉得“代码反正都在工作区，不提交就行了”，结果提交之前用IDE的自动整理功能把整个文件格式化了一遍。格式化这种事最可怕，它会把你没有改过的几十行代码也变成“改动”。等我把文件add进去，再push到远端，同事一拉代码就发现提交里混进了一堆和他正在开发的内容无关的行。代码没冲突，review却被喷得很惨。

从那以后我彻底明白，选择性提交不是“洁癖”，而是团队协作里的基本礼貌。一个提交应该只包含一个逻辑改动，要么是修bug、要么是加功能、要么是调格式，混在一起会让历史变得没法看，也不利于后面用git bisect定位问题。更重要的是，很多团队有CI/CD流程，提交时会自动跑lint、测试或者格式化检查，你把调试代码、临时print、没写完的函数一块提交上去，构建失败是小事，卡住别人上线的流程才是大事。

所以选择性提交解决的本质问题，是从“我已经改了一堆东西”到“我应该提交哪些东西”这个过渡环节。它不是在提交之后再去修补，而是在提交之前就用好git的暂存机制，把工作区的改动精确地筛选出来。

1.2 git三区模型是选择性提交的地基

如果你只是机械地背命令，那选择性提交总是容易绕晕。我自己的经验是，先吃透git的“三区”概念：工作区、暂存区、版本库。

• 工作区（working tree）：就是你电脑上看得见的文件目录，改动的结果是直接体现在这里的。
• 暂存区（index/staging area）：是一个介于工作区和版本库之间的中间层，你可以把它理解为“下一提交的候选清单”。
• 版本库（repository）：是git保存提交记录的地方，每一次commit就是把暂存区的快照永久记录进去。

平常我写代码是在工作区改动，git add把某个文件的当前版本放进暂存区，git commit把暂存区一次性固化到版本库。而选择性提交的核心思路，就是把“这个文件我要不要提交”这个粒度，进一步细化到“这个文件里的这些改动行我要不要提交”。这中间靠的全是暂存区这个中间层的灵活性：你可以只把一个文件里的一部分改动放进暂存区，另一部分留在工作区。

这个“同一个文件还能拆开暂存”的概念，很多用了几年git的人都不知道。他们以为git add要么就是整个文件进暂存区，要么不进去，所以一遇到“一个文件里有两处改动，只想提交一处”就慌了，只能复制文件临时改名，或者干脆把无关改动一起提交。理解了暂存区之后，你就知道git其实允许你以行为单位操作暂存区，这正是选择性提交真正的底气。

1.3 选择性提交主要解决三类场景

我第一次系统性整理选择性提交方法时，把实际会遇到的情况分成了三类，后面所有操作其实都是在围绕这三类场景做文章。

第一类是多文件场景：工作区里改了三个文件，只想提交其中一个或两个，剩下的等以后再处理。这个用git add <file>加路径参数就能搞定，但很多人没有正确理解它的边界，容易在提交指定文件时把工作区里未暂存的改动也带进去，后文我会专门讲这个坑。

第二类是单文件多改动场景：一个文件里有两处甚至多处彼此独立的改动，只想提交其中某几行，这个就必须用到交互式暂存，也就是git add -p的核心用途。比如我改了一个函数，又顺手在同一文件里加了个debug输出，用这个方式就能把debug输出直接过滤掉。

第三类是“提交内容整理”场景：需要把一个逻辑改动拆成多个提交，或者把当前暂存区内不满意的一部分内容挪出去。这类需要用到git reset -p、git stash -p这些稍微冷门的交互式命令。

这三类场景没有哪一个是空谈术语，全都能落到具体命令上。下面我按优先级一个个说清楚。

2. git add -p：最常用的交互式选择性提交

2.1 所谓hunk到底是什么

要讲git add -p，必须先理解hunk这个概念。git对文件做差异对比时，不是把每个改动行单独列出来，而是把改动连同周围的上下文行打包成一个一个的片段，这个片段在git里就叫hunk，中文常译作“代码块”或“变更块”。

hunk的边界是git根据diff的行数自动确定的。打开任意一次diff，你会看到类似@@ -15,7 +15,8 @@这样的行，这就是hunk的起始标记，-15,7表示原文件从第15行开始的7行，+15,8表示新文件从第15行开始的8行。而一个hunk里除了真正的增删行，还包含默认3行的上下文行。

为什么是3行？因为git有个配置项叫diff.context，默认值是3，意思是相邻两处改动之间如果相隔6行以内，git就会把它们合并成一个hunk。反过来，如果两处改动距离较远，它们就会变成两个独立的hunk。这个参数可以调大调小，后面讲“hunk太大怎么拆”的时候还要用上。

理解hunk是理解选择性提交的关键，因为git add -p就是一次给你展示一个hunk，让你决定“这个hunk要不要进入暂存区”。一个hunk你想全部要就要，全部不要就跳过，而如果hunk内部还有不相干的改动，你就得用后面的s拆分或者e编辑方式进一步裁剪。

2.2 进入交互后你能按哪些键

进入交互模式很简单，在仓库根目录执行git add -p，git会遍历所有有未暂存改动的文件，然后一个hunk一个hunk地展示，每展示一个就停下来等你按键确认。

我第一次执行这个命令时有点懵，因为它会打印类似这样的内容：

diff --git a/config.py b/config.py index 1234567..89abcde 100644 --- a/config.py +++ b/config.py @@ -20,7 +20,7 @@ def load_config(): parser.add_argument("--host") parser.add_argument("--port") - parser.add_argument("--debug", default=False) + parser.add_argument("--debug", default=True) parser.add_argument("--rate_limit", type=int, default=50) parser.add_argument("--threads", type=int, default=4) Stage this hunk [y,n,q,a,d,s,e,?]?

这串提示是最重点的部分。我整理了一张速查表，你把它保存下来，比临时满网搜效率高得多：

这里我特别提醒两点。第一，a和d是“这个文件之后所有hunk”的意思，不是“所有文件”，所以你在一个文件里确认了某个hunk之后按d，下一个文件还是会继续弹出来问你；第二，s能不能拆成功，取决于当前hunk里是否包含了多个改动块，而“改动块之间有没有空档”的实际判断标准是：它们各自的上下文行不能有重叠。如果重叠了，s会直接告诉你不能拆，这时候你得用e手动编辑，或者退出去调整diff.context再进来。

2.3 为什么我把add -p放在第一位

可能有人觉得，很多IDE比如VS Code、IntelliJ都提供了可视化的选择性提交界面，鼠标点一点就能把某个文件的某个代码块挑出来暂存，为什么还要学命令行？

我自己的体会是：命令行更可控，也更适合批量操作。GUI的选择性提交通常是“点行”或者“点代码块”，一次只能处理一个文件，而且你很难在操作过程中快速看到整个diff上下文。git add -p是纯文本的，终端里就能完整看到每个hunk的上下文，还能随时切换查看，遇到复杂拆分可以直接进入编辑器用diff文本精确控制。更关键的是，GUI工具的可选择性受版本限制，偶尔还会出现功能隐藏很深找不到的情况；而命令行这套交互从Git 1.x时代就有了，在任何环境、任何操作系统下行为都一致。

另外一个实际好处是，git add -p可以与Shell别名、脚本无缝搭配。我自己在.bashrc里就配了一个alias gap='git add -p'，敲两个命令就能快速进入暂存选择器，比打开IDE找半天菜单快得多。

3. 完整实操：从多文件筛选到单文件挑行

3.1 场景A：改了好几个文件，只想提交其中一个

这是最基础的选择性提交，但不少人在这上面犯过一个隐蔽错误。假设我改了a.py、b.py、c.py三个文件，现在只想提交a.py的改动。常规做法是：

git add a.py git commit -m "fix: 修复a模块的问题"

这样提交确实只包含a.py的改动，但如果你敲的是git commit a.py -m "..."这句话，答案就不一样了。git commit <路径>这个语法有一个特殊语义：它会直接用工作区里该文件的当前内容更新暂存区，然后再提交这个文件的全部改动。换句话说，即使a.py还留有没有被git add的改动，git commit a.py也会把它们一并提交。

我吃过这个亏。有一次我在a.py里存了两处修改，一处是改好的功能，另一处是没写完的试验代码。我先用git add -p只把功能部分放进了暂存区，然后顺手敲了git commit a.py -m "..."，结果试验代码也进了提交，当场血压拉满。所以现在的规则我建议你直接记住：提交某个文件时，要么先git add <文件>再不带路径git commit -m，要么干脆不用git commit <路径>这种写法。

3.2 场景B：同一个文件只提交一部分改动

假设main.py里有两个改动块，第一个是修了一个空指针判断，第二个是加了一行调试print。我只想提交空指针的修复，调试print留在工作区继续调试。这时候执行：

git add -p main.py

git会先展示第一个hunk，我判断是空指针修复，按y；接着展示第二个hunk，我判断是调试print，按n。等全部hunk处理完，git会自动回到命令行。然后执行：

git status

你会看到main.py的状态变成了MM，左边的M代表暂存区里有改动，右边的M代表工作区里还有未暂存的改动。这就说明选择性提交成功了一半。接下来只要提交：

git commit -m "fix: 修复空指针判断"

提交完成后，main.py里那个调试print仍然安静地躺在工作区里。这种“提交完代码文件还是脏的”状态很多人第一次见会慌，误以为提交没成功，其实这正是预期效果。

实际操作中有一个判段hunk是否精确的技巧：在交互提示处按?能看帮助，但你更应该习惯在交互前先跑一遍git diff，把整个文件的diff预览一遍，心里大概有几个hunk、各自是什么内容，再进add -p时按y/n才会又快又准。否则你看着hunk里的上下文行判断不出这是哪段逻辑，很容易按错。

3.3 场景C：hunk太大，用e手动编辑

这是选择性提交里最硬核，也是最容易劝退新人的部分。遇到的情况通常是：一个hunk里有三处改动，其中两处想提交，一处不想提交。你按s想拆分，git却提示无法拆分，因为改动块之间共享了上下文行。

这时按e会打开一个文本编辑器，内容大概是这样的：

# Manual hunk edit mode -- see bottom for a quick guide. @@ -10,7 +10,7 @@ def init(): config = load_config() - if config.debug: - print("running in debug mode") + if config.debug: + print("running in debug mode, extra log") start_server(config) - setup_metrics(enable=False) + setup_metrics(enable=True)

编辑规则其实不复杂：在这个临时文件里，-开头的行表示要删除，+开头的行表示要新增。你只需要把你不想提交的改动行删掉，或者用注释方式处理，就能手动控制hunk的最终内容。举刚才的例子，我只想提交setup_metrics那部分的修改，不想提交第一处debug输出，就可以把第一处相关的行改成这样：

@@ -10,7 +10,7 @@ def init(): config = load_config() - if config.debug: - print("running in debug mode") +# if config.debug: +# print("running in debug mode") start_server(config) - setup_metrics(enable=False) + setup_metrics(enable=True)

注意，这里把不想删掉的行前面的-改成了#，呈现在diff里就是“这一行没有变化”。然后保存退出编辑器，git会验证这个手动修改后的hunk是否合法。合法的话，它就进入暂存区；不合法，git会明确报“您的补丁未应用”，然后你重新按e再改一次。

这里有个实战细节：编辑时千万不要破坏hunk头@@ -10,7 +10,7 @@的上下文行数，因为你增减了行数却不改hunk头，补丁就失效了。最稳妥的做法是，只把-和+开头的行改成其他形式，少动上下文行本身，这样hunk头的行数大概率还能对得上。如果改完git提示补丁有问题，别慌，重新进入编辑状态检查一下行数即可。

3.4 提交前必须养成的检查习惯

无论你是用git add -p、git add -i还是GUI工具做选择性提交，提交前一定要看一眼“最终要提交什么”。这个检查命令是：

git diff --cached

没有--cached的git diff看的是工作区还没暂存的改动，加上--cached才能看到暂存区里即将被提交的内容。我见过太多人不检查就git commit，提交完了才发现暂存区里多了一个不想提交的文件，或者少了一个应该提交的hunk，最后还得搞一波git reset和git commit --amend。

我自己的习惯是提交前跑三连：

git status git diff --stat git diff --cached

第一条看整体状态，第二条看有哪些文件改动量多大，第三条精读即将提交的差异。这一套流程熟练之后十秒钟就能扫完，但它能把你在交互式选择时犯的错拦下一大半。

4. 备选方案与进阶组合拳

4.1 不想慢慢按键？试试git add -i的12宫格菜单

git add -i是比git add -p更老牌的交互式暂存入口，它的界面风格像一个菜单，进入后你会看到类似这样的输出：

*** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help

这里每个数字对应一项操作。其中2: update可以批量选择要暂存的文件；5: patch进去后和git add -p几乎一样，照样一hunk一hunk地问；3: revert则能把已经暂存的内容退回去。

说实话，git add -i在平时不是我的首选，因为git add -p已经覆盖了百分之八十的需求，而且更直接。但有一个场景它好用：当你需要批量查看“哪些文件可暂存、哪些文件尚未暂存”，想在一个直观的菜单里快速切换时，git add -i的status和update组合能让你少敲很多命令。另外，如果你写自动化脚本想跟交互式暂存打交道，git add -i的输出更适合解析。所以我的建议是，先掌握add -p，把它用熟，再当彩蛋去了解add -i，不必一开始就硬啃。

4.2 把不需要提交的改动“隔离”开：git stash -p

git stash大家应该都熟，它的作用是把工作区变干净，改动存到一个临时堆栈里。但很多人不知道git stash也支持交互式的部分暂存，命令是：

git stash push -p

它同样是一hunk一hunk地问你“这个存不存到stash里”，挑中的hunk会从工作区挪走，没挑中的保留在工作区。这个特性在一种场景下特别有用：你现在的工作区里有一堆属于“A任务”的新功能代码，突然来了个紧急“B任务”，你得先修复B并提交。但A任务的代码里还有一些并不是独立成文件，而是穿插在同一个文件里的。这时候与其用add -p去选B相关的hunk，不如反过来：用git stash push -p把A的hunk全部暂存走，工作区只剩下B的改动。

等B的提交完成后，再用git stash pop把A的改动从stash里恢复回来。简单说，add -p是“正向挑要提交的”，stash -p是“反向挑要保留的”，两者配合起来覆盖面就很完整了。

不过要提醒的是，stash pop回到工作区时如果和当前代码有冲突，需要手动解决，所以使用前最好把当前状态梳理清楚，不要stash里堆太多东西自己都忘了哪份是哪个任务的代码。

4.3 谨慎使用git commit指定文件

前面已经聊过git commit <路径>的坑，这里我再展开一点。这个语法的全称是“提交该路径对应的改动”，但gits的内部行为是先用工作区内容把暂存区刷新一遍再提交，所以它根本不管你到底按hunkselect了什么。

我见过一些同学为了保证“只提交某几个文件”，每次都写git commit 文件A 文件B -m "..."，表面上确实只提交了这两个文件，可一旦这两个文件里还有尚未暂存的新改动，也会一起进去。这个行为在官方文档里叫--only语义，理解起来容易绕。我只给一条最朴素的结论：想精确提交，先add再commit，不把文件路径写进commit命令。

4.4 暂存错了怎么退回去：交互式撤销暂存

选择性提交的过程中，按错键是常有的事。本来想按n跳过某个hunk，结果手滑按了y；或者想提交的hunk漏选了，提交之后才发现。这类情况有两个常用纠正手段。

第一个是提交前用git reset -p恢复部分暂存内容。它和add -p是镜像操作，add -p是把工作区hunk放入暂存区，reset -p是把暂存区hunk移出暂存区。进入后它会问你“这个hunk要从暂存区撤销吗”，按y就撤销。这样的话你不用把整个文件从暂存区全部退回去重新选，很精细。

第二个是提交后才发现搞错了，但提交还没push到远端，这时候的修复流程是：

git reset --soft HEAD~1

--soft会把这次提交的所有改动退回暂存区，但不碰工作区。接着你可以用git reset -p把不该进来的部分撤销掉，再重新git commit合并成一个干净提交。这套组合我用了很多年，基本能覆盖绝大多数“提交内容不对”的紧急情况。

如果你的提交已经push到了远端，那事情就没这么简单了，会涉及修改公共历史的问题，这就需要和团队协商，而不是你自己悄悄force push解决。这条原则值得刻在脑子里：提交可以很轻松地改，推送出去的历史改写要谨慎。

5. 常见问题与排查技巧实录

5.1 hunk太大、拆不开怎么办

用最新版的git配合默认上下文3行时，两个改动块之间如果空行太少，就会合成一个大hunk，然后你按s拆分时git会提示Split failed。出现这个提示，本质原因是两个改动块的上下文行有重叠，按s无法把边界切开来。

我的处理方式是优先设置上下文行数为1，让diff粒度更细。可以临时这样敲：

git -c diff.context=1 add -p

也可以永久写进配置：

git config --global diff.context 1

注意，diff.context只影响后续diff的上下文行数，并不会让你丢任何内容，它只是改变hunk的呈现粒度。设置为1之后，原来因为上下文重叠而合并的hunk很可能就自然拆开了。不过也别觉得设置得越小越好，上下文行太少会看不清改动周围的代码环境，影响判断。我一般日常用3，遇到复杂文件时临时切到1。

5.2 编辑hunk总是提示“补丁未应用”

用e手动编辑时，最常见的失败原因就是hunk头里的行数信息和实际改动对不上。比如你把某一行删掉了，却没有把@@ -10,7 +10,7 @@里的7改成6，git在应用补丁时就发现行数对不上，然后报错。

解决方法是手动修正hunk头。比如你在编辑时少了一行-开头的行，那么原文件部分的行数要减1，也就是-10,7改成-10,6；如果你少了新增行，+10,7也是同理。第一次弄这个确实容易乱，我的建议是编辑时尽量少改结构，只把不要的-/+行改成注释形式，这样行数完全不变，就不用动hunk头。如果确实删除了行，就仔细数一数再改hunk头，慢慢来总比反复报错强。

5.3 换行符和空行差异让你没法选择

在Windows上开发的人会经常碰到一种烦恼：明明只改了一行代码，git却把整个文件都当成被修改了。原因通常是CRLF和LF换行符的差异。Windows默认用的是\r\n，Linux/macOS默认是\n，git在配置了core.autocrlf之后会把换行符自动转换，但当备份文件、外部拷贝、编译器生成的临时内容混进来时，diff会被这些看不见的字符搅乱，hunk的展示就会变得极其诡异。

这时候先用这个命令看看到底是不是换行符搞的鬼：

git diff --ignore-space-at-eol

或者彻底忽略空白差异：

git diff -w

看到的结果如果只剩下真实的代码变化，那就确认是换行符干扰。根治方式是统一项目换行符策略，在项目根目录加一个.gitattributes文件，声明* text=auto或者具体指定*.py text eol=lf，让git在入库时统一转换。这类问题处理完，git add -p的hunk就会恢复正常，不再把整个文件变成一个无法细分的巨无霸。

5.4 我能给你的最后一条经验

选择性提交做多了，我最大的感受是：它不应该等代码全部写完才想起来用，而应该嵌在日常开发流程里。提交前先git diff看一遍，改动的第一眼就要清晰。提交动作要小，一个提交只对应一个目标。给自己配几条顺手别名，比如gst查看status、gap进入add -p、gdc查看暂存区diff，实际效率提升立竿见影。

另外我想强调，git不会帮你判断“哪些改动属于同一个逻辑”，它只负责按你的指令去拆hunk。真正要折腾的选择性提交，前提是你对自己的工作区改动有足够认知。如果连自己改了什么都不清楚，那再多的命令技巧也救不了你。反过来，只要你清楚自己的改动，git add -p这套交互流程几分钟就能让你变成一个能把提交做得干干净净的人。