移至正确的项目
如果你一直跟着操作，那么现在你的计算机中，应该在两个目录下有 git 项目：
new-git-project - 使用git init转换为 git 仓库的空目录
course-git-blog-project - 使用 git clone获得的现有博客项目
为了避免与已有的 commit 产生混淆，我们将向 new-git-project 仓库提交 commit。
在终端上，确保使用 cd命令转到 new-git-project 目录中。如果你没有 new-git-project 目录，现在创建一个。位于该目录中后，运行 git init 命令。如果你之前已经运行了 git init，没关系。多次运行git init不会导致任何问题，因为它只是重新初始化 Git 目录。
你的终端应该如下图所示：
状态！状态！状态！
我已经多次提到，但是还是要提下，git status 命令在这节课将非常有用。你应该在任何一个其他 git 命令之前和之后运行 git status 命令。
我们立即运行该命令吧！
git status 输出总结
以下是输出：
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)
注意最后一行 – nothing to commit (create/copy files and use "git add" to track)。注意到它推荐使用的 git add 命令了吗？这很有帮助！git status 的输出结果将给出下一步应该怎么做的建议或提示。
我们根据反馈的建议操作，并创建一些文件。
创建 HTML 文件
首先，创建一个叫做 index.html 的文件，并添加一些起始代码：
Blog Project
注意，代码引用了 CSS 文件和 JavaScript 文件。
现在创建这些 CSS 和 JavaScript 文件。你可以让这两个文件留空。稍后我们将向文件中添加内容。
快速检查 git 状态
我们刚刚通过添加了文件和内容对仓库进行了几个更改。现在该快速检查下 git 的状态了：
``` $ git status```
我的终端显示了以下内容：
整体回顾
很酷吧？我们尚未对 git 执行任何特殊操作，但是它已经在观察这个目录（因为它是 git 项目），并且知道我们创建了几个新的文件。git status命令的输出同样十分简洁地告诉我们 git 没有跟踪这些文件。
我们快速回顾一下正在进行的操作以及将要执行的操作：
我们新建了几个希望 git 开始跟踪的文件
为了让 git 能跟踪文件，需要将该文件提交到仓库中
要提交文件，需要将该文件放入暂存区
可以使用 git add 命令将文件从工作目录移到暂存区
工作目录中目前有三个未跟踪文件
index.html
css目录下的 app.css
js目录下的app.js
要将所有文件提交到仓库中，首先需要将这些文件从工作目录移到暂存区。我们将使用 git add 命令将这三个文件移到暂存区。
暂存文件
是时候行动了！在终端上运行以下命令，使用 git add 将 index.html 添加到暂存区：
$ git add index.html
注意：我们仅添加了 index.html 文件。稍后我们将添加 CSS 和 JavaScript 文件。
运行git add命令没有任何输出（同样也没有错误）。如何让 git 告诉我们它执行了什么操作以及添加的 index.html 文件发生了什么呢？git status 就可以告诉我们这些信息。你可能对我一直在强调 git status命令的重要性开始感到厌烦了，但是它是非常重要的命令，特别是在你对版本控制/命令行工具不是非常熟练的时期，更要注重该命令。
我们来看看项目的状态：
$ git status
这是我获得的输出结果：
Changes to be committed
输出结果中现在出现了全新的区域："Changes to be committed"区域！这一新的"Changes to be committed"区域显示了位于暂存区的文件！目前只显示了 index.html 文件，因此暂存区只有这个文件。继续这一思路，如果我们现在提交 commit，则只有 index.html 文件会被提交。
提示：你注意到"Changes to be committed"下方的帮助文本了吗？它提示 (use "git rm --cached ，也就是当你不小心运行了 git add 并提供了错误文件，它会提示你应该怎么操作。
顺便提下，git rm --cached 与 shell 的 rm 命令不同。git rm --cached不会破坏任何属于你的文件，它只是从暂存区删掉了文件。
此外，帮助文本中出现了"unstage"（撤消暂存）字眼。将文件从工作目录移到暂存区叫做"staging"（暂存）。如果已移动文件，则叫做"staged"（已暂存）。从暂存区将文件移回工作目录将"unstage"（撤消暂存）。如果你阅读的文档中提示“stage the following files”，则表明你应该使用 git add 命令。
暂存剩余的文件
index.html 文件已暂存。我们再暂存另外两个文件。现在我们可以运行以下命令：
$ git add css/app.css js/app.js
但是要输入的内容好多啊。我们可以使用一个特殊的命令行字符：
句点 .
句点指代当前目录，可以用来表示所有文件和目录（包括所有嵌套文件和目录！）。
```bash
$ git add css/app.css js/app.js
# 等同于
$ git add .
```
唯一要注意的是，你可能会不小心包含多余的文件。现在，我们希望同时暂存 css/app.css 和 js/app.js，因此运行该命令没问题。现在假设你向 img 目录添加了一些图片，但是暂时不想暂存这些图片。运行 git add . 将暂存这些图片。如果你暂存了不想暂存的文件，git status 会告诉你撤消暂存需要用到的命令。
暂存剩余的文件
我们使用以下简写命令暂存剩余的文件：
$ git add .
然后运行 git status：
git add 小结
git add 命令用于将文件从工作目录移到暂存区。
$ git add …
此命令：
可接受多个文件名（用空格分隔）
此外，可以使用句点 . 来代替文件列表，告诉 git 添加当前目录至暂存区（以及所有嵌套文件）
最后一次 git 状态检查
如果你尚未向工作目录添加任何文件或修改任何现有文件，则不会有任何被修改内容，但是为了进行确认，我们需要在提交 commit 之前再次快速运行下 git status，以确保项目是我们预期的状态。
提交 Commit
我们开始提交吧！
要在 git 中提交 commit，你需要使用 git commit 命令，但是先别运行这条命令。运行这条命令将会打开你在第一节课配置的代码编辑器。如果你尚未运行以下命令：
$ git config --global core.editor
回到 git 配置步骤并让 git 使用你所选的编辑器。
如果你尚未执行这一步骤并且已经运行 git commit，那么 git 可能会默认使用 Vim 编辑器。Vim 很受 Unix 或 Linux 系统用户的欢迎，但是对新用户来说，并不太好用。这门课程肯定不推荐使用该编辑器。请参阅这篇关于如何退出 Vim 的帖子，了解如何回到普通的命令提示符界面。
如果你配置了编辑器，那么可以使用 git commit 命令提交 commit：
$ git commit
注意，你的编辑器应该会打开并且会出现以下界面：
终端冻结了
如果你快速切回终端，会看到终端冻结了，并等待你在弹出的代码编辑器完成编辑。不用担心。当我们向代码编辑器添加必要的内容，并最终关闭代码编辑器窗口后，终端将不再冻结，并回到正常状况。
代码编辑器 Commit 消息解释说明
回到代码编辑器。我的编辑器显示了以下内容：
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Initial commit
#
# Changes to be committed:
# new file: css/app.css
# new file: index.html
# new file: js/app.js
#
第一段精确地告诉了我们需要执行的操作 - 我们需要为该 commit 提供一条消息。此外 ，任何以字符 # 开头的行将被忽略。在后面还提示：这将是初始 commit。最后，给出了将提交 commit 的文件列表。
因为这是存储库的第一个commit，我们将使用 commit 消息"Initial commit"。文本"Initial commit"并不特殊，只是第一个 commit 的常用消息。如果你想使用其他消息，完全可以！
在代码编辑器的第一行输出 commit 消息：
完成提交
现在保存文件并关闭编辑器窗口（只关闭面板/标签页还不够，你还需要关闭 git commit 命令打开的代码编辑器窗口）。
现在回到终端，你应该能看到类似于以下内容的界面：
终于提交了第一个 commit，恭喜！
你刚刚提交了第一个 commit - 哇！ 有何感受？是不是有点虎头蛇尾的感觉。说实话，当我第一次提交 commit 时，我的感受就如同
“等等...就这样？只是把将要进行提交的文件添加到了暂存区，然后运行 'git commit'？”
答案是 “是的”。是的，就这些内容。一开始，你会觉得版本控制是一个要克服的庞大障碍，然后才能成为真正的程序员/开发者/设计师等等。但是当你理解术语（我认为是最具挑战的部分）后，实际运用版本控制就不是那么可怕了。
使用
-m选项绕过编辑器提示：如果你要编写的提交说明很简短，不想等打开代码编辑器后再输入信息，可以直接在命令行中使用
-m选项传入信息：$ git commit -m "Initial commit"在上述示例中，文本
"Initial commit"被作为提交说明信息。但是注意，不能为 commit 提供信息的描述（description），只能提供信息部分（message）。
第二个 commit - 添加更改
我们已经短暂休息了一下，现在提交第二个 commit！将以下内容添加到 index.html 中的 body 标记中：
Expedition
下一步是什么？没错，运行 git status！
[[图片上传失败...(image-c1ec9c-1523348666713)]
终端显示了 git status 命令的结果。它显示了"Changes not staged for commit"部分，其中包含修改后的"index.html"文件。](https://classroom.udacity.com/nanodegrees/nd019-cn/parts/8998189c-3298-475c-9069-db3866d4a688/modules/6394fac9-adee-4a2b-94ca-a9df7ef5c384/lessons/5f584ce7-1b7b-4848-80c1-b559739ea363/concepts/95564c00-5060-45e7-aa24-e26fb9039f90#)
提示：如果你运行了
git status，但是没有看到index.html已更改，确保文件已被保存。我经常在修改文件以后忘记保存文件！我觉得修改文件后是否记得保存是衡量真正的专业人士的标准。
具有多个作用的 git add
我们修改了文件。git 看到该文件已被修改。到目前为止，一切正常。注意，要提交 commit，待提交的文件必须位于暂存区。要将文件从工作目录移到暂存区，我们应该使用哪个命令？答对了，是 git add！
我们使用 git add 向暂存区添加了新建的文件，同样的，我们也能使用同一命令将修改的文件暂存。
现在使用 git add 命令将文件移到暂存区，并使用 git status 验证文件是否位于暂存区。
第二个 commit
现在我们的文件已经具有可以提交的更改，让我们提交第二个 commit 吧！使用 git commit 命令提交 commit，并添加提交说明 Add header to blog。
现在，你可能会问自己：“Richard 为何会这样书写提交说明？” 或 “何为好的提交说明？”。问的好，我们将在下一部分探讨这些问题！
commit 中应该包含什么内容
我一直在告诉你要创建什么文件，提供需要要包含的内容，并告诉你何时应该进行 commit。但是你自己知道应该在 Commit 中包含什么内容，以及何时/多久进行 commit 吗？
关键在于使每个 commit 都有其侧重点。每个 commit 应该记录一项更改。这种说法可能比较主观（完全没问题），但是每个 commit 应该只对项目的一个方面做出更改。
这并不限制可以添加/删除多少行代码或添加/删除/修改多少个文件。假设你想更改侧栏，并向其中添加新的图片。你可能会：
向项目文件中添加新的图片
更改 HTML
添加/修改 CSS 以包含新图片
完全可以使用一个 commit 记录所有这些更改！
但是，一个 commit 不应包含不相关的更改，更改侧栏，然后重新描述脚注内容。这两项更改相互没有关系，不应包含在同一 commit 中。先进行一项更改，提交该更改，然后再进行第二项更改。这样的话，如果一个更改有 bug，你需要撤消该更改时，则不用同时撤消另一个更改。
我认为在判断应该在 commit 中包含什么内容时，最好的方法是思考下“如果该 commit 中的所有更改都清空了，会怎样？”。如果删除了某个 commit，应该只撤消一项更改。
别担心，commit 不会随机地被清除。
在后面的课程中，我们将学习使用 git 撤消 commit 中进行的更改，以及如何谨慎地手动删除最后提交的一个 commit。
git commit 小结
git commit 命令会取出暂存区的文件并保存到仓库中。
$ git commit
此命令：
将打开配置中指定的代码编辑器
（请参阅第一节课中的 git 配置流程，了解如何配置编辑器）
在代码编辑器中：
必须提供提交说明
以
#开头的行是注释，将不会被记录添加提交说明后保存文件
关闭编辑器以进行提交
然后使用 git log 检查你刚刚提交的 commit！
深入研究
将文本编辑器与 git 相关联 - 英 GitHub 帮助文档
起步 - 初次运行 Git 前的配置 (git book)：英 | 中
良好的提交说明
我们来思考一个问题：
如何编写良好的提交说明？为何要编写好的提交说明？
问的好！花点时间编写良好的提交说明，再怎么强调这一点都不为过。
何为好的提交说明呢？问的好，很多人发表过关于这一问题的文章，比如： 如何编写 Git Commit Message - 英|译文 、Commit message 和 Change log 编写指南。在编写好的提交说明时，需要注意以下几个事项：
建议
消息篇幅简短（少于 60 个字符）
解释提交的作用（不是如何更改或为何更改！）
禁忌
请勿解释为何做出了这些更改（下文会深入讲解这一点）
请勿解释如何进行了更改（这是
git log -p的目的！）请勿使用单词"and"
如果你必须使用 "and"，则你的提交说明可能进行了太多的更改，将这些更改拆分为独立的 commit
例如 "make the background color pink and increase the size of the sidebar"
在编写提交说明时，我喜欢用以下短语造句："This commit will…"。你可以补充完整该句子并作为提交说明使用。
最重要的是，在编写提交说明时保持一致性！
解释原因
如果你需要解释为何进行了提交，也可以！
在编写提交说明时，第一行是消息本身。消息之后空一行，然后输入正文或说明，包括关于为何需要该 commit 的原因详情（例如 URL 链接）。
以下是编辑提交说明时屏幕可能显示的内容：
提交说明的详情描述部分包含在 git log 中。要查看带有详情描述的提交说明，请参阅博客项目仓库并查看 commit 8a11b3f。
但是 git log --oneline 中仅包含了说明（第一行）！
优达学城的提交样式要求
git 提交说明样式指南。
下一个是 git diff！
在下一部分，我们将学习一个新的工具（具有相似的输出！）。此工具可以在进行提交之前告诉我们已对文件进行了什么样的更改！