Git 第一讲---基础篇 git基础概念与操作

前言：

Git，作为目前全球最流行的分布式版本控制系统，以其高效、灵活和强大的分支管理能力，成为开发者手中不可或缺的工具。从个人开源项目到企业级应用，Git的身影无处不在。然而，对初学者而言，Git的抽象概念和命令行操作往往让人望而生畏：commit、branch、merge、remote…… 这些术语背后究竟隐藏着怎样的逻辑？如何通过简单的命令避免代码灾难？

 本文将从零开始，为你揭开Git的神秘面纱。

---

 

目录

前言：

一、git的基础概念

1.1git的基本认识

1.11 提出问题

1.12 如何解决--版本控制器

1.2不同环境下git的安装

        1.21 在Linux-centos下

        1.21 在Linux-ubuntu下

1.3 初始化本地仓库

1.31 创建仓库

1.32 配置Git 

查看配置命令：

删除对应的配置命令：

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

1.5 查看 .git ⽂件

二、git的基本操作

2.1、添加文件

2.11 场景一_添加文件

2.12 场景二_添加文件

2.3 修改文件

2.4 版本回退

git reset

HEAD 说明：

2.5 撤销修改

情况⼀

情况⼆

情况三

2.6 删除文件

总结​​​​​​​

---

一、git的基础概念

1.1git的基本认识

1.11 提出问题

不知道你⼯作或学习时，有没有遇到这样的情况：我们在编写各种⽂档时，为了防⽌⽂档丢失，更改 失误，失误后能恢复到原来的版本，不得不复制出⼀个副本，

⽐如： “报告-v1”    “报告-v2”    “报告-v3”    “报告-确定版”   “报告-最终版”   “报告-究极进化版” ... 每个版本有各⾃的内容，但最终会只有⼀份报告需要被我们使⽤ 。

但在此之前的⼯作都需要这些不同版本的报告，于是每次都是复制粘贴副本，产出的⽂件就越来越 多，⽂件多不是问题，问题是：随着版本数量的不断增多，你还记得这些版本各⾃都是修改了什么 吗？ ⽂档如此，我们写的项⽬代码，也是存在这个问题的！！

1.12 如何解决--版本控制器

为了能够更⽅便我们管理这些不同版本的⽂件，便有了版本控制器。

所谓的版本控制器，就是能让你 了解到⼀个⽂件的历史，以及它的发展过程的系统。通俗的讲就是⼀个可以记录⼯程的每⼀次改动和版本迭代的⼀个管理系统，同时也⽅便多⼈协同作业。

⽬前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的⽂件，例如 doc、excel、dwg、 dgn、rvt等等。对于我们开发⼈员来说，Git 最重要的就是可以帮助我们管理软件开发项⽬中的源代码 ⽂件！

一句话总结：Git是目前最大的版本控制器。

注意：

所有的版本控制系统，Git 也不例外，其实只能跟踪⽂本⽂件的改动，⽐如 TXT ⽂ 件，⽹⻚，所有的程序代码等等。版本控制系统可以告诉你每次的改动，⽐如在第5⾏加了⼀个单词 “Linux”，在第8⾏删了⼀个单词 “Windows”。

⽽图⽚、视频这些⼆进制⽂件，虽然也能由版本控制系统管理，但没法跟踪⽂件的变化，只能把⼆进 制⽂件每次改动串起来，也就是只知道图⽚从100KB改成了120KB，但到底改了啥，版本控制系统不 知道，也没法知道。

---

1.2不同环境下git的安装

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

        1.21 在Linux-centos下

#先检查一下有没有安装git
1 git
#如果提示没有发现命令，那么接着安装一个
2 sudo yum -y install git

        1.21 在Linux-ubuntu下

#先检查一下有没有安装git
1 git
#如果提示没有发现命令，那么接着安装一个
2 sudo apt-get install git -y

1.3 初始化本地仓库

