学习目标

• 技术目标一：掌握 Git 企业级应用，深刻理解 Git 操作过程与操作原理，理解工作区，暂存区，版本库的含义。
• 技术目标二：掌握 Git 版本管理，自由进行版本回退、撤销、修改等 Git 操作方式与背后操作原理。
• 技术目标三：掌握 Git 分支管理，从分支创建，切换，合并，删除的整个生命周期，灵活进行各种场景下的分支管理，学习常见分支管理策略。
• 技术目标四：掌握 Git 远程仓库与本地仓库，结合版本管理与分支管理，做到基于分支级的个人级开发。
• 技术目标五：理解分布式版本控制系统，学习远程仓库与本地仓库的交互操作，掌握多人协作开发模式。
• 协作目标：学习企业级常见分支策略 master/release/develop/feature/hotfix 等等，理解不同公司，不同环境下适合的分支模型。结合案例，引入工程师，测试人员，技术经理等角色，展现项目开发过程的全貌，深刻理解开发的整体流程，俯视 Git 在其中的作用。

Git 初识

提出问题

不知道你工作或学习时，有没有遇到这样的情况：我们在编写各种文档时，为了 防止文档丢失，更改失误，失误后能恢复到原来的版本，不得不复制出⼀个副本，比如：
“报告-v1”
“报告-v2”
“报告-v3”
“报告-确定版”
“报告-最终版”
“报告-究极进化版”
…
每个版本有各自的内容，但最终会只有一份报告需要被我们使用 。
但在此之前的工作都需要这些不同版本的报告，于是每次都是复制粘贴副本，产出的文件就越来越多，文件多不是问题，问题是：随着版本数量的不断增多，你还记得这些版本各自都是修改了什么吗？ 文档如此，我们写的项目代码，也是存在这个问题的！！

如何解决？—— 版本控制器

为了能够更方便我们管理这些不同版本的文件，便有了版本控制器。所谓的版本控制器，就是能让你了解到一个文件的历史，以及它的发展过程的系统。通俗的讲就是⼀个可以记录工程的每一次改动和版本迭代的一个管理系统，同时也方便多人协同作业。目前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的文件，例如 doc、excel、dwg、dgn、rvt等等。对于我们开发人员来说，Git 最重要的就是可以帮助我们管理软件开发项目中的源代码文件！

注意事项

还需要再明确一点，所有的版本控制系统，Git 也不例外，其实只能跟踪文本文件的改动，比如 TXT 文件，网页，所有的程序代码等等。版本控制系统可以告诉你每次的改动，比如在第5行加了⼀个单词“Linux”，在第8行删了⼀个单词“Windows”。
而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

Git 安装

Git 是开放源代码的代码托管工具，最早是在 Linux 下开发的。开始也只能应用于 Linux 平台，后面慢慢的被移植到 windows 下，现在，Git 可以在 Linux、Unix、Mac 和 Windows 这几大平台上正常运行了。

Linux CentOS

如果你的的平台是 CentOS，安装 Git 相当简单，以我的 CentOS 7.6为例：
首先，你可以试着输入 Git，看看系统有没有安装 Git：

$ git
-bash: git: command not found

出现像上面的结果，Linux会友好地告诉你 Git 没有安装。
安装 Git ：

sudo yum -y install git

查看 Git 安装的版本：

git --version

相信聪明的朋友肯定不会出现以下失误噢！

卸载 Git ：

$ sudo yum remove git -y  

Linux Ubuntu

如果你的的平台是 Ubuntu，安装 Git 相当简单，以我的 Ubuntu20.04为例：
首先，你可以试着输入 Git，看看系统有没有安装 Git：

$ git
Command 'git' not found, but can be installed with:sudo apt install git

出现像上面的结果，Linux 会友好地告诉你 Git 没有安装，还会告诉你如何安装Git。
安装 Git：

$ sudo apt-get install git -y

查看 Git 安装的版本：

$ git --version

卸载 Git ：

$ sudo apt-get remove -y

Windows

可以根据这个参考链接来跟着安装。

Git 基本操作

创建 Git 本地仓库

要提前说的是，仓库是进行版本控制的一个文件目录。我们要想对文件进行版本控制，就必须先在一个合适的路径底下创建⼀个仓库出来。
创建⼀个 Git 本地仓库对应的命令为 git init ，注意命令要在文件目录下执行，例如：

