Git add -p：暂存特定行并进行集中提交

要仅提交文件的一部分，请使用 `git add -p -- path/to/file` 暂存所需的更改，使用 `git diff --cached` 进行审核，然后提交。 其余编辑保留在您的工作文件中。在 GitTree 中，打开文件 diff，选择更改的行，然后选择 Stage Lines 以准备相同类型的集中提交。

假设您修复了结账验证错误，然后开始重新组织同一组件。审阅者应该能够在不阅读未完成的重构的情况下理解错误修复。本指南在这些更改成为历史之前将其分开。该动画示例使用 GitTree，即我们为 macOS、Windows 和 Linux 制作的客户端。部分分期属于免费计划；当前的官方版本需要登录。

工作树、暂存区和提交：保存什么？

暂存是一个选择步骤，不是提交，也不是推送。文件可以部分暂存：索引保存一个版本，而编辑器显示所有编辑。如果您在暂存后再次编辑，暂存版本不会静默更新。提交之前再检查一遍。 可视化提交图有助于检查提交存在后的历史记录。

如何在一个文件上使用 git add -p

从 git status 开始并检查已上演的所有内容。补丁模式将选定的更改添加到现有索引；它不会删除之前的选择。在此示例中，将 src/checkout.ts 替换为您跟踪的文本文件，然后在 Git 询问每个块时仅接受验证修复。

git status
git diff --cached
git diff -- src/checkout.ts
git add -p -- src/checkout.ts
git diff --cached
git diff -- src/checkout.ts
git commit -m "fix: validate checkout input"

仅在检查分阶段差异并测试预期更改后才运行最终提交。 git diff --cached 显示提交将记录的内容； plain git diff 显示未提交的内容。请勿在此工作流程中使用 git commit -a 或向 git commit 提供文件路径：这些表单可能会绕过您刚刚准备的部分选择。

当修复和重构紧密结合时，拆分大块

块是附近带有上下文的已更改行的块。补丁模式可以将修复和重构组合在一起。使用 s 要求 Git 分割块。如果编辑无法自动分隔，则 e 打开补丁编辑器，或者可视线选择器可以帮助您选择预期的添加和删除。

对于替换，请将已删除的行及其替换视为一个逻辑更改。仅选择一半可能会生成您在编辑器中从未见过的代码。高级补丁编辑可选；如果您无法解释暂存的结果，请取消暂存并选择更清晰的边界。集中的提交需要独立发挥作用，而不仅仅是小规模的提交。

下载 GitTree 以直观地查看混合差异并构建重点提交。您可以在终端旁边的现有存储库上使用它；两者都读取相同的 Git 暂存区。

取消暂存更改而不放弃您的编辑

git restore --staged -- src/checkout.ts
# Or choose which staged blocks to remove:
git restore --staged -p -- src/checkout.ts

这些是替代命令。使用 --staged，恢复会更改索引而不是您的工作文件。对于具有提交的存储库，它通常会将暂存内容重置为 HEAD。如果没有 --staged，恢复可能会覆盖正在进行的编辑，因此请保持清晰的区别。当您只想更改下一次提交包含的内容时，在 GitTree 中选择 Unstage，而不是 Discard。

为什么一个文件出现两次，或者一行无法暂存

暂存文件和未暂存文件下的文件通常意味着部分暂存或稍后编辑，而不是重复文件。新的、未跟踪的文本文件可能需要 git add -N -- path/to/new-file，修补模式才能提供其内容。二进制文件没有普通的文本块； GitTree 还将重命名、LFS 指针和子模块更改作为整个文件操作进行阶段。如果隐藏了空白，请在选择仅空白更改之前显示它。

如果编辑器或格式化程序在您打开其差异后更改了文件，则 GitTree 可能会拒绝过时的行选择。刷新 diff 并再次选择。避免仅仅为了达到更小的行数而分割紧密耦合的更改。对于任务中断，隐藏未完成的工作；对于已经提交的混合历史记录，请查看交互式变基指南。

测试您正在准备的提交，而不仅仅是编辑器的文件

您的正常测试命令针对工作文件运行，其中仍然包括未暂存的编辑。通过那里的测试并不能证明部分提交已完成。对于重要的拆分，进行第一次本地提交，然后在单独的干净签出或工作树中检查和测试已提交的快照。如果在共享分支之前失败，请添加缺少的依赖项。 worktree 指南 解释了单独的文件夹如何帮助将这些版本分开。