谢邀。
这个问题我带的实习生几乎人手问一遍，有些工作三五年的老同事，虽然天天用，但你要是冷不丁问他，他可能也得愣一下，然后憋出一句“规定就是这样呗”。
这问题，问得是真好。它一针见血地戳到了Git设计的核心灵魂。你以为这是个操作问题，其实这是个哲学问题。
今天我就豁出去了，把压箱底的经验和思考都掏出来，争取用人话把这事儿给你讲透。这篇回答可能有点长，信息量也大，但我保证，你耐心看完，不仅能彻底明白为啥要先add再commit，你对整个软件开发的理解，可能都会上一个台阶。觉得有收获，别忘了回来给我点个赞，就是对我码这么多字最大的鼓励。
咱们先不聊技术，聊聊手艺活。你想象一个顶级的木匠，他要做一把椅子。他的工作台（Working Directory）上乱七-八糟，有刨子、凿子、锯子，还有一堆刚锯下来还带着毛刺的木料，甚至还有他喝了一半的茶杯和啃了一半的苹果。
现在，他要把椅子的四条腿组装起来，这是他这一个阶段的工作成果。他会怎么做？
他会把整个工作台上的所有东西，包括那个啃了一半的苹果，一股脑全粘起来，然后说“椅腿阶段完工”吗？
肯定不会。
他会精心地从一堆木料里，挑选出那四根已经打磨好、尺寸分毫不差、榫卯结构都凿好的椅腿，把它们拿到一个干净的“待组装区”（Staging Area），仔细摆好，确认没问题了，然后用胶水和楔子把它们牢牢地固定在一起，形成一个稳定、可靠的部件。这个“固定”的动作，就是commit。
你看，git add这个命令，就是那个“挑选”的动作。它让你有机会在“乱七八糟的工作台”和“最终固定的成品”之间，建立一个“待组装区”。
这个区域，就是Git的精髓所在：暂存区（Staging Area，或者叫Index）。
理解了暂存区，你就理解了Git的半壁江山。
很多从SVN或者更古老的版本控制工具转过来的同学，最不适应的就是这个暂存区。他们会觉得，我改了东西，不就是为了提交吗？为什么还要多此一举add一下？svn commit一把梭哈多爽。
爽是爽，但那是“莽夫”的爽。等你项目复杂了，代码review的时候，或者半夜三更需要回滚代码、定位bug的时候，你才会发现，当初的“爽”，现在都变成了要命的“坑”。
Git的作者，Linus Torvalds，他设计Git的初衷是为了管理极其复杂的Linux内核项目。那是什么体量？成千上万的开发者，每天成千上万的修改。如果提交记录是一团乱麻，这个项目早就崩了。
所以，Git从根儿上就建立在一个核心思想上：你的每一次提交（commit），都应该是一个逻辑上完整、独立的“原子单元”。
什么叫“原子单元”？
这些都是“原子”的。而“修复了一个bug的同时，顺手改了另一个模块的变量名，还加了一段没写完的测试代码”，这就不是“原子”的，这是“一锅乱炖”。
一锅乱炖的commit，会带来灾难性的后果：
所以，为了实现“原子提交”这个目标，Git必须提供一个机制，让你在正式提交前，能够对你所有的改动进行一次“检阅”和“编排”。
这个机制，就是git add和它背后的暂存区。
你的工作区（Working Directory）是你自由发挥的地方，你可以天马行空，写各种调试代码（比如到处console.log或者print），写一半的功能，做各种实验。这是你的草稿纸，没人管你。
当你觉得某一部分工作完成了，比如那个bug修好了，你想把它记录到历史里去。你就要执行git add。
git add的本质，是把工作区里指定文件的“当前快照”或者“部分快-照”放入暂存区。
暂存区就像一个购物车，你逛超市（在工作区写代码），看到需要的、确认要买的东西（写好的、测试通过的代码），就把它add到购物车里。你可以多次add，把修复bug的A文件add进去，把相关的B文件的修改也add进去。你甚至可以用一个神级命令git add -p（--patch的缩写），把同一个文件里的不同修改，一块一块地（hunk by hunk）选择性地add进去。
讲到这，我必须给你举个我亲身经历的，教科书般的例子。
场景案例一：修复Bug与代码重构的分离
有一次我接手一个陈年老项目，要去修复一个数据处理的bug。这个bug在一个长达2000行的函数process_data里。我花了半天时间，终于在1500行左右找到了问题，改了3行代码，bug修复了。
但是在看这2000行代码的过程中，我简直是忍无可忍。命名不规范，逻辑混乱，各种魔法数字。我这个人有点代码洁癖，顺手就把这个函数里的一些变量名给重构了，把一些重复的逻辑抽成了几个小函数。
好了，现在我的git status会显示user_model.py这个文件被修改了。如果我直接git add user_model.py然后git commit -m "Fix data processing bug"，会发生什么？
我的同事在Code Review的时候，打开这个commit，会看到一个巨大的diff，里面混着3行真正的bug修复，和上百行的代码重构。他会疯掉的。他会问我：“哥们，你到底哪几行是修bug的？你改这么多，万一引入新bug怎么办？”
这时候，一个专业的工程师会这么做：
看到没有？通过git add -p和暂存区，我把一次混杂的修改，拆分成了两个逻辑清晰、目的单一的原子提交。我的提交历史变得像一本清晰的账簿，而不是一团浆糊。我的同事给我点了个赞，项目的可维护性也因此提高了。
这就是git add的威力。它不是一个多余的步骤，它是你“导演”你的提交历史的指挥棒。
如果你对git add -p还不熟悉，我强烈建议你现在就去试一试。这是区分Git新手和老手的一个重要分水岭。想深入了解这类Git高级技巧，官方的《Pro Git》第二版是永远的神，而且网上有免费的中文版。别去看那些东拼西凑的博客了，直接啃原版，这比啥都强。这本书我司新人入职人手一本，不是开玩笑的。
其实市面上很多教程非常繁杂，动辄几十个小时，为了大家快速入门，我这里总结了一套Git初学者操作手册，以一线大厂的工业实战实操标准为例，结合了大厂协作流程和真实事故案例写成。
这套方法，覆盖一个开发者在公司里 90% 以上的 Git 操作场景。里面不光有命令大全，更重要的是，把这些命令串起来，告诉你什么场景下该用什么组合拳。比官方文档好懂，比碎片化的博客系统更高效。为了方便大家下载学习，所有操作都汇集成册。按需下载：Git零基础实战手册.pdf（点击免费自取）
不求你成为 Git 布道师，只求你在公司里游刃有余，不坑队友，还能在关键时刻秀一把操作，解决别人解决不了的问题。
这个问题问得更深了。你是在问，为什么暂存区不是“持久化”的？为什么我add了一个文件后，再修改它，还需要重新add一次？Git为啥这么“不智能”？
我们还是回到那个木匠的例子。
木匠把打磨好的椅腿A放到了“待组装区”。这时候，他发现椅腿A的榫头稍微有点紧，他又拿回工作台，用凿子修了一下。
现在，工作台上的椅腿A，和待组装区里“记忆中”的那个椅腿A，已经不是同一个版本了。
如果Git“智能地”认为，只要add过一次，后续的修改就自动包含在内，会发生什么？
木匠以为他要组装的是“修复了榫头”的完美椅腿，但实际上，如果commit直接使用了“待组装区”里那个旧的、有瑕疵的版本快照，那他组装上去的还是那个有问题的椅腿。
如果commit“智能地”去追踪工作区里所有add过的文件，然后把它们的最新版本都提交了，那又回到了我们前面说的“一锅乱炖”的问题。我在add了修复bug的代码之后，可能又在同一个文件里加了一些print调试语句，我显然不希望这些print被提交。
所以，Git的设计是这样的：
git add命令，是把你执行该命令的那个瞬间，工作区里指定文件的内容快照，覆盖到暂存区。
git commit命令，是把执行该命令的那个瞬间，暂存区里的全部内容，生成一个新的提交记录。
这两个动作都是“瞬时”的，而不是“持续追踪”的。
这种设计，保证了极高的确定性和可控性。
你每一次commit，提交的到底是什么东西，唯一取决于你commit之前，暂存区里的内容是什么。这个“篮子”里的东西是确定的，不会因为你工作区里又改了什么而动态变化。
这给了你极大的安全感。你知道，只要你不执行git add，你在工作区里 怎么折腾，都不会污染你下一次的提交。
这在一些紧急和复杂的场景下，简直是救命稻草。
场景案例二：紧急线上Hotfix
想象一下这个场景：你正在一个叫feature/new-recommend-algo的复杂功能分支上开发，吭哧吭哧写了一下午，改了七八个文件，代码还处于半成品状态，各种依赖和逻辑还没理顺，肯定不能提交。
突然，产品经理火急火燎地跑过来，或者你大半夜被oncall电话叫起来，说线上的一个支付接口挂了，十万火急，需要立刻修复！
这时候，一个专业的工程师会怎么做？
整个过程行云流水，干净利落。
现在我们来反向思考一下，如果Git是按你说的，“默认之前被add的文件一定继续被加入”，这个流程会变成什么样？
你根本没有git stash这个选项，因为你的修改“自动”就和分支绑定了。你为了修复那个hotfix，要么就得在你那堆半成品代码里直接改，然后想办法只提交那五行代码（这几乎不可能），要么就得手动把你的半成品修改一个个备份到别的地方，等修复完再一个个拷回来。无论哪种，都是一场灾难。
git add和暂存区的存在，本质上是解耦了“开发过程”和“提交历史”。你的工作区是凌乱的、动态的、属于“过程”的；而你的提交历史，通过暂存区的筛选和编排，应该是清晰的、稳定的、属于“结果”的。
聊到这里，我们其实已经超出了“为什么要git add”这个具体问题的范围。
我想表达的是，Git不仅仅是一个代码备份工具，或者一个多人协作的同步工具。它是一种工作流，一种思维方式，甚至可以说是一种工程哲学。
我作为数据科学家，这个感触尤其深。我的工作区里经常一团糟：
当我一个实验成功了，比如我发现某个模型架构和某组超参数的组合效果最好。我需要把这次“成功”记录下来。
我绝对不会把整个文件夹git commit -a -m "It works!"。
我会这么做：
我的commit信息会写得非常具体，说明我做了什么，达到了什么效果。这样，三个月后我自己回来看，或者同事接手我的项目，能立刻明白这个commit的价值。
Git通过add这个动作，强迫我停下来思考：
这个“停顿”和“思考”，是宝贵的。它让你从一个代码的“搬运工”，向一个软件的“工程师”转变。你的关注点，从“我写了什么代码”，提升到了“我如何构建一个清晰、健壮、可维护的软件历史”。
所以，别再抱怨git add麻烦了。当你开始享受git add -p带给你的那种对代码的极致掌控感时，当你开始为你自己维护的清爽、优雅的提交历史而感到自豪时，恭喜你，你已经真正掌握了Git的精髓，也向一个更资深的工程师迈出了一大步。
总结一下吧，其实就几句话：
一个工具的设计，往往反映了其创造者对某个领域问题的深刻理解。去理解Git为什么要这么设计，比单纯记住它的命令要重要得多。当你理解了add和commit分离背后的哲学，你会发现这非但不繁琐，反而是一种优雅和智慧。
它在用一种温和而坚定的方式，逼着我们养成良好的工程习惯。
这，就是Git的魅力。
