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相当简单，以我的centos7.6为例：

⾸先，你可以试着输⼊Git，看看系统有没有安装Git：

出现像上⾯的结果，说明你并没有安装过Git。

安装Git:

sudo yum -y install git

查看Git安装的版本：

git --version

Linux-ubuntu

⾸先，你可以试着输⼊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 int

创建⼀个Git本地仓库对应的命令为 git init ，注意命令要在⽂件⽬录下执⾏。

然后我们发现，当前⽬录下多了⼀个 .git 的隐藏⽂件， .git ⽬录是Git来跟踪管理仓库的，不要⼿动修改这个⽬录⾥⾯的⽂件，不然改乱了，就把Git仓库给破坏了。

其中包含Git仓库的诸多细节，可以进⼊看看：

配置Git

当安装Git后⾸先要做的事情是设置你的⽤⼾名称和e-mail地址，这是⾮常重要的。配置命令为：

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

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

查看配置命令为：

 git config -l

删除对应的配置命令为：

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

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

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

下⾯这个图展⽰了⼯作区、暂存区和版本库之间的关系：

图中左侧为⼯作区，右侧为版本库。Git的版本库⾥存了很多东西，其中最重要的就是暂存区。

• 在创建Git版本库时，Git会为我们⾃动创建⼀个唯⼀的master分⽀，以及指向master的⼀个指针叫HEAD。（分⽀和HEAD的概念后⾯再说）
• 当对⼯作区修改（或新增）的⽂件执⾏ git add 命令时，暂存区⽬录树的⽂件索引会被更新。
• 当执⾏提交操作 git commit 时，master分⽀会做相应的更新，可以简单理解为暂存区的⽬录树才会被真正写到版本库中。

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

添加⽂件–场景⼀

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"

注意 git commit 后⾯的 -m 选项，要跟上描述本次提交的message，由⽤⼾⾃⼰完成，这部分内容绝对不能省略，并要好好描述，是⽤来记录你的提交细节，是给我们⼈看的。

例如：

---

git commit命令执⾏成功后会告诉我们，1个⽂件被改动（就是我们新添加的ReadMe⽂件），插⼊了两⾏内容（ReadMe有两⾏内容）。

我们还可以多次add不同的⽂件，⽽只commit⼀次便可以提交所有⽂件，如：

git log

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

该命令显⽰从最近到最远的提交⽇志，并且可以看到我们commit时的⽇志消息。

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 --pretty=oneline 参数：

需要说明的是，我们看到的⼀⼤串类似 3e659...07e75 的是每次提交的 commit id （版本号），Git的 commit id 不是1，2，3……递增的数字，⽽是⼀个SHA1计算出来的⼀个⾮常⼤的数字，⽤⼗六进制表⽰（你看到的 commit id 和我的肯定不⼀样，以你⾃⼰的为准）。

查看.git⽂件

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

[root@VM-16-15-centos ~]# 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
│   ├── 2c
│   │   └── 5264370f2630da80ee38f412213d59657af6e8
│   ├── 3b
│   │   └── 18e512dba79e4c8300dd08aeb37f8e728b8dad
│   ├── 3e
│   │   └── 6595623aeef2d29588d0f6d0fb359d40307e75
│   ├── 65
│   │   └── bf9553b6606ec6ab71335d130ae188cba87322
│   ├── 72
│   │   └── 0158fddedab0b1edc636477bff392e443950d1
│   ├── d2
│   │   └── bd2ff5e6774fcb87e5c5fe23c91e4ee3ee3ad8
│   ├── e6
│   │   └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│   ├── f1
│   │   └── e64366e0b2acab10e64c4deedf4b44f996ac3d
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

20 directories, 26 files

• index 就是我们的暂存区，add后的内容都是添加到这⾥的。

---

• HEAD 就是我们的默认指向master分⽀的指针：

[root@VM-16-15-centos ~]# cat .git/HEAD
ref: refs/heads/master

---

• ⽽默认的master分⽀，其实就是:

[root@VM-16-15-centos ~]# cat .git/refs/heads/master
f1e64366e0b2acab10e64c4deedf4b44f996ac3d

打印的 f1e64366...4f996ac3d 是什么东西呢？保存的就是当前最新
的 commit id.

---

• objects 为Git的对象库，⾥⾯包含了创建的各种版本库对象及内容。