1.31 创建仓库

      要提前说的是，仓库是进⾏版本控制的⼀个⽂件⽬录。

      我们要想对⽂件进⾏版本控制，就必须先创建⼀个仓库出来,git只能对该目录下的文件进行管理。

      创建⼀个 Git 本地仓库对应的命令为 git init ，注意命令只能在文件目录下执⾏。

       演示：

git init

查看目录变化 

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

1.32 配置Git 

当安装 Git 后⾸先要做的事情是设置你的 ⽤⼾名称 和 e-mail 地址，这是⾮常重要的。即使没有初始化，在第一次提交文件改变的时候，仍然要求你完成初始化工作。

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

配置主要是配置提交人的个人信息，就类似与下载一个软件，后面要登陆完善个人信息。

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

查看配置命令：

1 git config -l

演示：

删除对应的配置命令：

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

演示： 

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

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

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

图中左侧为⼯作区，右侧为版本库。

Git 的版本库⾥存了很多东西，其中最重要的就是暂存区。

 在创建 Git 版本库时，Git 会为我们⾃动创建⼀个唯⼀的 master 分⽀，以及指向 master 的⼀个指 针叫 HEAD。（分⽀和HEAD的概念后⾯再说）

 当对⼯作区修改（或新增）的⽂件执⾏ git add 命令时，暂存区⽬录树的⽂件索引（索引会指向对象库，而对象库中存储这一个又一个的git对象）会被更新。

 当执⾏提交操作 git commit 时，master 分⽀会做相应的更新，可以简单理解为暂存区的⽬录才会被真正写到版本库中。

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

1.5 查看 .git ⽂件

当然git再怎么变化分区，任然是Linux下的一个软件程序，所以我们接下来看看git的目录结构。

# tree .git/
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-merge-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│   └── heads
│   └── master
├── objects
│   ├── 23
│   │   └──3605c6002791b310256a56d9ba32f3884e40bb4f
│   ├── info
│   └── pack
└── refs├── heads│   └── master└── tags

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

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

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

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

查找 object 时要将 commit id 分成2部分，其前2位是⽂件夹名称，后38位是⽂件名称。

找到这个⽂件之后，⼀般不能直接看到⾥⾯是什么，该类⽂件是经过 sha （Secure Hash Algorithm,安全哈希算法）加密过的 ⽂件，好在我们可以使⽤ git cat-file -p 命令来查看版本库对象的内容： 

我们本次提交的内容就在其中！！！

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

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

二、git的基本操作

2.1、添加文件

2.11 场景一_添加文件

情景演示：

在包含 .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⽂件），没插 ⼊了内容。 

我们可以使⽤ git log 命令，来查看 下历史提交记录： 

 

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

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 --pretty=oneline（表示的是更好的单行打印） 参数：

当然这一大串数字是我们git本次提交的commitid，git可以通过它完成相关提交的各种操作。 

2.12 场景二_添加文件

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

我们看最后一行，它提示我们只有一个文件改变了。 这时我们提出了疑问，不是新增了两个⽂件吗？ 再来回忆下， git add 是将⽂件添加到暂存区， git commit 是将暂存区的内容添加到本地仓库 中。由于我们并没有使⽤ git add file4 ，file4 就不在暂存区中维护，所以我们 commit 的时候 其实只是把已经在暂存区的 file3 提交了，⽽遗漏了⼯作区的 file4。如何提交 file4 呢？很简单，再次 add , commit 即可。或者在第一次提交的时候，就直接将整个目录的改变提交上去，不要指定提交。

2.3 修改文件

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

什么是修改？

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

让我们将 ReadMe ⽂件进⾏⼀次修改：

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

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

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

⽬前，我们只知道⽂件被修改了，如果能知道具体哪些地⽅被修改了，就更好了。

有同学会说，我刚改的我知道呀！可是，你还记得你三天前写了什么代码吗？或者没写？甚至更远的时间呢？

git diff [file] 命令⽤来显⽰暂存区和⼯作区⽂件的差异，显⽰的格式正是类Unix操作系统通⽤的diff格 式。

