Git add -p：让提交更精准的利器
Staging patches with Git add -p
如果你还没在提交代码时使用 git add -p，那你可能错过了提升工作流效率的关键一步。这个功能让我能在提交前逐块审查代码，及时发现拼写错误或逻辑漏洞。更重要的是，它能让我只提交文件中的部分修改，而不是整个文件。比如，当我在一个文件中同时添加了 div 和 avg 函数，却只想先提交 div 时，git add -p 让我轻松拆分并提交单个 hunk。这种精细控制不仅让每次提交更清晰，也让代码历史更易追溯。我几乎每天提交时都会用到它，除非是首次提交新文件或确定整个目录内容无误时。
通过交互式地审查并提交代码，我能在提交前发现许多在编码或内容创建过程中可能遗漏的错误。
HN 评论区
17- chriswarbo
如果你还没用 git add -p 来暂存提交，那你可就亏大了。
不过自从切换到 jujutsu 后，我向你保证，我完全不怀念这个功能。
jj 采取了截然相反的思路：它一直暂存所有改动，当你需要拆分时再使用 split 命令。
（是的，它把暂存的改动存为修订版本，所以你随时可以回退到之前的暂存状态）。
- BeetleB
Magit 支持选择性暂存/取消暂存，既可以按代码块（hunks），也可以按选中的行（即 Emacs 的“区域”）。除非是暂存整个文件，否则我尽量避免在 git 命令行里操作。
附注：Majutsu 也提供这个功能（它是 jj 的类 magit 工具）。
- natbennett
我觉得 `add -p` 最大的问题在于，很难修正那些误加或误拒的补丁。我经常跳过几十个不想暂存的内容，结果发现最后一个代码块其实是需要的。但我没法回头再处理它，只能从头再来，还得格外小心别再跳过它。
我真希望 j 和 k 快捷键能让我重新访问那些已经暂存或拒绝的代码块，而不仅仅是那些还没审查过的。面对一大堆不想暂存的未暂存改动时，在代码块列表中“迷失位置”真的非常糟糕。