当执⾏ git add 命令时，暂存区的⽬录树被更新，同时⼯作区修改（或新增）的⽂件内容被写⼊到对象库中的⼀个新的对象中，就于".git/objects"⽬录下，让我们来看看这些对象有何⽤处：

[root@VM-16-15-centos ~]#  ls .git/objects/
2c  3b  3e  65  72  d2  e6  f1  info  pack

git cat-file

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

我们看一下第一个版本库对象：

[root@VM-16-15-centos gitcode]# git cat-file -p 2c5264370f2630da80ee38f412213d59657af6e8
100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad	readme

可以看到，第一个版本库对象代表我们之前第一次提交的readme文件。

我们再看一下里面的内容：

[root@VM-16-15-centos gitcode]# git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
hello world
# 这是我们对ReadMe做的修改！！被git记录了下来！！

---

总结⼀下，在本地的git仓库中，有⼏个⽂件或者⽬录很特殊：

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

后⾯再学习过程中，最好能将常⻅的 git 操作与 .git ⽬录当中的结构内容变化对应起来，这样有
利于我们理解git细节流程。

---

添加⽂件–场景⼆

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

我们创建了file1，file2，并且将file1进行了 git add，然后进行commit。

提交后发现打印了 1 file changed, 0 insertions(+), 0 deletions(-) ，意思是只有⼀个⽂件改变了，这时我们提出了疑问，不是新增了两个⽂件吗？

再来回忆下， git add 是将⽂件添加到暂存区， git commit 是将暂存区的内容添加到本地仓库中。由于我们并没有使⽤ git add file2 ，file2就不在暂存区中维护，所以我们commit的时候其实只是把已经在暂存的file1提交了，⽽遗漏了⼯作区的file2。

因此，要想将file2也放到暂存区，我们需要重新进行如下操作：

[root@VM-16-15-centos gitcode]# git add file2
[root@VM-16-15-centos gitcode]# git commit -m "add file2"

修改⽂件

Git⽐其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，⽽⾮⽂件。

什么是修改？⽐如你新增了⼀⾏，这就是⼀个修改，删除了⼀⾏，也是⼀个修改，更改了某些字符，也是⼀个修改，删了⼀些⼜加了⼀些，也是⼀个修改，甚⾄创建⼀个新⽂件，也算⼀个修改。

让我们将readme⽂件进⾏⼀次修改;

此时，仓库中的ReadMe和我们⼯作区的ReadMe是不同的，如何查看当前仓库的状态呢？

git status

git status 命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改。

上⾯的结果告诉我们，readme被修改过了，但还没有完成添加与提交。

⽬前，我们只知道⽂件被修改了，如果能知道具体哪些地⽅被修改了，就更好了。有同学会说，我刚改的我知道呀！可是，你还记得你三天前写了什么代码吗？或者没写？

git diff [file]、git diff HEAD – [file]

git diff [file] 命令⽤来显⽰暂存区和⼯作区⽂件的差异，显⽰的格式正是Unix通⽤的diff格式。也可以使⽤ git diff HEAD -- [file] 命令来查看版本库和⼯作区⽂件的区别。

那么我们知道了对readme做了什么修改后，再把它提交到本地仓库就放⼼多了。

版本回退

git reset

之前我们也提到过，Git能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现之前做的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。

• 执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。

要解释⼀下“回退”本质是要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：

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次提交，如下所⽰：

查看历史提交记录:

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

git reset --hard 6023a0f4c5315fafc7e7582fb5d5d7e545eeafcd

通过下图，我们发现工作区的readme内容回退到version2了。

git reflog

还存在一种情况，假设我们后悔了，想再回到version3怎么办？我们可以继续使⽤ git reset 命令，回退到 version 3 版本，但我们必须要拿到version 3 的 commit id 去指定回退的版本。

但我们看到了 git log 并不能打印出 version 3 的 commit id ，运⽓好的话我们可以从终端上去找找之前的记录，运⽓不好的话 commit id 已经被我们搞丢了（=。=）

Git还提供了⼀个 git reflog 命令能补救⼀下，该命令⽤来记录本地的每⼀次命令。