也可以使⽤ git diff HEAD -- [file] 命令来查看版本库和⼯作区⽂件的区别。

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

 在执行完git add 【file】操作后再次观察现象

 

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

2.4 版本回退

之前我们也提到过，Git 能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。

如果有⼀天你发现 之前前的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本 回退的功能了。 执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是 要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：

git reset

命令语法格式为： git reset [--soft | --mixed | --hard(三选一)]  [HEAD]

1. • --mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区的内容退回为指定提交版本内 容，⼯作区⽂件保持不变。
2. • --soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
3. • --hard 参数将暂存区与⼯作区都退回到指定版本。（特别要注意）

切记⼯作区有未提交的代码时不要⽤这个命 令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重。

HEAD 说明：

1.可直接写成 commit id，表⽰指定退回的版本

2.HEAD 表⽰当前版本

• HEAD^ 上⼀个版本
• HEAD^^ 上上⼀个版本
• 以此类推...

3.可以使⽤ 〜数字表⽰：

• HEAD~0 表⽰当前版本
• HEAD~1 上⼀个版本
• HEAD^2 上上⼀个版本
• 以此类推...

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

演示：

现在我新增了三个版本的ReadMe到仓库中，但是现在我发现版本三有问题，想要回退到V2版。

由于我们在这⾥希望的是将⼯作区的内容也回退到 version 2 版本，所以需 要⽤到 --hard 参数，⽰例如下：

到这⾥⼀般回退功能就演⽰完了，但现在如果我后悔了，想再回到 version 3 怎么办？

我们可以继续使 ⽤ git reset 命令，回退到 version 3 版本，但我们必须要拿到 version 3 的 commit id 去指定回退的版本。

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

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

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

下面演示的是：想要HEAD不使用commitid的用法

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

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

2.5 撤销修改

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

情况⼀

对于⼯作区的代码，还没有 add 你当然可以直接删掉你⽬前在⼯作区新增的代码，要是我们现在只写一行代码就发现还好。

要是你写了3天，⼀直都没有提交，该怎么删掉呢？

你⾃⼰都忘了⾃⼰新增过哪些，可能说，可以 git diff xxx ⼀下，看看差别在删啊， 那你肯定⼜要花3天时间删代码了，并且很⼤的概率还会改出bug。

⼀周过去了，你怎么向你的⽼板交 代呢？

Git 其实还为我们提供了更好的⽅式，我们可以使⽤ git checkout -- [file] 命令让⼯作区的 ⽂件回到最近⼀次 add 或 commit 时的状态。

注意： git checkout -- [file] 命令中的 -- 很重要，切记不要省略，⼀旦省略，该命令就变为其他意思了，后⾯我们再说。

情况⼆

已经 add ，但没有 commit 。

add 后还是保存到了暂存区呢？怎么撤销呢？

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

 在暂存区被清空的情况下，可以仿造情况一，重复操作即可。 

情况三

已经 add ，并且也 commit 了。

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

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

演示：

2.6 删除文件

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

但这样直接删除是没有⽤的，反⽽徒增烦恼， git status 命令会⽴刻告诉你哪些⽂件被删除了:

此时，⼯作区和版本库就不⼀致了，要删⽂件，⽬前除了要删⼯作区的⽂件，还要清除版本库的⽂ 件。 

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

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

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

这里就不再赘述了。

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

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

---

总结

通过本讲的学习，你已经迈出了 Git 之旅的第一步！从理解工作区、暂存区和版本库的核心概念，到掌握 git init、git add、git commit、git status 等基础操作，你已经具备了使用 Git 进行版本控制的基本能力。

Git 的强大之处不仅在于它能记录每一次代码变更，更在于它能让你的开发流程更加安全、高效。无论是个人项目还是团队协作，良好的版本控制习惯都能让你避免混乱，轻松回溯历史，甚至自信地尝试新功能而不必担心“搞砸一切”。

下节课，我们将深入探索 Git 的分支管理，解锁更高效的开发方式！

我们下期见。