老司机带路：三万字超详细图文分析Git管理的使用流程和实例讲解，不怕你学不会，就怕你不学（欢迎三连加收藏）

Posted 2021-10-02 Forever_wj

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了老司机带路：三万字超详细图文分析Git管理的使用流程和实例讲解，不怕你学不会，就怕你不学（欢迎三连加收藏）相关的知识，希望对你有一定的参考价值。

一、获取 Git 仓库

通常有两种获取 Git 项目仓库的方式：
- 将尚未进行版本控制的本地目录转换为 Git 仓库；
- 从其它服务器克隆一个已存在的 Git 仓库。
两种方式都会在本地机器上得到一个工作就绪的 Git 仓库。

① 在已存在目录中初始化仓库

如果有一个尚未进行版本控制的项目目录，想要用 Git 来控制它，那么首先需要进入该项目目录中。如果还没这样做过，那么不同系统上的做法有些不同：
- 在 Linux 上：

	$ cd /home/user/my_project

- 在 macOS 上：

	$ cd /Users/user/my_project

- 在 Windows 上：

	$ cd /c/user/my_project

之后执行：

	$ git init

该命令将创建一个名为 .git 的子目录，这个子目录含有初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。但是，在这个时候，仅仅是做了一个初始化的操作，项目里的文件还没有被跟踪。
如果在一个已存在文件的文件夹（而非空文件夹）中进行版本控制，应该开始追踪这些文件并进行初始提交。可以通过 git add 命令来指定所需的文件来进行追踪，然后执行 git commit ：

	$ git add *.c
	$ git add LICENSE
	$ git commit -m 'initial project version'

现在，已经得到了一个存在被追踪文件与初始提交的 Git 仓库。

① 克隆现有的仓库

如果想获得一份已经存在了的 Git 仓库的拷贝，比如说，如果想为某个开源项目贡献自己的一份力，这时就要用到 git clone 命令。如果对其它的 VCS 系统（比如说 Subversion）很熟悉，请留心一下所使用的命令是“clone”而不是“checkout”。这是 Git 区别于其它版本控制系统的一个重要特性，Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成工作所需要文件。
当执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。事实上，如果服务器的磁盘坏掉了，通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库（虽然可能会丢失某些服务器端的钩子（hook）设置，但是所有版本的数据仍在）。
克隆仓库的命令是 git clone 。比如，要克隆 Git 的链接库 libgit2，可以用下面的命令：

	$ git clone https://github.com/libgit2/libgit2

这会在当前目录下创建一个名为 “libgit2” 的目录，并在这个目录下初始化一个 .git 文件夹，从远程仓库拉取下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝。如果进入到这个新建的 libgit2 文件夹，会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用。
如果想在克隆远程仓库的时候，自定义本地仓库的名字，可以通过额外的参数指定新的目录名：

	$ git clone https://github.com/libgit2/libgit2 mylibgit

这会执行与上一条命令相同的操作，但目标目录名变为了 mylibgit。Git 支持多种数据传输协议，上面的例子使用的是 https:// 协议，不过也可以使用 git:// 协议或者使用 SSH 传输协议，比如 user@server:path/to/repo.git。

二、记录每次更新到仓库

① 文件的状态变化周期

现在我们的机器上有了一个真实项目的 Git 仓库，并从这个仓库中检出了所有文件的工作副本。通常，我们会对这些文件做些修改，每当完成了一个阶段的目标，想要将记录下它时，就将它提交到到仓库。
请记住，工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能是未修改，已修改或已放入暂存区。简而言之，已跟踪的文件就是 Git 已经知道的文件。
工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们，而你尚未编辑过它们。
编辑过某些文件之后，由于自上次提交后我们对它们做了修改，Git 将它们标记为已修改文件。在工作时，可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。
因此，文件的状态变化周期如下所示：

② 检查当前文件状态

可以用 git status 命令查看哪些文件处于什么状态。如果在克隆仓库后立即使用此命令，会看到类似这样的输出：

	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	nothing to commit, working directory clean

这说明现在的工作目录相当干净，换句话说，所有已跟踪文件在上次提交后都未被更改过。此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。最后，该命令还显示了当前所在分支，并告诉你这个分支同远程服务器上对应的分支没有偏离。现在，分支名是“master”，这是默认的分支名。
现在，让我们在项目下创建一个新的 README 文件。如果之前并不存在这个文件，使用 git status 命令，将看到一个新的未跟踪文件：

	$ echo 'My Project' > README
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Untracked files:
	  (use "git add <file>..." to include in what will be committed)
	
	    README
	
	nothing added to commit but untracked files present (use "git add" to track)

