4.9 KiB
Git commit
git add / git commit / git diff / git stash / .gitignore
✍️ 童仲毅 | ⏳ 2018 年 12 月 5 日（上游未更新，根据旧版教程审校）
©️ 本文演绎自 Atlassian 编写的 Saving Changes。页面上所有内容采用知识共享-署名（CC BY 2.5 AU）许可协议。
git commit
git commit 命令将缓存的快照提交到项目历史。提交的快照可以认为是项目安全的版本，Git 永远不会改变它们，除非你这么要求。和 git add 一样，这是最重要的 Git 命令之一。
尽管和它和 svn commit 名字一样，但实际上它们毫无关联。快照被提交到本地仓库，不会和其他 Git 仓库有任何交互。
工作原理
快照总是提交到 本地 仓库。这一点和 SVN 截然不同，后者的工作拷贝提交到中央仓库。而 Git 不会强制你和中央仓库进行交互，直到你准备好了。就像缓存区是工作目录和项目历史之间的缓冲地带，每个开发者的本地仓库是他们贡献的代码和中央仓库之间的缓冲地带。
这一点改变了 Git 用户基本的开发模型。Git 开发者可以在本地仓库中积累一些提交，而不是一发生更改就直接提交到中央仓库。这对于 SVN 风格的协作有着诸多优点：更容易将功能切分成原子性的提交，让相关的提交组合在一起，发布到中央仓库之前整理好本地的历史。开发者得以在一个隔离的环境中工作，直到他们方便的时候再整合代码。
记录快照，而不是记录差异
SVN 和 Git 除了使用上存在巨大差异，它们底层的实现同样遵循截然不同的设计哲学。SVN 追踪文件的 变化 ，而 Git 的版本控制模型基于 快照 。比如说，一个 SVN 提交由仓库中原文件相比的差异（diff）组成。而 Git 在每次提交中记录文件的 完整内容 。
这让很多 Git 操作比 SVN 来的快得多，因为文件的某个版本不需要通过版本间的差异组装得到——每个文件完整的修改能立刻从 Git 的内部数据库中得到。
Git 的快照模型对它版本控制模型的方方面面都有着深远的影响，从分支到合并工具，再到协作工作流，以至于影响了所有特性。
用法
git commit
提交已经缓存的快照。它会运行文本编辑器，等待你输入提交信息。当你输入信息之后，保存文件，关闭编辑器，创建实际的提交。
git commit -m "<message>"
提交已经缓存的快照。但将 <message> 作为提交信息，而不是运行文本编辑器。
git commit -a
提交一份包含工作目录所有更改的快照。它只包含跟踪过的文件的更改（那些之前已经通过 git add 添加过的文件）。
栗子
下面这个栗子假设你编辑了 hello.py 文件的一些内容，并且准备好将它提交到项目历史。首先，你需要用 git add 缓存文件，然后提交缓存的快照。
git add hello.py
git commit
它会打开一个文件编辑器（可以通过 git config 设置) 询问提交信息，同时列出将被提交的文件。
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
Git 对提交信息没有特定的格式限制，但约定俗成的格式是：在第一行用 50 个以内的字符总结这个提交，留一空行，然后详细阐述具体的更改。比如：
Change the message displayed by hello.py
- Update the sayHello() function to output the user's name
- Change the sayGoodbye() function to a friendlier message
注意，很多开发者倾向于在提交信息中使用一般现在时态。这样看起来更像是对仓库进行的操作，让很多改写历史的操作更加符合直觉。
这篇文章是「git-recipes」的一部分，点击 目录 查看所有章节。
如果你觉得文章对你有帮助，欢迎点击右上角的 Star 🌟 或 Fork 🍴。
如果你发现了错误，或是想要加入协作，请参阅 Wiki 协作说明。