Git提交四件套：add、commit、status与stash实战

在我带过的几批新人里，几乎所有人卡在 Git 上的第一道坎都是“明明已经改好了文件，为什么队友拉下来却什么都没有”。问题基本都出在提交这条链路上：add没加对、commit提交了但不该提交的内容、status不会看、临时被打断时又不知道该怎么把现场收起来。这次就把提交相关的四件事一次性讲透：add负责把改动放进暂存区，commit负责把暂存区固化成一次历史节点，status负责在动手之前告诉你会发生什么，stash则在被迫切换任务时帮你把未完成的现场暂时保存起来。同时还要把提交散列值、提交历史、多次提交的组织方式和忽略规则一并说明，因为这四者不是孤立的命令，而是一套互相咬合的机制。适合已经能跑通clone、pull、push，但提交记录写得凌乱、遇到冲突就手忙脚乱的读者；也适合想把 Git 用得干净一点、让提交历史能真正当文档看的人。

1. 先把提交这件事的底层逻辑捋直

1.1 工作区、暂存区、版本库：三棵树的模型

很多人用不好 Git，原因并不在记不住命令，而在于脑子里对“文件到底在哪”没有清晰的地图。Git 自带一张地图，就是常说的三棵树模型：工作区是你编辑器里打开的那一堆文件，随便改、随便删，Git 都不关心；暂存区（也叫索引，index）是一个中间层，记录着“下次提交的时候，我想把哪些内容装进去”；版本库也就是.git目录，存放着一次次提交形成的对象数据库和分支指针。三者的关系可以这么理解：工作区是书桌，改乱了也不影响别人；暂存区是一个托盘，你把要交付的东西挑出来放上去；版本库是档案柜，托盘上的东西一旦登记入柜，就有了永久编号，想反悔得走另一套流程。

这个模型解释了日常最容易困惑的一个现象：文件改完以后直接执行git commit，有时会提示“没有需要提交的改动”，原因是工作区的内容还没有进入托盘，档案柜当然没东西可登记。也解释了另一个现象：明明删掉了文件，历史里却还在，因为删除动作本身也只是工作区的一次修改，需要同样经过暂存区这一步。理解了三棵树的边界，后面所有命令的参数就都能对上号：add是“工作区 → 暂存区”，commit是“暂存区 → 版本库”，status是“三棵树之间的差异体检报告”，stash则是“把工作区和暂存区的现场整体卷起来，暂时放到一边”。

1.2 为什么不干脆改完直接提交

第一次接触暂存区的人多半会有个疑问：多这一层不是纯添麻烦吗？直接改完就提交不行吗？行，但会丢掉三样非常值钱的能力。

第一是选择性提交。你在文件 A 里修了一个线上 bug，顺手又改了几行无关紧要的格式，还动了文件 B 的实验性代码。如果没有暂存区，这一批改动只能整个提交，代码评审的人得在一堆噪音里找那三行真正的修复。有了暂存区，你可以只把 bug 修复那几行放上去，格式和实验代码留着继续写，这直接决定了提交记录的可读性。

第二是提交前的预演。add之后跑一次git diff --cached，你看到的就是“这次提交到底会是什么样”，而不是凭印象猜。这一步挡掉的错误比任何规范都管用，我见过太多把临时调试代码、本地配置、数据库口令一起提交上去的情况，都是因为跳过了这个预演环节。

第三是断点保护。暂存区本身也是一份状态，你可以放心地在工作区继续改，托盘上那份已经定型的改动不会跟着变。这在做一些有风险的实验时特别有用——先把手头能跑通的版本登记到托盘上，再去折腾新写法，就算改崩了，托盘上的内容还在。

1.3 四个命令的职责边界与常用参数全景

先把分工摆清楚，避免用错工具。下面这张表是我平时贴在显示器边上的一份速查，左侧是命令，中间是它在三棵树里动的是哪一段，右侧是几个高频参数和典型用途。

有一点需要提前说清楚：git stash并不等于git add的替代品，这两者处理的是完全不同的事情。add是把改动推进提交链路，stash是把改动移出提交链路。用户标题里写的“stach”其实是stash的常见错拼，这个词在 Git 里就是“藏起来”的意思，下文统一用正确拼写。

2. 四个命令逐个拆开：语义、参数与实操细节