在状态报告中可以看到新建的 README 文件出现在 Untracked files 下面，未跟踪的文件意味着 Git 在之前的快照（提交）中没有这些文件；Git 不会自动将之纳入跟踪范围，除非我们明明白白地告诉它“我需要跟踪该文件”。这样的处理不必担心将生成的二进制文件或其它不想被跟踪的文件包含进来。不过现在的例子中，我们确实想要跟踪管理 README 这个文件。

③ 跟踪新文件

使用命令 git add 开始跟踪一个文件。所以，要跟踪 README 文件，运行：

	$ git add README

此时再运行 git status 命令，会看到 README 文件已被跟踪，并处于暂存状态：

	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git restore --staged <file>..." to unstage)
	
	    new file:   README

只要在 Changes to be committed 这行下面的，就说明是已暂存状态。如果此时提交，那么该文件在运行 git add 时的版本将被留存在后续的历史记录中，可能会想起之前我们使用 git init 后就运行了 git add 命令，开始跟踪当前目录下的文件。git add 命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。

④ 暂存已修改的文件

现在来修改一个已被跟踪的文件，如果修改了一个名为 CONTRIBUTING.md 的已被跟踪的文件，然后运行 git status 命令，会看到下面内容：

	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    new file:   README
	
	Changes not staged for commit:
	  (use "git add <file>..." to update what will be committed)
	  (use "git checkout -- <file>..." to discard changes in working directory)
	
	    modified:   CONTRIBUTING.md

文件 CONTRIBUTING.md 出现在 Changes not staged for commit 这行下面，说明已跟踪文件的内容发生了变化，但还没有放到暂存区。要暂存这次更新，需要运行 git add 命令，这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。将这个命令理解为“精确地将内容添加到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。现在来运行 git add 将“CONTRIBUTING.md”放到暂存区，然后再看看 git status 的输出：

	$ git add CONTRIBUTING.md
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    new file:   README
	    modified:   CONTRIBUTING.md

现在两个文件都已暂存，下次提交时就会一并记录到仓库。假设此时，想要在 CONTRIBUTING.md 里再加条注释，重新编辑存盘后，准备好提交。不过且慢，再运行 git status 看看：

	$ vim CONTRIBUTING.md
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    new file:   README
	    modified:   CONTRIBUTING.md
	
	Changes not staged for commit:
	  (use "git add <file>..." to update what will be committed)
	  (use "git checkout -- <file>..." to discard changes in working directory)
	
	    modified:   CONTRIBUTING.md

怎么回事？现在 CONTRIBUTING.md 文件同时出现在暂存区和非暂存区，这怎么可能呢？实际上 Git 只不过暂存了运行 git add 命令时的版本。如果现在提交，CONTRIBUTING.md 的版本是最后一次运行 git add 命令时的那个版本，而不是运行 git commit 时，在工作目录中的当前版本。所以，运行了 git add 之后又作了修订的文件，需要重新运行 git add 把最新版本重新暂存起来：

	$ git add CONTRIBUTING.md
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    new file:   README
	    modified:   CONTRIBUTING.md

⑤ 状态简览

git status 命令的输出十分详细，但其用语有些繁琐。Git 有一个选项可以帮你缩短状态命令的输出，这样可以以简洁的方式查看更改。如果使用 git status -s 命令或 git status --short 命令，将得到一种格式更为紧凑的输出：

	$ git status -s
	 M README
	MM Rakefile
	A  lib/git.rb
	M  lib/simplegit.rb
	?? LICENSE.txt

新添加的未跟踪文件前面有 ?? 标记，新添加到暂存区中的文件前面有 A 标记，修改过的文件前面有 M 标记。输出中有两栏，左栏指明了暂存区的状态，右栏指明了工作区的状态。例如，上面的状态报告显示： README 文件在工作区已修改但尚未暂存，而 lib/simplegit.rb 文件已修改且已暂存，Rakefile 文件已修，暂存后又作了修改，因此该文件的修改中既有已暂存的部分，又有未暂存的部分。

⑥ 忽略文件

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式。来看一个实际的 .gitignore 例子：

	$ cat .gitignore
	*.[oa]
	*~