$ pwd 
$ mkdir gitcode
$ cd gitcode
$ git init
$ Initialized empty Git repository in /home/quantian/108/gitcode/.git/
$ ls -a
. .. .git

我们发现，当前目录下多了⼀个 .git 的隐藏文件， .git 目录是 Git 来跟踪管理仓库的，不要手动修改这个目录里面的文件，不然改乱了，就把 Git 仓库给破坏了。
其中包含 Git 仓库的诸多细节，有兴趣的同学可以进入看看。

$ tree .git/

配置 Git

当安装 Git 后首先要做的事情是配置你的用户名称和 e-mail 地址，这是非常重要的，因为不配置的话将来我们对本地仓库操作的时候可能会出现一系列的问题。配置命令为：

git config [--global] user.name "Your Name" 
git config [--global] user.email "email@example.com" 
# 把 Your Name 改成你的昵称
# 把 email@example.com 改成邮箱的格式，只要格式正确即可

其中 –global 是⼀个可选项。如果使用了该选项，表示这台机器上所有的 Git 仓库都会使用这个配置。如果你希望在不同仓库中使用不同的 name 或 e-mail ，可以不要 –global 选项，但要注意的是，执行命令时必须要在仓库里。
查看配置命令为：

git config -l

删除对应的配置命令为：

git config [--global] --unset user.name
git config [--global] --unset user.email

PS：配置的时候带了 --global 选项删除的时候也要带上该选项才能正确删除。

认识工作区、暂存区、版本库

• 工作区：是在电脑上你要写代码或文件的目录。
• 暂存区：英文叫 stage 或 index。⼀般存放在 .git 目录下的 index 文件（.git/index）中，我们把暂存区有时也叫作索引（index）。
• 版本库：又名仓库，英文名 repository 。工作区有⼀个隐藏目录 .git ，它不算工作区，而是 Git 的版本库。这个版本库里面的所有文件都可以被 Git 管理起来，每个文件的新增、修改和删除，Git 都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

下面这个图展示了工作区、暂存区和版本库之间的关系：

• 图中左侧为工作区，右侧为版本库。Git 的版本库里存了很多东西，其中最重要的就是暂存区。
• 在创建 Git 版本库时，Git 会为我们自动创建一个唯一的 master 分支，以及指向 master 的⼀个指针叫 HEAD。（分支和HEAD的概念下面再说）
• 当对工作区修改的文件执行 git add 命令时，暂存区目录树的文件索引会被更新。（PS：这些修改会被写进一个个object对象中）
• 当执行提交操作 git commit 时，master 分支会做相应的更新，可以简单理解为暂存区的目录树才会被真正写到版本库中。

由上述描述我们便能得知：通过新建或粘贴进目录的文件，并不能称之为向仓库中新增文件，而只是在⼯作区新增了文件。必须要通过使用 git add 和 git commit 命令才能将文件添加到仓库中进行管理！！！

添加文件——场景一

在包含 .git 的目录下新建一个 ReadMe 文件，我们可以使用 git add 命令可以将文件添加到暂存区：

• 添加一个或多个文件到暂存区：

git add [file1] [file2] ...

• 添加指定目录到暂存区，包括子目录：

 git add [dir]

• 添加当前目录下的所有文件改动到暂存区：

git add .

再使用 git commit 命令将暂存区内容添加到本地仓库中：

• 提交暂存区全部内容到本地仓库中: git commit -m “message”
• 提交暂存区的指定文件到仓库区： git commit [file1] [file2] … -m “message”

PS：git commit 后面的 -m 选项，要跟上描述本次提交的 message，由用户自己完成，这部分内容绝对不能省略，并要好好描述，是用来记录你的提交细节，是给我们人看的。例如：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ ls
ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ vim ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "commit my first file"
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "commit my first file"
[master (root-commit) f7d9919] commit my first file1 file changed, 2 insertions(+)create mode 100644 ReadMe

git commit 命令执行成功后会告诉我们，1个文件被改动（就是我们新添加的ReadMe文件），插入了两行内容（ReadMe有两行内容）。我们还可以多次 add 不同的文件，而只 commit 一次便可以提交所有文件，是因为需要提交的文件是通通被 add 到暂存区中，然后一次性 commit 暂存区的所有修改。如：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ touch file1 file2 file3
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ ls
file1  file2  file3  ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add file1 file2 file3
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "commit 3 files"
[master 8ecc460] commit 3 files3 files changed, 0 insertions(+), 0 deletions(-)create mode 100644 file1create mode 100644 file2create mode 100644 file3