[root@VM-16-15-centos gitcode]# git reflog
6023a0f HEAD@{0}: reset: moving to 6023a0f4c5315fafc7e758
f2e6815 HEAD@{1}: commit: alter version3
6023a0f HEAD@{2}: commit: alter version2
3e0ccde HEAD@{3}: commit: alter version1
6e4b54f HEAD@{4}: commit: readme alter 1
bcfa533 HEAD@{5}: commit: add file2
937c2af HEAD@{6}: commit: add file
f1e6436 HEAD@{7}: commit: commit 3 files
3e65956 HEAD@{8}: commit (initial): commit my first fle

这样，你就可以很⽅便的找到你的所有操作记录了，但 f2e6815 这个是啥东西？

这个是 version3 的 commit id 的部分。没错，Git版本回退的时候，也可以使⽤部分 commit id 来代表⽬标版本。⽰例如下：

我们看到此时就回退到了version3版本。

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

---

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

---

撤销修改

如果我们在我们的⼯作区写了很⻓时间代码，越写越写不下去，觉得⾃⼰写的实在是垃圾，想恢复到上⼀个版本。

情况⼀：对于⼯作区的代码，还没有 add

对于少量的代码，你当然可以直接删掉你⽬前在⼯作区新增的代码。

但是如果你写了好几天，⼀直都没有提交，该怎么删掉呢？你⾃⼰都忘了哪些代码是你新增过的，有同学说，我可以 git diff xxx ⼀下，看看差别再删啊，但是代码量太大的话，根据差别一点一点删除，那你肯定⼜要花好几天时间删代码了，并且很⼤的概率还会改出bug。

git checkout – [file]

Git其实还为我们提供了更好的⽅式，我们可以使⽤ git checkout -- [file] 命令让⼯作区的⽂件回到最近⼀次add 或 commit 时的状态。要注意 git checkout -- [file] 命令中的-- 很重要，切记不要省略，⼀旦省略，该命令就变为其他意思了，后⾯我们再说。

⽰例如下：

情况⼆：已经 add ，但没有 commit

除了工作区代码你需要撤销外，假设你已经将修改通过add保存到了暂存区呢，怎么撤销呢？

让我们来回忆⼀下学过的 git reset 回退命令，该命令如果使⽤--mixed 参数，可以将暂存区的内容退回为指定的版本内容，但⼯作区⽂件保持不变。这样我们就可以回退暂存区的内容了！！！

⽰例如下

#--mixed 是默认参数，使⽤时可以省略
[root@VM-16-15-centos gitcode]# git reset HEAD readme
Unstaged changes after reset:
M	gitcode/readme

⽤ git status 查看⼀下，发现现在暂存区是⼲净的，⼯作区相比较于暂存区有修改。

现在就剩下工作区需要进行撤销修改了，我们用 git checkout --[file] 命令进行撤销：

[root@VM-16-15-centos gitcode]# git checkout -- readme
[root@VM-16-15-centos gitcode]# git status .
# On branch master
nothing to commit, working directory clean

可以看到工作区针对于暂存区没有改动，此时两者都是上一个版本时的状态。

情况三：已经 add ，并且也 commit 了

这种情况不要担⼼，我们可以 git reset --hard HEAD^ 回退到上⼀个版本！

不过，这是有条件的，就是你还没有把⾃⼰的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后⾯会讲到远程版本库，⼀旦你推送到远程版本库，你就真的gg了。

删除⽂件

在Git中，删除也是⼀个修改操作，我们实战⼀下,如果要删除 readme⽂件，怎么搞呢？如果你这样做了:

[root@VM-16-15-centos gitcode]# rm readme 
rm: remove regular file ‘readme’? y

学到这里我们应该知道，你只是删除了工作区的readme文件。

⼀般⾛到这⾥，有两种可能:

• 确实需要从版本库中删除该⽂件
• 不⼩⼼删错了

对第⼆种情况，很明显误删，需要使⽤ git 来进⾏恢复，很简单,我们刚学过（删除也是修改）:

git rm

对于第⼀种情况，很明显是没有删完，我们只删除了⼯作区的⽂件。这时就需要使⽤ git rm 将⽂件从暂存区和⼯作区中删除，并且 commit 。

[root@VM-16-15-centos gitcode]# git rm readme
rm 'gitcode/readme'
[root@VM-16-15-centos gitcode]# git commit -m "rm readme"
[master 36d40bc] rm readme
 1 file changed, 6 deletions(-)
 delete mode 100644 gitcode/readme

现在，⽂件就从版本库中被删除了。

---

the end!