掌握Git暂存与提交：你的第一次变更

掌握Git暂存与提交的基础知识是自信使用Git的第一步。暂存让你精确选择下一次快照包含的内容，而提交则用一条未来读者能理解的信息记录该快照。

如果你将每次提交视为一个小的、可审查的工作单元，Git会变得更容易使用。你可以检查变更、拆分无关的编辑，并在出错时从容恢复。

暂存区如何工作

Git不会自动提交你编辑的每个文件。它将你的工作分为工作树、暂存区和已提交历史。

工作树是你的项目文件夹。这些是你在编辑器中编辑的文件。

暂存区是Git为下一次提交准备的清单。当你运行git add时，你还没有保存历史。你只是在为下一次提交选择变更。

仓库历史是已记录的提交序列。

首先检查状态：

git status

Git会显示未跟踪的文件、已修改的文件、暂存的变更以及当前分支。这个命令随时可以安全运行，应该成为习惯。

要暂存一个新文件或已修改的文件：

git add README.md

要暂存当前目录下的所有变更：

git add .

这个命令很方便，但要谨慎使用。如果.gitignore不完整，它可能会暂存无关的文件、本地配置或生成的文件。

为了更安全的审查，先检查差异：

git diff

然后只暂存属于同一组的变更：

git add src/app.js
git add README.md

暂存后，检查将要提交的内容：

git diff --staged

这会显示确切的暂存快照。如果有什么看起来不对，在提交前修复它。

一旦正确的变更被暂存，创建一个提交：

git commit -m "添加项目README"

信息应该描述变更，而不是你采取的行动。"添加项目README"比"变更"或"更新文件"更有用。

一个好的提交通常有一个明确的目的。例如，假设你更新了一个部署脚本，同时修复了文档页面中的一个拼写错误。这些是独立的变更。分别暂存并提交它们：

git add scripts/deploy.sh
git commit -m "添加部署健康检查"

git add docs/setup.md
git commit -m "修复设置指南中的拼写错误"

这使得审查更容易。如果部署变更导致问题而文档修复没问题，回滚也更简单。

如果你运行git commit而不带-m，Git会打开你的编辑器。当你需要更长的信息时，这很有用：

添加部署健康检查

在标记部署完成前验证服务端点。
这有助于在发布过程中更早地捕获失败的启动。

第一行应该简短直接。正文可以解释为什么需要这个变更或提及权衡。

查看最近的提交：

git log --oneline -5

这会给你一个紧凑的最新历史视图。

有时一个文件包含多个无关的编辑。Git可以通过补丁模式暂存文件的一部分：

git add -p src/config.js

Git会显示每个变更块并询问你要做什么。常见的选择是：

补丁暂存在你提交前清理时很有用。例如，你可能有一个文件，你添加了一个新的超时设置，还重新格式化了一条注释。将超时变更暂存为一个提交，然后将注释清理暂存为另一个提交。

如果你错误地暂存了某些内容，在不丢弃工作的情况下取消暂存：

git restore --staged src/config.js

你的文件在工作树中保持修改状态。它只是从暂存区中移除。

如果你想丢弃文件中未暂存的变更，请小心：

git restore src/config.js

该命令会丢弃该文件中的本地编辑。先运行git diff，这样你知道会丢失什么。

更多恢复模式，请参阅如何撤销Git错误。

小而专注的提交更容易审查、测试和回滚。它们也使git bisect等工具在需要找到错误起源时更有用。

养成这些习惯：

一个实用的工作流程可能如下：

git status
git diff
git add src/server.js
git diff --staged
git commit -m "处理缺失的健康检查响应"
git status

这个序列并不花哨，但能捕获大多数初学者的错误。你知道什么变更了，什么被暂存了，什么被提交了，以及什么仍然存在。

如果你的团队使用预提交钩子或自动格式化，提交可能会失败，直到你修复格式或测试。阅读错误信息，运行建议的命令，暂存结果变更，然后再次提交。

如果你意外暂存或提交了机密，提交到了错误的分支，或者不确定是应该修改、回退、重置还是创建新提交，请寻求帮助。这些选择有不同的效果，尤其是在推送之后。

你还应该在重写其他人可能已经拉取的提交之前询问。一个简单的本地清理如果改变了共享历史，可能会变成团队问题。

暂存和提交是Git的核心循环。检查你的变更，有意图地暂存，以专注的片段提交，并编写一个月后仍有意义的信息。