截至目前为止，我们已经更够将代码直接提交至本地仓库了。我们可以使用 git log 命令，来查看下历史提交记录：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git log
commit 8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb4629
Author: quantian <...@qq.com>
Date:   Sat Jun 1 20:05:29 2024 +0800commit 3 filescommit f7d99193ca7139fb44894c5bdedb46ef926c9c25
Author: quantian <...@qq.com>
Date:   Sat Jun 1 19:56:57 2024 +0800commit my first file

该命令显示从最近到最远的提交日志，并且可以看到我们 commit 时的日志消息。如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 –pretty=oneline 参数：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git log --pretty=oneline
8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb4629 commit 3 files
f7d99193ca7139fb44894c5bdedb46ef926c9c25 commit my first file

需要说明的是，我们看到的一大串类似 8ecc46…f1b9f1fb462 的是每次提交的commit id （版本号），Git 的 commit id 不是1，2，3……递增的数字，而是⼀个 SHA1 （哈希）计算出来的⼀个非常大的数字，用十六进制表示（你看到的 commit id 和我的肯定不一样，以你自己的为准）。

查看 .git 文件

先来看看我们的 .git 的目录结构：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ tree .git
.git
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── master
├── objects
│   ├── 60
│   │   └── 8a7d3551c68414651854b7d0b360f91f80f9c1
│   ├── 8e
│   │   └── cc4603aa4f4290c5bfc0bb0632f1b9f1fb4629
│   ├── e6
│   │   └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│   ├── f5
│   │   └── 4bdb11e712c170c3e8929858fa05f8aa33e9bb
│   ├── f7
│   │   └── d99193ca7139fb44894c5bdedb46ef926c9c25
│   ├── f8
│   │   └── 031228be309590b053a6c5793724077977701d
│   ├── info
│   └── pack
└── refs├── heads│   └── master└── tags18 directories, 24 files

1. index 就是我们的暂存区，add 后的内容都是添加到这里的。
2. HEAD 就是我们的默认指向 master 分支的指针：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat .git/HEAD
ref: refs/heads/master

而默认的 master 分支，其实就是：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat .git/refs/heads/master
8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb4629

打印的 8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb462 是什么东西呢？保存的就是当前最新的 commit id 。

3. objects 为 Git 的对象库，里面包含了创建的各种版本库对象及内容。当执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的⼀个新的对象中，就位于 ".git/objects"目录下，让我们来看看这些对象有何用处：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ ls .git/objects/
60  8e  e6  f5  f7  f8  info  pack

查找 object 时要将 commit id 分成2部分，其前2位是文件夹名称，后38位是文件名称。找到这个文件之后，⼀般不能直接看到里面是什么，该类文件是经过 sha （安全哈希算法）加密过的文件，好在我们可以使用 git cat-file 命令来查看版本库对象的内容：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git cat-file -p 8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb4629
tree f8031228be309590b053a6c5793724077977701d
parent f7d99193ca7139fb44894c5bdedb46ef926c9c25
author quantian <3098048780@qq.com> 1717243529 +0800
committer quantian <3098048780@qq.com> 1717243529 +0800commit 3 files
#这就是我们最近一次的提交

其中，还有一行 tree f8031228be309590b053a6c5793724077977701d，我们使用同样的方法，看看结果：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git cat-file -p f8031228be309590b053a6c5793724077977701d
100644 blob f54bdb11e712c170c3e8929858fa05f8aa33e9bb	ReadMe
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	file1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	file2
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391	file3

在看 ReadMe 对应的 f54bdb11e712c170c3e8929858fa05f8aa33e9bb：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git cat-file -p f54bdb11e712c170c3e8929858fa05f8aa33e9bb
hello git
hello git
#这是我们对 ReadMe 进行的修改！被 git 记录下来了！
#证明我们修改的工作区内容会写入对象库的一个新的 git 对象中

总结⼀下，在本地的 git 仓库中，有几个文件或者目录很特殊

• index：暂存区，git add 后会更新该内容。
• HEAD：默认指向 master 分支的⼀个指针。
• refs/heads/master：文件里保存当前 master 分支的最新 commit id 。
• objects：包含了创建的各种版本库对象及内容，可以简单理解为放了 git 维护的所有修改。