2.1 git add：把“想提交什么”这件事表达清楚

git add的参数设计其实就是在回答一个问题：你到底想把哪些改动放进托盘。最基础的git add 文件路径只处理指定文件；git add .处理当前目录及所有子目录的改动；git add -A处理整个仓库范围内的一切改动，包括新增、修改和删除。这里有个历史上容易踩的坑：老版本里git add .不处理“删除”这个动作，导致删掉的文件提交不上去，现在主流版本已经统一了行为，但如果你在别人的机器上操作，最好还是养成用git add -A处理全量的习惯，至少语义上没有歧义。

真正值得花时间掌握的是git add -p。它会把每一处改动切成小块，逐块问你“这一块要不要”？选项里y是要，n是不要，s是把这一块再拆细，e是手工编辑要提交的具体行，q退出，?看帮助。这个命令是让提交记录变干净的关键。举个具体场景：你在一个函数里修了 bug，同时在同一文件里加了两行print调试。用git add -p，第一块选y，那两行print选n，提交记录里就只有修复，没有调试代码。如果是新手，我一般建议先在这上面花二十分钟练手，收益比背十个命令都高。

另外一个容易被忽略的点是换行符和文件权限。在某些环境下，编辑器会把整个文件的换行符从 CRLF 改成 LF，git status显示整个文件都被修改了，实际上你只改了一行。这类“全文件 diff”会让人根本没法审代码。解决思路是在仓库根目录放一个.gitattributes，明确告诉 Git 哪类文件用什么换行策略；至于文件权限，如果只在本地遇到成片的mode change，检查是不是复制文件导致的，必要时用git config core.fileMode false关掉权限位比较——但这属于团队约定层面的事，动手前跟队友对一下，别单方面改。

注意：git add之后文件内容又被你改过了，暂存区里保存的仍是add那一刻的版本。这时候git status会同时显示“已暂存”和“未暂存”两条记录，这不是 bug，恰恰是暂存区作为快照的价值所在。

2.2 git commit：把托盘上的内容固化成历史节点

git commit的核心语义只有一句话：把暂存区当前的内容，连同作者、时间、说明一起打包，生成一个带唯一编号的历史节点。最常用的写法是git commit -m "说明"，但我不建议只用一个-m，尤其是改动稍微复杂一点的时候。多写一个-m就多一段，第一段当标题，第二段开始当正文，用来解释“为什么要这么改”。半年后回来翻记录的人（很可能就是你自己）真正需要的是动机，而不是把 diff 再复述一遍。

git commit -v是我最推荐的一个参数。它会在提交信息编辑器里附上本次的完整 diff，你一边写说明一边对照实际改了什么，能发现“我以为是三行改动结果动了三十行”这类事故。配上-a就变成了跳过add直接提交所有已跟踪文件的改动，但这个组合要慎用：它绕过了选择性提交，而且新手常见的问题是把它当成“万能提交”，最后把不该提交的东西一起带上去。我的建议是，日常老老实实add完再commit，只在非常确定的场景下用-a。

git commit --amend用来修补最近一条提交，包括改说明和补内容两件事。改内容时，先add新的改动，再--amend --no-edit，新内容会合并进上一条提交。这个操作必须带一个前提认知：它是在改写历史，会产生一个全新的提交编号。如果这条提交已经推送到共享分支，别人拉过之后你的改写会造成分叉，麻烦就不是你能单方面收拾的了。所以这条命令的安全边界很清楚：只对还没推送出去的本地提交使用，这是个底线。

2.3 git status：动手之前先看仪表盘

git status在很多人眼里是个“看一眼有没有改东西”的命令，实际上它给的信息比你想象的多，而且它是最便宜的检查手段，几毫秒就能跑完。完整输出的结构是：当前分支、与上游分支的领先或落后情况、已暂存的改动、未暂存的改动、未跟踪的文件。这五块信息基本就是提交前需要确认的全部内容。

短格式git status -s用两列字符表示状态，掌握之后效率会高很多：左侧一列是暂存区的状态，右侧一列是工作区的状态，M是修改、A是新增、D是删除、R是重命名、U是冲突状态、??表示未被跟踪。举例来说，MM意味着这个文件在暂存区和工作区都有一份修改，AM表示新文件已经加进暂存区，之后又改了一次。看懂这个组合，你就可以在不切窗口的情况下判断“现在提交会提交哪些内容”。