第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件，一般这类对象文件和存档文件都是编译过程中出现的，第二行告诉 Git 忽略所有名字以波浪符（~）结尾的文件，许多文本编辑软件（比如 Emacs）都用这样的文件名保存副本。此外，可能还需要忽略 log，tmp 或者 pid 目录，以及自动生成的文档等等，要养成一开始就为新仓库设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。
文件 .gitignore 的格式规范如下：
- 所有空行或者以 # 开头的行都会被 Git 忽略；
- 可以使用标准的 glob 模式匹配，它会递归地应用在整个工作区中；
- 匹配模式可以以（/）开头防止递归；
- 匹配模式可以以（/）结尾指定目录；
- 要忽略指定模式以外的文件或目录，可以在模式前加上叹号（!）取反。
所谓的 glob 模式是指 shell 所使用的简化了的正则表达式，星号（*）匹配零个或多个任意字符；[abc] 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。使用两个星号表示匹配任意中间目录，比如 a/**/z 可以匹配 a/z 、 a/b/z 或 a/b/c/z 等。
再看一个 .gitignore 文件的例子：

	# 忽略所有的 .a 文件
	*.a
	
	# 但跟踪所有的 lib.a，即便前面忽略了 .a 文件
	!lib.a
	
	# 只忽略当前目录下的 TODO 文件，而不忽略 subdir/TODO
	/TODO
	
	# 忽略任何目录下名为 build 的文件夹
	build/
	
	# 忽略 doc/notes.txt，但不忽略 doc/server/arch.txt
	doc/*.txt
	
	# 忽略 doc/ 目录及其所有子目录下的 .pdf 文件
	doc/**/*.pdf

在最简单的情况下，一个仓库可能只根目录下有一个 .gitignore 文件，它递归地应用到整个仓库中。然而，子目录下也可以有额外的 .gitignore 文件，子目录中的 .gitignore 文件中的规则只作用于它所在的目录中（Linux 内核的源码库拥有 206 个 .gitignore 文件）。

⑦ 查看已暂存和未暂存的修改

如果 git status 命令的输出过于简略，而我们想知道具体修改了什么地方，可以用 git diff 命令。通常可能会用它来回答这两个问题：当前做的哪些更新尚未暂存？有哪些更新已暂存并准备好下次提交？虽然 git status 已经通过在相应栏下列出文件名的方式回答了这个问题，但 git diff 能通过文件补丁的格式更加具体地显示哪些行发生了改变。
假如再次修改 README 文件后暂存，然后编辑 CONTRIBUTING.md 文件后先不暂存，运行 status 命令将会看到：

	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    modified:   README
	
	Changes not staged for commit:
	  (use "git add <file>..." to update what will be committed)
	  (use "git checkout -- <file>..." to discard changes in working directory)
	
	    modified:   CONTRIBUTING.md