后面再学习过程中，最好能将常见的 git 操作与 .git 目录当中的结构内容变化对应起来，这样有利于我们理解 git 细节流程。我们后面还会学习什么分支，标签什么的，那我想后面朋友们就应该学习对应着研究了！

添加文件——场景二

学习到这里，我们已经清楚了如何向仓库中添加文件，并且对于工作区、暂存区、版本库也有了一定的认识。那么我们再展示一种添加文件的场景，能加深对工作区、暂存区、版本库的理解，示例如下：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ ls
file1  file2  file3  ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ touch file4 #新增file4文件
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add file4 #将file4添加到暂存区
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ touch file5 #新增file5文件
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "add file" #提交修改
[master 37827fb] add file1 file changed, 0 insertions(+), 0 deletions(-)create mode 100644 file4

提交后发现打印了 1 file changed, 0 insertions(+), 0 deletions(-) ，意思是只有一个文件改变了，这时我们提出了疑问，不是新增了两个文件吗？再来回忆下， git add 是将文件添加到暂存区， git commit 是将暂存区的内容添加到本地仓库中。由于我们并没有使用 git add file5 ，file5 就不在暂存区中维护，所以我们 commit 的时候其实只是把已经在暂存区的 file4 提交了，而遗漏了工作区的 file5。如何提交 file5 呢？很简单，再次 add，commit 即可。

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add file5
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "add file5"
[master 9a23620] add file51 file changed, 0 insertions(+), 0 deletions(-)create mode 100644 file5

修改文件

Git 比其他版本控制系统设计得优秀，因为 Git 跟踪并管理的是修改，而非文件。
什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建⼀个新文件，也算⼀个修改。
让我们将 ReadMe 文件进行一次修改：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ vim ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
hello world!

此时，仓库中的 ReadMe 和我们工作区的 ReadMe 是不同的，如何查看当前仓库的状态呢？ git status 命令用于查看在你上次提交之后是否有对文件进行再次修改。

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git status
# On branch 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:   ReadMe
#
no changes added to commit (use "git add" and/or "git commit -a")

上面的结果告诉我们，ReadMe 被修改过了，但还没有完成添加与提交。
目前，我们只知道文件被修改了，如果能知道具体哪些地方被修改了，就更好了。有朋友会说，我刚改的我知道呀！可是，你还记得你三天前写了什么代码吗？或者没写？

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git diff ReadMe
diff --git a/ReadMe b/ReadMe
index f54bdb1..139bc13 100644
--- a/ReadMe
+++ b/ReadMe
@@ -1,2 +1,3 @@hello githello git
+hello world!

git diff [file] 命令用来显示暂存区和工作区文件的差异，显示的格式正是 Unix 通用的 diff 格式。也可以使用 git diff HEAD – [file] 命令来查看版本库和工作区文件的区别。知道了对 ReadMe 做了什么修改后，再把它提交到本地仓库就放心多了。

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   ReadMe
#

git add 之后，就没有看到上面 no changes added to commit (use “git add”
and/or “git commit -a”) 的消息了。接下来让我们继续 git commit 即可：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "add modify ReadMe file"
[master 8ba25a9] add modify ReadMe file1 file changed, 1 insertion(+)
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git status
# On branch master
nothing to commit, working directory clean

版本回退

之前我们也提到过，Git 能够管理文件的历史版本，这也是版本控制器重要的能力。如果有一天你发现之前的工作做的出现了很大的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。
执行 git reset 命令用于回退版本，可以指定退回某一次提交的版本。要解释一下“回退”本质是要将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定：

git reset [--soft | --mixed | --hard] [HEAD]

• –mixed 为默认选项，使用时可以不用带该参数。该参数将暂存区的内容退回为指定提交版本内容，工作区文件保持不变。
• –soft 参数对于工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
• –hard 参数将暂存区与工作区都退回到指定版本。切记工作区有未提交的代码时不要用这个命令，因为工作区会回滚，你没有提交的代码就再也找不回了，所以使用该参数前一定要慎重。

HEAD 说明：

• 可直接写成 commit id，表示指定退回的版本
• HEAD 表示当前版本
• HEAD^ 表示上一个版本
• HEAD^^ 表示上上一个版本
• 以此类推…

可以使用 〜数字表示：