把status和diff配合起来用是标准动作：git diff看工作区相对暂存区改了什么，git diff --cached看暂存区相对最后一次提交改了什么，也就是“如果现在提交，内容是什么样”。我自己的固定流程是三条连招——status看全局、diff --cached看细节、commit -v写说明时再核对一遍。整套下来不超过三十秒，能挡掉九成以上的误提交。

提示：git status默认会忽略被.gitignore挡掉的文件。如果怀疑某个该忽略的没生效，加上--ignored参数，它会把被忽略的文件也列出来，配合忽略规则排查非常顺手。

2.4 git stash：被打断时怎么把现场收起来

正写着新功能，代码改了一半还编译不过，突然要切到另一个分支修个紧急问题。直接切分支会报错，因为未提交的改动会跟着你过去，导致另一条分支也乱掉。这时候临时提交一次也不合适，留下半成品提交记录很难看。git stash就是为这个场景设计的：它把工作区和暂存区的改动打包藏起来，让工作区回到干净状态，等忙完之后再还原。

基础流程是四步。第一步git stash push -m "说明"把当前现场藏起来，强烈建议加-m，因为默认的WIP on 分支名一旦攒了三四条就完全分不清谁是谁。第二步正常切分支、处理事情、提交、再切回来。第三步git stash list看一眼藏了什么，输出类似stash@{0}: On main: 说明，序号越小越新。第四步git stash pop恢复最新的那条并把它从列表里删掉，或者用git stash apply stash@{1}恢复指定的一条但保留记录。

pop和apply的差别值得单独说一句：pop是“取出并销毁”，apply是“取出但保留”。恢复过程中如果和当前代码冲突，pop就不会删除记录，这一点倒是挺体贴。但如果恢复过程顺利、你又误删了现场，就只能去翻git fsck --lost-found捞游离对象了，成本极高。所以我个人的习惯是恢复一律用apply，确认代码没问题之后再手动git stash drop清掉，多一条命令，少一次事故。

还有一个参数必须记住：默认情况下stash不处理未跟踪的新文件。你新建了一个文件，没add过，直接stash，它不会跟着被藏起来，切换分支时会明晃晃地待在那里。要连它一起收走就得加-u（包含未跟踪文件），或者-a（连被忽略的文件也一起收）。这一点我见过太多人在这里栽跟头。

3. 提交散列值：Git 用来标识每一次提交的编号

3.1 四十位十六进制编号是怎么来的

每次提交都会生成一个形如a1b2c3d...的四十位十六进制字符串，这就是提交散列值，也叫提交哈希、commit id。它的生成方式不神秘：Git 把这次提交的全部内容拼成一个字节流，包括指向的目录树对象、父提交的编号、作者和提交者的名字与时间戳、以及提交说明，前面再加上类型和长度信息，然后对这个整体做一次密码学摘要运算。

这里的关键在于“全部内容都参与运算”。改动任何一处，哪怕只是提交说明里多了一个空格，算出来的结果都会面目全非，这就是所谓雪崩效应。所以散列值实际上充当了内容的指纹：两个编号相同，就可以确信内容一模一样；内容有任何差异，编号必然不同。这也顺带解释了 Git 的防篡改能力——你没法悄悄改掉一条历史提交，因为改完之后它的编号会变，而后面所有提交都记着它的旧编号，链条立刻断掉，一眼就能看出来。

实际使用中你很少需要完整的四十位，Git 允许用前七到十位来指代一条提交，只要在当前仓库里不产生歧义就行。仓库规模大到一定程度时偶尔会出现短编号撞车，这时候 Git 会提示你多写几位，不是报错，是让你把范围缩小。

3.2 提交历史该怎么读才不迷路

git log的默认输出信息密度很低，翻两屏就晕。我实际工作里基本只用几种组合。第一种是git log --oneline --graph --decorate -20，一行一条提交，带分支和标签的标记，左边用字符画出分叉与合并的形状，最后二十条刚好一屏，用来快速回忆“这个分支最近在干什么”。第二种是git log -p 文件路径，只看某个文件的改动历史，排查“这行代码什么时候被谁改的”特别快，通常配合-S "关键字"使用——-S是按内容搜索，能找出“哪次提交引入了这段文字”，比逐条翻 diff 高效得多。