要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff：

	$ git diff
	diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
	index 8ebb991..643e24f 100644
	--- a/CONTRIBUTING.md
	+++ b/CONTRIBUTING.md
	@@ -65,7 +65,8 @@ branch directly, things can get messy.
	 Please include a nice description of your changes when you submit your PR;
	 if we have to read the whole diff to figure out why you're contributing
	 in the first place, you're less likely to get feedback and have your change
	-merged in.
	+merged in. Also, split your changes into comprehensive chunks if your patch is
	+longer than a dozen lines.
	
	 If you are starting to work on a particular area, feel free to submit a PR
	 that highlights your work in progress (and note in the PR title that it's

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容。
若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --staged 命令，这条命令将比对已暂存文件与最后一次提交的文件差异：

	$ git diff --staged
	diff --git a/README b/README
	new file mode 100644
	index 0000000..03902a1
	--- /dev/null
	+++ b/README
	@@ -0,0 +1 @@
	+My Project

不过要注意，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。所以有时候一下子暂存了所有更新过的文件，运行 git diff 后却什么也没有，就是这个原因。
像之前说的，暂存 CONTRIBUTING.md 后再编辑，可以使用 git status 查看已被暂存的修改或未被暂存的修改。如果我们的环境（终端输出）看起来如下：

	$ git add CONTRIBUTING.md
	$ echo '# test line' >> CONTRIBUTING.md
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    modified:   CONTRIBUTING.md
	
	Changes not staged for commit:
	  (use "git add <file>..." to update what will be committed)
	  (use "git checkout -- <file>..." to discard changes in working directory)
	
	    modified:   CONTRIBUTING.md

现在运行 git diff 看暂存前后的变化：

	$ git diff
	diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
	index 643e24f..87f08c8 100644
	--- a/CONTRIBUTING.md
	+++ b/CONTRIBUTING.md
	@@ -119,3 +119,4 @@ at the
	 ## Starter Projects
	
	 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
	+# test line

然后用 git diff --cached 查看已经暂存起来的变化（ --staged 和 --cached 同义）：

	$ git diff --cached
	diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
	index 8ebb991..643e24f 100644
	--- a/CONTRIBUTING.md
	+++ b/CONTRIBUTING.md
	@@ -65,7 +65,8 @@ branch directly, things can get messy.
	 Please include a nice description of your changes when you submit your PR;
	 if we have to read the whole diff to figure out why you're contributing
	 in the first place, you're less likely to get feedback and have your change
	-merged in.
	+merged in. Also, split your changes into comprehensive chunks if your patch is
	+longer than a dozen lines.
	
	 If you are starting to work on a particular area, feel free to submit a PR
	 that highlights your work in progress (and note in the PR title that it's

⑧ 提交更新

现在的暂存区已经准备就绪，可以提交了，在此之前，请务必确认还有什么已修改或新建的文件还没有 git add 过，否则提交的时候不会记录这些尚未暂存的变化。这些已修改但未暂存的文件只会保留在本地磁盘。因此，每次准备提交前，先用 git status 看下，所需要的文件是不是都已暂存起来了，然后再运行提交命令 git commit，这样会启动选择的文本编辑器来输入提交说明：

	$ git commit

编辑器会显示类似下面的文本信息（本例选用 Vim 的屏显方式展示）：

	# Please enter the commit message for your changes. Lines starting
	# with '#' will be ignored, and an empty message aborts the commit.
	# On branch master
	# Your branch is up-to-date with 'origin/master'.
	#
	# Changes to be committed:
	#	new file:   README
	#	modified:   CONTRIBUTING.md
	#
	~
	~
	~
	".git/COMMIT_EDITMSG" 9L, 283C

可以看到，默认的提交消息包含最后一次运行 git status 的输出，放在注释行里，另外开头还有一个空行，供输入提交说明，完全可以去掉这些注释行，不过留着也没关系，多少能帮你回想起这次更新的内容有哪些。
退出编辑器时，Git 会丢弃注释行，用输入的提交说明生成一次提交。另外，也可以在 commit 命令后添加 -m 选项，将提交信息与命令放在同一行，如下所示：

	$ git commit -m "Story 182: Fix benchmarks for speed"
	[master 463dc4f] Story 182: Fix benchmarks for speed
	 2 files changed, 2 insertions(+)
	 create mode 100644 README

现在已经创建了第一个提交，可以看到，提交后它会提示当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（463dc4f），以及在本次提交中，有多少文件修订过，多少行添加和删改过。
请记住，提交时记录的是放在暂存区域的快照，任何还未暂存文件的仍然保持已修改状态，可以在下次提交时纳入版本管理。每一次运行提交操作，都是对项目作一次快照，以后可以回到这个状态，或者进行比较。

⑨ 跳过使用暂存区域

尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤：

	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes not staged for commit:
	  (use "git add <file>..." to update what will be committed)
	  (use "git checkout -- <file>..." to discard changes in working directory)
	
	    modified:   CONTRIBUTING.md
	
	no changes added to commit (use "git add" and/or "git commit -a")
	$ git commit -a -m 'added new benchmarks'
	[master 83e38c7] added new benchmarks
	 1 file changed, 5 insertions(+), 0 deletions(-)

提交之前不再需要 git add 文件“CONTRIBUTING.md”，这是因为 -a 选项使本次提交包含了所有修改过的文件。这很方便，但是要注意，有时这个选项会将不需要的文件添加到提交中。

⑩ 移除文件

要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中。
如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 “Changes not staged for commit” 部分（也就是未暂存清单）看到：

	$ rm PROJECTS.md
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes not staged for commit:
	  (use "git add/rm <file>..." to update what will be committed)
	  (use "git checkout -- <file>..." to discard changes in working directory)
	
	        deleted:    PROJECTS.md
	
	no changes added to commit (use "git add" and/or "git commit -a")

然后再运行 git rm 记录此次移除文件的操作：

	$ git rm PROJECTS.md
	rm 'PROJECTS.md'
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    deleted:    PROJECTS.md

下一次提交时，该文件就不再纳入版本管理。如果要删除之前修改过或已经放到暂存区的文件，则必须使用强制删除选项 -f（译注：即 force 的首字母），这是一种安全特性，用于防止误删尚未添加到快照的数据，这样的数据不能被 Git 恢复。
另外一种情况是，想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，想让文件保留在磁盘，但是并不想让 Git 继续跟踪，当忘记添加 .gitignore 文件，不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时，这一做法尤其有用。为达到这一目的，使用 --cached 选项：

	$ git rm --cached README

git rm 命令后面可以列出文件或者目录的名字，也可以使用 glob 模式。比如：

	$ git rm log/\\*.log

意到星号 * 之前的反斜杠 \\，因为 Git 有它自己的文件模式扩展匹配方式，所以不用 shell 来帮忙展开，此命令删除 log/ 目录下扩展名为 .log 的所有文件。类似的比如：删除所有名字以 ~ 结尾的文件的命令：

	$ git rm \\*~

⑪ 移动文件

不像其它的 VCS 系统，Git 并不显式跟踪文件移动操作。如果在 Git 中重命名了某个文件，仓库中存储的元数据并不会体现出这是一次改名操作。不过 Git 非常聪明，它会推断出究竟发生了什么，至于具体是如何做到的，我们稍后再谈。
既然如此，当看到 Git 的 mv 命令时一定会困惑不已。要在 Git 中对文件改名，可以这么做：

	$ git mv file_from file_to

它会恰如预期般正常工作，实际上即便此时查看状态信息，也会明白无误地看到关于重命名操作的说明：

	$ git mv README.md README
	$ git status
	On branch master
	Your branch is up-to-date with 'origin/master'.
	Changes to be committed:
	  (use "git reset HEAD <file>..." to unstage)
	
	    renamed:    README.md -> README

其实，运行 git mv 就相当于运行了下面三条命令：

	$ mv README.md README
	$ git rm README.md
	$ git add README

如此分开操作，Git 也会意识到这是一次重命名，所以不管何种方式结果都一样。两者唯一的区别是，mv 是一条命令而非三条命令，直接用 git mv 方便得多。不过有时候用其他工具批处理重命名的话，要记得在提交前删除旧的文件名，再添加新的文件名。

三、查看提交历史

在提交了若干更新，又或者克隆了某个项目之后，我们也许想回顾下提交历史，完成这个任务最简单而又有效的工具是 git log 命令。
使用一个非常简单的 “simplegit” 项目作为示例，运行下面的命令获取该项目：

	$ git clone https://github.com/kody/simplegit-progit

当在此项目中运行 git log 命令时，可以看到下面的输出：

	$ git log
	commit ca82a6dff817ec66f44342007202690a93763949
	Author: Scott Chacon <kody@gee-mail.com>
	Date:   Mon Mar 17 21:52:11 2021 -0700
	
	    changed the version number
	
	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
	Author: Scott Chacon <kody@gee-mail.com>
	Date:   Sat Mar 15 16:40:33 2021 -0700
	
	    removed unnecessary test
	
	commit a11bef06a3f659402fe7563abf99ad00de2209e6
	Author: Scott Chacon <kody@gee-mail.com>
	Date:   Sat Mar 15 10:31:28 2021 -0700
	
	    first commit

不传入任何参数的默认情况下，git log 会按时间先后顺序列出所有的提交，最近的更新排在最上面。正如所看到的，这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。
git log 有许多选项可以搜寻你所要找的提交，其中一个比较有用的选项是 -p 或 --patch，它会显示每次提交所引入的差异（按补丁的格式输出），也可以限制显示的日志条目数量，例如使用 -2 选项来只显示最近的两次提交：

	$ git log -p -2
	commit ca82a6dff817ec66f44342007202690a93763949
	Author: Scott Chacon <kody@gee-mail.com>
	Date:   Mon Mar 17 21:52:11 2021 -0700
	
	    changed the version number
	
	diff --git a/Rakefile b/Rakefile
	index a874b73..8f94139 100644
	--- a/Rakefile
	+++ b/Rakefile
	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
	 spec = Gem::Specification.new do |s|
	     s.platform  =   Gem::Platform::RUBY
	     s.name      =   "simplegit"
	-    s.version   =   "0.1.0"
	+    s.version   =   "0.1.1"
	     s.author    =   "Scott Chacon"
	     s.email     =   "kody@gee-mail.com"
	     s.summary   =   "A simple gem for using Git in Ruby code."
	
	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
	Author: Scott Chacon <kody@gee-mail.com>
	Date:   Sat Mar 15 16:40:33 2021 -0700
	
	    removed unnecessary test
	
	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
	index a0a60ae..47c6340 100644
	--- a/lib/simplegit.rb
	+++ b/lib/simplegit.rb
	@@ -18有容云：上车 | 听老司机谈Docker安全合规建设
 （万字超详细总结纯手打）MYSQL深度学习分析
 老司机图文教程教你如何免费下载腾讯视频的视频mp4（直接下载到，不用qlv格式转mp4格式，亲测）
 bzoj4200: [Noi2015]小园丁与老司机（可行流+dp）
 Linux新手快速入门（万字超详细）
 bzoj4200[Noi2015]小园丁与老司机  STL-map+dp+有上下界最小流