• HEAD~0 表示当前版本
• HEAD~1 表示上一个版本
• HEAD~2 表示上上一个版本
• 以此类推…

为了便于表述，方便测试回退功能，我们先做一些准备工作：更新3个版本的 ReadMe，并分别进行3次提交，如下所示：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ vim ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
hello world!
hello Version1
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "Version1"
[master 6becb2f] Version11 file changed, 1 insertion(+)

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ vim ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
hello world!
hello Version1
hello Version2
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "Version2"
[master 1cc9630] Version21 file changed, 1 insertion(+)

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ vim ReadMe
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
hello world!
hello Version1
hello Version2
hello Version3
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git add .
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git commit -m "Version3"
[master 36eba26] Version31 file changed, 1 insertion(+)

#查看历史提交记录
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git log --pretty=oneline
36eba26eda24a75f7deb88ef58743e1e4e6085dc Version3
1cc9630071f1deda8ff2f9d2ed3ddffa868fa70c Version2
6becb2f3b941284ecc356e4e73e8f9c62af257af Version1
8ba25a9b296096f3ca8772029e916de823d36c1c add modify ReadMe file
9a23620a19c6e11446665a9b4d8e5716fca11d58 add file5
37827fb7aca4e3b922771b914006870bd983ecce add file
8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb4629 commit 3 files
f7d99193ca7139fb44894c5bdedb46ef926c9c25 commit my first file

现在，如果我们在提交完 version3 后， 发现 version 3 编写错误，想回退到 version2，重新基于version 2 开始编写。由于我们在这里希望的是将工作区的内容也回退到 version 2 版本，所以需要用到 –hard 参数，示例如下：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git reset --hard HEAD^
HEAD is now at 1cc9630 Version2
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
hello world!
hello Version1
hello Version2

我们惊奇的发现，此时 ReadMe 文件的内容，已经回退到 version2 了！，当前，我们再次用 git log 查看⼀下提交日志，发现 HEAD 指向了 version2，如下所示：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git log --pretty=oneline
1cc9630071f1deda8ff2f9d2ed3ddffa868fa70c Version2
6becb2f3b941284ecc356e4e73e8f9c62af257af Version1
8ba25a9b296096f3ca8772029e916de823d36c1c add modify ReadMe file
9a23620a19c6e11446665a9b4d8e5716fca11d58 add file5
37827fb7aca4e3b922771b914006870bd983ecce add file
8ecc4603aa4f4290c5bfc0bb0632f1b9f1fb4629 commit 3 files
f7d99193ca7139fb44894c5bdedb46ef926c9c25 commit my first file

到这里一般回退功能就演示完了，但现在如果我后悔了，想再回到 version 3 怎么办？我们可以继续使用 git reset 命令，回退到 version 3 版本，但我们必须要拿到 version 3 的 commit id 去指定回退的版本
但我们看到了 git log 并不能打印出 version 3 的 commit id ，运气好的话我们可以从终端上去找找之前的记录，运气不好的话 commit id 已经被我们搞丢了=。=
Git 还提供了⼀个 git reflog 命令能补救一下，该命令用来记录本地的每一次命令。

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git reflog
1cc9630 HEAD@{0}: reset: moving to 1cc9630071f1deda8ff2f9d2ed3ddffa868fa70c
36eba26 HEAD@{1}: commit: Version3

这样，你就可以很方便的找到你的所有操作记录了，但 36eba26 这个是啥东西？这个是 version 3 的 commit id 的部分。没错，Git 版本回退的时候，也可以使用部分 commit id 来代表目标版本。示例如下：

[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ git reset --hard 36eba26
HEAD is now at 36eba26 Version3
[quantian@iZbp10ca6zfiie9132tqfjZ gitcode]$ cat ReadMe
hello git
hello git
hello world!
hello Version1
hello Version2
hello Version3

可往往是理想很丰满，现实很骨感。在实际开发中，由于长时间的开发了，导致 commit id 早就找不到了，可突然某⼀天，我又想回退到 version3，那该如何操作呢？貌似现在不可能了。。。

值得说的是，Git 的版本回退速度非常快，因为 Git 在内部有个指向当前分支（此处是master）的 HEAD 指针， refs/heads/master 文件里保存当前 master 分支的最新 commit id 。当我们在回退版本的时候，Git 仅仅是给refs/heads/master 中存储⼀个特定的 version，可以简单理解成如下示意图：