git log --stat只显示每次提交动了哪些文件、各改了多少行，适合扫一遍改动范围。--author按人过滤，--since和--until按时间过滤，--grep搜提交说明关键词。把--grep和格式规范结合起来用效果最好，前提是你的提交说明写得规范。

还有一个工具，平时不太起眼但关键时刻能救命：git reflog。它记录的是本地 HEAD 的移动轨迹——切分支、提交、重置、变基，每一步都留痕。假设你手滑执行了一次硬重置，把刚写的提交弄丢了，git log里已经看不到了，但reflog里还在。找到那条记录，git reset --hard 那个编号，内容就回来了。这条命令的特殊之处在于它记录的是本地操作，不随推送同步，而且默认只保留一段时间，所以别拿它当长期备份用。

3.3 提交链、分支指针与游离头指针

把历史想象成一条链会更清楚：每条提交都记着它的父提交编号，形成一条向前的单向链，最新的一条在链头，也就是HEAD指向的位置。分支本质上只是一个指向某条提交的可移动指针，main指向哪，哪就是这条分支的最新提交。这里有个很实用的推论：新建分支几乎零成本，因为它只是多了一个指针，而不是复制一份代码。

合并提交比较特殊，它有两个父提交，链在这里分叉又汇合，这也是--graph输出的形状为什么那么值得看。看完图形再理解“为什么合并之后历史线看起来是绕的”就顺了。

还有一种状态叫游离头指针，也就是HEAD不指向任何分支，而是直接指向某条提交。通常出现在你检出某个历史提交去看旧代码的时候。这时候如果你直接提交，新提交不属于任何分支，切走之后很容易“找不到”。真遇到了也别慌，reflog里能找到编号，然后git switch -c 新分支名 那个编号把它接回一条分支上就安全了。我现在检历史代码一律用git switch --detach明确进入游离状态，心里有数，反而不容易出岔子。

4. 多次提交与忽略规则：让历史可读，让噪音消失

4.1 提交粒度怎么定，说明怎么写

提交粒度这件事没有绝对标准，但有个判断原则很好用：一条提交只做一件事，而且这件事单独拿出来也能解释得通。修一个 bug 是一条，加一个功能是一条，重命名一批文件是一条。把“修 bug + 顺手改格式 + 升级依赖”塞进一条，审查的人会很痛苦；反过来，把一次功能改动拆成十几条“改一行”的提交，也同样糟糕，因为没人能从碎片里拼出意图。我一般的做法是，写代码时随便提交都行，收尾时用交互式变基整理成几条干净的提交再推出去，这个习惯能同时兼顾效率和整洁。

说明的写法我推荐一个简单的两段式。标题行控制在五十个字符左右，用动词开头，说清楚“做了什么”，例如“修复空列表导致的分页异常”。空一行之后写正文，重点回答“为什么”——原来的逻辑是什么、问题出在哪里、为什么选这个方案、有没有副作用。不需要复述 diff，diff 自己会说话。真要写规范的话，标题加个类型前缀也很有用，比如区分修复、功能、重构、文档、构建，配合--grep过滤时体验完全不同。

多次提交的另一个价值体现在出问题的时候。假设上线后发现某个功能有问题，如果你的历史是一条巨大的提交，回退就是在拆炸弹——它可能同时包含十个不相干的改动。如果是十条原子的提交，定位到具体哪一条，单独回退，风险小得多。这也是为什么我坚持在合并前整理历史：不是为了好看，是为了出问题时能精准动手。

4.2 忽略规则的写法与优先级

.gitignore用来告诉 Git 哪些文件永远不需要进入版本库，典型对象是编译产物、依赖目录、日志、本地环境配置、编辑器生成的临时文件。语法不复杂但细节不少，我把最容易出错的几条列出来。

