1. 命令概述

git commit 命令用于将暂存区（Staging Area） 的内容快照保存到本地版本库（Repository） 中。
可以把它理解为：

• 拍照：git add 命令是把文件改动“摆好姿势，放进取景框”（放入暂存区）。
• 按下快门：git commit 命令则是“按下快门”，生成一张永久的快照（提交）。
• 相册：版本库就是你的相册，保存了所有快照（提交历史）。

每次提交都会生成一个唯一的 SHA-1 哈希值（如 a1b2c3d...）作为 ID，并记录提交者、时间、提交说明等信息。

2. 命令格式

基本的命令格式如下：

git commit [<选项>] [--] [<路径规格>...]

• [<选项>]：用于修改命令行为的各种标志，如 -m, -a, --amend 等。
• [--]：可选的分隔符，用于明确区分选项和文件路径。
• [<路径规格>...]：可选的文件路径，用于指定只提交部分文件的更改（需要与特定选项配合使用）。

3. 基本用法

3.1 启动编辑器进行提交

这是最标准的方式，会让你在默认的文本编辑器（如 Vim, VSCode, Nano）中编写提交信息。

git commit

执行后，Git 会打开编辑器，你需要在其中编写提交信息。第一行是主题，空一行后是详细描述。保存并关闭编辑器后，提交完成。

3.2 直接在命令行中提交（-m 选项）

对于简单的提交，可以直接在命令行中提供提交信息，避免打开编辑器。

git commit -m "提交的信息 -m "提交的详细描述（可选）"

使用两个 -m 参数可以分别对应主题和正文。如果只用一个，则全部内容都会作为提交主题

3.3 自动暂存所有已跟踪文件的更改并提交（-a 选项）

这个选项可以跳过 git add 步骤，直接将所有已跟踪文件的修改和删除操作提交。它不会提交未跟踪的新文件。

git commit -a -m "修复了一个紧急的bug"

这等价于：

git add -u  # 暂存所有已跟踪文件的更新和删除
git commit -m "修复了一个紧急的bug"

4. 高级用法

4.1 修改上一次提交（–amend）

这是一个非常有用的命令，主要用于以下三种情况：

• 修改提交信息：只是改一下上条提交的 message。

git commit --amend -m "新的、更清晰的提交信息"

• 补充遗漏的文件：上次提交忘记把某个文件 add 进去了。

git add 遗漏的文件.txt
git commit --amend --no-edit  # --no-edit 表示不修改提交信息

• 合并到上一次提交：你刚做了一个小提交，但觉得它应该合并到上一个提交中，让历史更清晰。

# 假设你刚刚做了一次提交 C
# 你又做了一点小修改
git add .
git commit --amend

注意：--amend 不是修改了原提交，而是生成了一个全新的提交并替换掉旧的。如果旧提交已经推送到远程仓库，强制推送 (git push --force-with-lease) 可能会给协作者带来问题。

4.2 提交时跳过钩子（–no-verify）

如果你的项目设置了 Git Hooks（如 pre-commit 用于代码检查），但本次提交想临时跳过它们，可以使用此选项。

git commit --no-verify -m "临时提交，跳过代码检查"

慎用，这可能会引入未通过检查的代码。

4.3 空提交（–allow-empty）

创建一个不包含任何文件改动的提交。这在某些场景下有用，例如为了触发 CI/CD 流程。

git commit --allow-empty -m "触发CI构建"

4.4 指定作者信息（–author）

以其他作者的身份进行提交（例如在其他人的服务器上提交代码时）

git commit -m "修复问题" --author="John Doe <john@example.com>"

5. 注意事项

5.1 提交信息的重要性

• 第一行（主题）：应简洁（建议50字符以内），概括本次提交的目的。使用祈使句，如 “Fix bug” 而非 “Fixed bug”。
• 正文（可选）：解释为什么要这么修改，而不是怎么修改（代码本身能说明怎么修改）。如果修改复杂，务必在此说明。
• 好的范例：

优化用户登录性能

- 使用 Redis 缓存用户会话，减少数据库查询
- 将密码验证算法从 MD5 迁移至 bcrypt
- 修复了在并发登录时可能出现的竞态条件

5.2 原子性提交

• 一次提交只做一件事。例如，修复一个 bug 和重构一个函数应该分成两次提交。这便于回滚、代码审查和 git bisect 调试。

5.3 --amend 的风险

• 绝对不要修改已经推送到公共仓库（如 GitHub, GitLab）且可能被他人拉取过的提交。这相当于重写历史，会导致协作者的仓库历史混乱。

5.4 什么应该被提交

• 只提交源代码和必要的项目文件
• 不要提交:
  • 编译生成的二进制文件（如 .class, .jar, .exe）
  • 依赖目录（如 node_modules/）。
  • 本地配置文件（包含密码、密钥的文件）。
  • 操作系统生成的临时文件（如 .DS_Store, Thumbs.db）。
  • 使用 .gitignore 文件来过滤这些不该提交的文件。

6.补充信息

6.1 提交信息模板

可以设置一个提交信息模板，规范团队成员的提交信息格式。
1.创建一个模板文件，如 ~/.gitmessage.txt：

[主题] 一行简单的描述（<50字符）

[正文] 详细描述本次修改的内容和原因：

* 
* 

[关联事项] Closes #123

2.配置 Git 使用该模板：

git config --global commit.template ~/.gitmessage.txt

之后执行 git commit 时，编辑器就会预加载这个模板。

6.2 查看提交记录

提交后，使用 git log 查看提交历史。

• git log --oneline：以简洁的单行模式查看。
• git log -p：查看每次提交的具体代码差异。
• git show <commit_hash>：查看某次提交的详细信息。