提交变更

通过 git add 命令，我们将文件的修改放入了暂存区。但这还不够，此时的修改只是“准备被记录”。为了让这些修改真正成为项目历史的一部分，我们需要执行 Git 最核心的操作——提交。

git commit 命令会将暂存区的内容永久保存到 Git 的版本库中，生成一个新的“快照”。每一个快照都是项目历史的一个节点，你可以随时回到任何一个节点查看代码。

1. 基本提交方式

最标准的提交方式是使用 -m 参数，后跟提交说明。这会让 Git 记录下本次变更的简短描述。

命令格式：

git commit -m "提交说明信息"

操作示例：

假设我们已经将 README.md 添加到了暂存区，现在提交它：

git commit -m "初始化项目：添加README文件"

执行成功后，终端会输出类似以下信息：

[master (root-commit) a1b2c3d] 初始化项目：添加README文件 1 file changed, 1 insertion(+) create mode 100644 README.md

这表示你成功创建了一个新的提交，提交ID是 a1b2c3d（SHA-1哈希值的简写），并修改了 1 个文件。

2. 为什么提交说明很重要？

提交说明不仅仅是备注，它是项目的“更新日志”。一个清晰的提交说明能让你（或队友）在几个月后快速了解这次改动的原因。

好的提交说明规范：

• 使用祈使句：例如用“添加功能”而不是“添加了功能”。Git 官方推荐这种风格，像是在给 Git 下达命令。
• 简明扼要：通常不超过 50 个字符。
• 说明“做了什么”和“为什么”：
• • ❌ 反面案例：update、fix bug、修改代码（这种说明毫无意义，无法让人知道改了什么）。
• • ✅ 正面案例：修复用户登录页面无法跳转的Bug、添加用户头像上传接口。

3. 跳过暂存区直接提交

你是否觉得每次都要先 git add 再 git commit 有点繁琐？对于已经跟踪的文件，Git 提供了一个快捷方式。

使用 -a 参数，Git 会自动将所有已跟踪文件的修改添加到暂存区并提交，省去了手动 git add 的步骤。

命令格式：

git commit -am "提交说明"

示例：

假设你修改了 index.js 和 style.css（这两个文件之前已经被提交过）：

git commit -am "重构首页样式与逻辑"

注意陷阱： -a 参数不会处理新创建的文件。对于项目中的新文件，你依然必须先使用 git add 命令将其纳入跟踪。

4. 修改上次提交

有时候，我们刚提交完，发现漏掉了一个文件，或者提交说明里写错了字。这时不想产生一个新的提交记录，而是想修正刚刚那个提交。

使用 --amend 参数可以重写最后一次提交：

场景一：修改提交说明

git commit --amend -m "新的正确的提交说明"

场景二：漏掉了文件

# 1. 先把漏掉的文件加入暂存区
git add forgotten_file.js

# 2. 修正提交（会保留上一次的提交说明，也可修改）
git commit --amend --no-edit

警告：--amend 会改变历史记录。如果你已经将代码推送到远程服务器共享给了其他人，千万不要使用 --amend，否则会导致历史冲突。

5. 小结：提交是“原子”操作

在 Git 的设计哲学中，每一次提交都应该是一个原子单元。这意味着：

1. 完整性：每一次提交都代表了项目的一个完整状态。检出任意一个提交，项目都应该是可运行的（或者能正常编译的）。
2. 独立性：每一个提交只做一件事。不要在一个提交里混杂“修复Bug”和“添加新功能”，这会让后续的代码审查和回滚变得困难。

标准工作流回顾：

修改文件。 git status 查看变更。 git add <file> 暂存变更。 git commit -m "message" 提交快照。