有一处特别容易让人困惑：如果父目录已经被忽略，那么再用!去取消其中某个文件的忽略是不生效的，因为 Git 根本不会进入这个目录去看。正确做法是先放行目录本身，再逐层排除，写成先目录/*再!目录/要保留的文件的形式。这个规则我至少跟人解释过七八次，几乎每个项目的新人都会撞上一次。

优先级方面，同一路径在不同文件里出现冲突规则时，越靠近文件的规则越优先：仓库内子目录的.gitignore覆盖根目录的，而通过命令行指定的排除文件优先级最高，通常用来放个人本地的临时规则，不进版本库。全局忽略配置适合放编辑器产生的杂项文件，一次配置好，所有仓库都受益。

4.3 已经被跟踪的文件怎么补救

忽略规则只对尚未被跟踪的文件生效。如果某个文件早就提交过，再把它写进.gitignore也没有任何作用，Git 依然会盯着它。这是新手最常抱怨的“忽略不生效”的真正原因。补救办法是把它从索引里移除但保留磁盘上的实体文件：git rm --cached 文件路径，然后正常提交这次移除。文件还在你本地，只是不再被跟踪。

如果这个文件本来是所有人的共享配置，正确的处理不只是加忽略，还得准备一份模板文件放进仓库，让每个人复制一份再改，并在说明里写清楚这一步。否则队友拉下来发现少了个配置，第一反应是提交到仓库里，一切都白做。

还有一种情况是文件必须留在仓库里，但每个人本地都得改。这时候可以用git update-index --skip-worktree 文件路径让 Git 忽略本地的改动，效果比--assume-unchanged更稳，后者本意是性能优化，遇到上游更新时容易被覆盖。这两个都是本地设置，不随仓库同步，换台机器要重新设一遍——所以更推荐的做法还是把配置拆成“默认值文件 + 本地覆盖文件”，从设计上避免这个问题。

5. 常见问题与排查实录

5.1 提交相关问题速查

下面这张表是我这几年被问得最多的一批问题，按现象归类，配上判断依据和处理方向。

5.2 stash 的几个高频坑

第一个坑是藏了不该藏的东西。默认不包含未跟踪文件，所以新建文件常常被落下，切分支时它还在原地。养成加-u的习惯，能省掉很多“怎么这个文件跟着过来了”的疑惑。

第二个坑是把 stash 当备份。stash的定位是“临时放一下”，不是长期存储。有人攒了十几条 stash 从来不清理，过两个月完全不知道哪条对应什么。我的建议是，stash 当天产生当天处理掉，实在要留就写清楚说明，并在当天的工作记录里记一笔。

第三个坑是恢复时冲突处理不当。apply之后如果出现冲突，Git 会把冲突标记写进文件，但改动本身已经合进来了。这时候不要急着drop那条 stash，先把冲突解决、测试跑通，再回头清理。我见过有人一看到冲突就reset --hard，结果把 stash 里还没落地的内容也一起丢了。

第四个坑跟跨分支恢复有关。stash 的恢复不限制分支，你可以把在 A 分支藏起来的内容恢复到 B 分支。这既是能力也是风险，因为代码可能依赖分支特有的上下文。恢复前确认一下你要落在哪个分支，别顺手pop到错的地方。

5.3 我自己的几条固化习惯

几个习惯坚持下来之后，提交这块基本就不太出问题了。第一，动手前先看 status，哪怕只是改一行，这条命令的成本几乎为零，收益却实打实。第二，提交前用 diff --cached 过一眼，确认内容跟你想的一致，特别是用add .的时候，这一步能抓住绝大多数误加。第三，说明里写动机不写动作，动作 diff 里都有，动机只有你脑子里有。第四，推送前看一眼 log，确认没有半成品提交、没有奇怪的合并、说明没有拼写错误。第五，stash 一律配说明并当天清理，不给未来的自己留麻烦。

再补充一个关于散列值的小技巧。日常你根本不需要记完整的四十位，但要记住它可以被你自由使用在几乎所有命令里：git show 编号看内容，git checkout 编号 -- 文件取回某个历史版本的文件，git diff 编号1 编号2对比两次提交。把编号当成“历史里的坐标”来用，很多原本觉得复杂的操作会一下子变得直观——你要做的只是找到那个坐标，然后告诉 Git 从哪里取东西。

最后分享一个我自己踩过的坑。有段时间我养成了一有改动就commit --amend的习惯，觉得提交记录特别干净。直到有一次在共享分支上这么干，队友拉取后出现了莫名其妙的分叉，花了不少时间才理清楚。后来我给自己定了一条硬规则：凡是已经推送出去的提交，只新增不修改，历史整洁的重要性永远排在协作安全之后。这条规则执行到现在，类似的麻烦再没出现过。