Git系列（一）、Git基础教程【建议收藏】

一、Git简介

1.1、什么是Git？

• Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或大或小的项目。
• Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源代码的版本控制软件。
• Git与常用的版本控制工具CVS、Subversion等不同，它采用了分布式版本库的方式，不用服务器端软件支持。

1.2、Git的特点

• Git是目前世界上最先进的分布式版本控制系统，在处理各种项目时，都十分高效，而且非常的高大上。

1.3、集中式与分布式的区别？

最常见的集中式版本控制系统是SVN，版本库是集中放在中央处理器中的，而干活的时候，用的都是自己电脑，所以首先要从中央服务器那里得到最新的版本，然后开始干活，干完活后，需要把自己做完的活推送到中央服务器。而且集中式版本控制系统是必须联网才能工作的，一旦断网，所有人都干不成活了，可想而知，集中式版本控制系统的局限性有多大。

Git是目前世界上最流行的分布式版本控制系统，它没有中央处理器，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上，随时都可以将自己在工作区间做的修改提交到本地仓库，最后将自己的本地版本仓库推动到远程版本仓库进行合并，效率可想而知是可控的贼高。

Git与SVN的区别：

	Git	SVN
核心区别	分布式	集中式
存储方式	Git按元数据方式存储	SVN是按文件方式存储
分支	分支是Git的必杀技能，将Git从版本控制系统的家族中区分出来	分支在SVN中一点也不特别，其实它就是版本控制系统中的另外一个目录
全局版本号	Git没有，是目前Git跟SVN缺少的最大特征	SVN有全局版本号
内容完整性	Git的内容存储使用的是SHA-1哈希算法，确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏	在这方面SVN的性能是低于Git的
安全性	和SVN相比，Git的每个分支都有一个完整的版本库，某个分支的电脑坏掉了，不要紧可以随便从别人那里赋值一份就可了	而SVN版本控制系统的中央服务器一旦挂掉，所有人all都么的活干了

如下图示：

1.4、什么是版本控制系统？

举个栗子，假设你想用Word写了一篇毕业论文，很长，而且在你的论文达到最低查重率之前，你肯定要经过若干次的修改，最终才会提交。

然而这期间你经历的每次修改，增加一段段落，或者删除一段落，但是你都不想直接将整篇论文保存修改，因为你怕哪天你会找不回你删除的是哪些段落，何时删除的？所以只好每次在修改的时候将论文都“另存为。。。”一个新的文档，再接着改，改到一定程度，再“另存为。。。”，最后你的桌面会变成这样，你觉嘞烦归烦，反正我烦：

一周后，你行彻底整理下最终版毕业论文，你看着这些杂七杂八的副版本文档，你想知道这篇改动了哪一些，那篇改动了哪段，你只能一篇一篇的对比，别说烦不烦，你就说能受了不，但是哪个版本的你都不想删除，没办法。

更要命的是啥，如果你想请教你的指导老师给你指正下，你要通过email发送给你的老师，发送后，在这期间你突发感想又添了几句话，过了一天后你的老师又将论文通过email发送给你，在这次，你必须要想想，老师做了哪些修改和你做的修改，要部分舍弃，那部分留着最终整合在一块，你就说累不累，不累就是困，这大概就是成年人的崩溃吧！！！

于是你睡了一觉，早上醒来想了想有没有一个软件可以自动记录每次修改文件的改动，还可以让多人同时编辑，最后将每个人做的修改版本整理在一块，无需手动合并，这岂不让人乐乎？

哎，你想的没错，这个软件有了，他就是当今世界最流行的Git（没有之一），于是你仰天大笑。

1.5、Git下载安装

在使用Git前我们需要先安装 Git。Git 目前支持 Linux/Unix、Solaris、Mac和 Windows 平台上运行。
本篇我们只介绍在Windows下安装Git，Git 各平台安装包下载地址为：http://git-scm.com/downloads

下载好，按默认安装即可（推荐安转在D盘中）。安装完成后，在开始菜单里找到“Git”->“Git Bash”，双击蹦出一个类似命令行窗口的东西，


输入git --version显示版本（也可以在cmdDOS窗口中测试），就说明Git安装成功！

1.5、Git配置

完成后在命令行输入：

$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"

因为Git是分布式版本控制系统，所以每个分支都要有自己的名字和邮箱，
注意git config命令的--global参数，用了这个参数，表示你这个分支上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

查看配置信息：
要检查已有的配置信息，可以使用 git config --list 命令：

$ git config --list

也可以单独查看某项配置：

$ git config user.name
$ git config user.email

1.6、Git 工作流程

一般工作流程如下：

• 克隆Git资源作为工作目录；
• 在克隆的资源上添加或修改文件；
• 如果其他人更改，你可以更新资源；
• 在提交前查看修改状态；
• 提交修改；
• 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

工作流程图：

1.7、Git 工作区、暂存区和版本库

我们先来理解下 Git 工作区、暂存区和版本库概念：

• 工作区： 就是你电脑里能看到目录；
• 暂存区： stage或index，一般放在.git(可隐藏文件)目录下的index文件（.git/index）中，所以我们把暂存区有时候也叫做索引（index）；
• 版本库： 工作区有一个隐藏目录，.git，这个实际上是Git的本地版本仓库。

工作区、版本库中的暂存区和版本库之间的关系：

• 左侧为工作区，右侧为版本库。在版本库中标记为“index”的区域是暂存区（stage/index），标记为“master”的是master主分支代表的目录数。
• HEAD实际上是指向master主分支的一个“游标”。
• 图中的objects标识的区域为Git的对象库，实际位于“.git/objects”目录下，里面包含了创建的各种对象及内容。
• 当工作区进行修改（或新增）的文件执行git add命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库（此时的对象库可以认为是暂存区中的对象库）中的一个新的对象中，而该对象的ID被记录在暂存区中的文件索引中。
• 当执行提交操作git commit时，暂存区的目录树就被提交到版本库中的对象库（objects）中，master主分支会做相应的更新。即master指向的在暂存区提交过来的目录树。
• 因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
• 可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

二、Git基本命令操作

2.1、创建版本库

什么是版本库？版本库又名仓库，英文名Repository，你可以简单成一个目录，这个目录里面的所有文件都被Git管理起来， 每个文件的修改、删除，Git都可以跟踪到，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

首先我们选择一个合适的位置，创建一个gitspace空目录(可选)，用作以后存储和创建本地版本仓库，在gitspace中创建一个learngit空目录，并切入：

$ mkdir learngit    #创建
$ cd learngit       #切换
$ pwd               #显示当前盘符路径
/d/gitspace/learngit

如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）均不包含中文。

然后通过git init命令把这个目录变成Git可以管理的仓库：

$ git init
Initialized empty Git repository in D:/gitspace/learngit/.git/

瞬间Git仓库就建好了，而且告诉你这是个空仓库（empty Git repository），打开learngit目录可以发现多了一个.git目录，这个目录是Git用来跟踪管理版本仓库的，千万不要乱修改和删除这个目录中任意文件，否则这个git仓库就被你破坏了。

如果你看不到这个.git文件，使用命令ls -ah就可以看到隐藏的文件了。

2.1.1、把文件添加到版本库

首先说明一下，所有的版本控制系统，其实只能跟踪到文本文件的改动，比如txt文件、网页、程序代码等等，Git也不例外。版本控制系统可以记录你每次的改动，比如在第5行添加了一个单词“linux”，在第八行删除了一个单词“windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但是却补能跟踪二进制文件的细致改动，只能把二进制文件每次串起来，也就是只知道图片或视频从100KB改成了200KB，但是到底改了啥，版本控制系统不知道，也没办法知道。

还有Mcrosoft的Word格式就是二进制的，因此版本控制系统是没法跟踪到Word文件的细致改动的，上述我们举的栗子只是为了演示，如果要真正使用版本控制系统，就要以纯文本的方式编写文件。

因为文本是有编码的，比如中文中有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台支持。

2.1.2、创建一个文件readme.txt

#在当前目录创建一个文件
$ touch readme.txt  （linux中的新建文件命令）

$ vim readme.txt    #编辑该文件

#在编辑页面按 i 键进入编辑状态，添加如下两行内容：

Git is a version control system.
Git is free software.

然后esc退出编辑，输入:wq回车，保存并退出

$ cat readme.txt   #查看当前文件的内容
Git is a version control system.
Git is free software.

2.1.3、将文件提交到本地git版本仓库中（两步走战略）

查看当前状态：

$ git status      #查看当前git状态(新建了一个文件)

第一步add到暂存区：

$ git add readme.txt      #添加到暂存区

再查看状态：

$ git status        #查看当前git状态(readme.txt被添加到暂存区)

第二步commit到本地版本仓库

$ git commit -m "wrote a readme file"

然后再再次查看状态（没有可提交的文件）：

简单解释下git commit -m "记录提交内容"命令，-m 后面写的是本次提交的记录内容，当然最好是有意义的，这样就能从历史记录中清楚的知道每次的改动的内容和操作。当然也可以不写，但是对于你自己可能清楚你每一步都干了啥（前提还是提交此处不是很多的时候），如果你在团队开发中做了提交不写记录内容，别人就没办法知道你做了哪些修改操作，所以说可读性非常重要,记录内容是必要的！！！

为什么Git提交文件需要两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件：

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

2.2、版本回退

上述我们学会了修改文件内容，再次修改内容为如下,并提交大本地版本仓库：

Git is a distributed version control system.
Git is free software distributed under the GPL.

$ vim readme.txt       #修改内容
$ git add readme.txt   #添加到缓存区
$ git commit -m "append GPL"  #提交到版本库

现在，我们回顾一下readme.txt文件一共有几个版本被提交到Git仓库里了：

版本1：wrote a readme file

Git is a version control system.
Git is free software.

版本2：append GPL

Git is a distributed version control system.
Git is free software distributed under the GPL.

在实际工作中我们肯定会经常看历史记录，使用git log命令：

$ git log  #查看日志记录
commit 4f489e74cdbcf902117a49fdf8c5f6a516ee2fb3 (HEAD -> master)
Author: yixiujun <1845192312@qq.com>
Date:   Fri Aug 13 10:00:46 2021 +0800

    append GPL

commit 0931364dad8d1a6601b4270a94418299f70f2de5
Author: yixiujun <1845192312@qq.com>
Date:   Fri Aug 13 09:40:55 2021 +0800

 	wrote a readme file

git log命令显示从最近到最远的提交日志，我们可以看到2次提交，最近的一次是append GPL，第一次是wrote a readme file。

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数（但是不建议使用）：

$ git log --pretty=oneline
4f489e74cdbcf902117a49fdf8c5f6a516ee2fb3 (HEAD -> master) append GPL
0931364dad8d1a6601b4270a94418299f70f2de5 wrote a readme file

我们所看到的的一大串4f489e74cdbcf902117a49fdf8c5f6a516ee2fb3的是commit id（版本号）和SVN的不同，Git的版本号不是1、2 、 3。。。递增的数字，而是有SHA1计算得出的一个非常大的十六进制数字，每个版本号不会重复。为什么使用十六进制表示版本号，因为Git是分布式的版本控制系统，每个人在各自的版本库例工作，如果大家都使用1、 2 、3。。。这样的数字，最后合并的时候肯定会冲突。

那啥我们现在需要回到第一个版本wrote a readme file :

$ git reset --hard HEAD^
HEAD is now at 0931364 wrote a readme file

查看readme.txt内容：

$ cat readme.txt
Git is a version control system.
Git is free software.

这个时候我们再查看日志记录：

$ git log
commit 0931364dad8d1a6601b4270a94418299f70f2de5 (HEAD -> master)
Author: yixiujun <1845192312@qq.com>
Date:   Fri Aug 13 09:40:55 2021 +0800

    wrote a readme file

最新的那个版本append GPL已经看不到了！好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，咋整？

莫慌有办法，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是4f489e74cdbcf902117a49fdf8c5f6a516ee2fb3，于是就可以指定回到刚才那个算是未来的某个版本：

$ git reset --hard 4f489e74
HEAD is now at 4f489e7 append GPL

版本号没必要写全，前8位基本就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。

再次查看日志：

$ git log
commit 4f489e74cdbcf902117a49fdf8c5f6a516ee2fb3 (HEAD -> master)
Author: yixiujun <1845192312@qq.com>
Date:   Fri Aug 13 10:00:46 2021 +0800

    append GPL

commit 0931364dad8d1a6601b4270a94418299f70f2de5
Author: yixiujun <1845192312@qq.com>
Date:   Fri Aug 13 09:40:55 2021 +0800

    wrote a readme file

哎日志记录又回来了，赶紧再次查看文件内容：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.

哎内容也回来了，你就说爽不爽！好玩不！呆发不！

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向wrote a readme file：

刚才上述我们在未关闭的窗口中可以找到最新版本的append GPL的commit id，但是如果我们关闭了窗口咋办，咋整，莫慌，还要一个命令git reflog，可以展示你每次的命令：

$ git reflog
4f489e7 (HEAD -> master) HEAD@{0}: reset: moving to 4f489e74
0931364 HEAD@{1}: reset: moving to HEAD^
4f489e7 (HEAD -> master) HEAD@{2}: commit: append GPL
0931364 HEAD@{3}: commit (initial): wrote a readme file

小结：

• 想回退历史： git log命令查看以便回到哪个版本；
• 想重返未来版本： git reflog命令查看每个版本的commit id，直接git reset --hard commit_id即可。

2.3、Git的管理与修改

为什么说Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。

你会问，什么是修改？比如：

• 你新增了一行，这就是一个修改；
• 删除了一行，也是一个修改；
• 更改了某些字符，也是一个修改；
• 删了一些又加了一些，也是一个修改；
• 甚至创建一个新文件，也算一个修改。

实例操作演示：

我们仍然对readme.txt文件做修改，添加两行新内容：

$ vim readme.txt  #修改添加内容
$ cat readme.txt  #查看新添了两行内容
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

然后将readme.txt添加到暂存区git add:

$ git add readme.txt     #添加到暂存区
$ git status    #当前状态是修改了，并在暂存区，待提交
On branch master
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        modified:   readme.txt

这个时候我们先不提交readme.txt，而是再做一次修改，将最后一行内容稍作修改，如下：

$ vim readme.txt    #修改最后一行内容
$ cat readme.txt    #查看当前内容（确实修改了）
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

白眨眼，这个时候我们不再添加到暂存区了，而是直接git commit提交到本地版本仓库：

$ git commit -m "git tracks changes"
[master bf9deee] git tracks changes
 1 file changed, 2 insertions(+)

查看状态：

$ git status
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

仔细看，你会发现上述我们明明提交了，然后文件仍然是处于修改的状态，原因就是因为我们第二次做的修改没有添加到暂存区中，git commit命令没有追踪到待提交的第二次修改内容。

回顾下刚才的过程：
第一次修改->git add->第二次修改->git commit

这个时候我们使用一个新命令git diff HEAD -- readme.txt（注意中间的空格），来对比我们此时工作区和git本地版本仓库中的readme.txt文件的区别：

$ git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
 Git is a distributed version control system.
 Git is free software distributed under the GPL.
 Git has a mutable index called stage.
-Git tracks changes.
+Git tracks changes of files.

我们发现第二次修改确实没有提交上去，就是因为第二次修改没有添加到暂存区中，那怎么将第二次修改提交到本地版本仓库呢？

莫慌，你可以直接接着git add,然后git commit在，这样就提交了；然后还有一种方法就是，在每次修改后都将文件添加到暂存区中，最后一总提交，方便高效，如下流程：

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

到这我们应该对于Git的管理了解的更深入了点，咱们接着走！

2.4、Git撤销修改

2.4.1、撤销工作区的修改

如果说你在工作区对readme.txt做了修改，添加了一行内容：

$ vim readme.txt   #做修改，在最后添加一行内容
$ cat readme.txt   #查看内容（最后一行）
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

查看内容，确实修改了添加了最后一行，当你准备添加暂存区，然后提交的时候，你突然想起来，这句胡话My stupid boss still prefers SVN.，可不是闹着玩类，一旦提交上去，我想你就完犊子了，所以你想撤销这句的修改，怎么办？先git status查看当前状态：

$ git status
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

很好，git表明了，如果你不想提交，可以使用git restore file命令撤回操作，也可以使用git checkout -- file命令这两个命令作用是一样的，但是我们推荐使用前者，因为checkout后续我们在分支管理上经常用到，经常用到，而且中间要加上--,否则意思是切换到指定分支，以防使用混乱，还是使用restore更为方便些：

$ git restore readme.txt
$ git  status   #查看当前状态
On branch master
nothing to commit, working tree clean

查看当前文件内容：

$ cat readme.txt  #发现最后一行撤销了
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

命令git restore readme.txt和命令git checkout -- readme.txt的作用就是将readme.txt文件在工作区做的修改全部撤回，其实此处有两种情况：

• 第一种：readme.txt修改后还没放到暂存区，现在，可以直接撤回到与版本库中的readme.txt一样的状态；
• 第二种：readme.txt做了两次修改，第一次修改添加到暂存区了，第二次修改没有添加，现在，撤回的是第二次在工作区的修改，回到的状态是第一次修改添加到暂存区后的状态，也就是说这个撤回命令不能够撤回已经添加到暂存区的内容。

总之，就是让这个文件撤回到最近一次的git add或git commit后的状态。

2.4.2、撤销暂存区的修改

假设现在是凌晨3点，你不但写了一些胡话，而且还git add到暂存区了：

$ vim readme.txt     #再次编辑再加上最后一句胡话
$ cat readme.txt     #查看内容（添加了）
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

然后你就手一抖，将readme.txt添加到了暂存区，查看状态：

$ git add readme.txt    #添加到暂存区
$ git status       #查看状态
On branch master
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        modified:   readme.txt

此时此刻，你就说心里慌不慌，慌！
莫慌，只要还没提交一切都还来得及，这时候就又来了一个命令git restore --staged file，上述状态中也告诉我们了，该命令可以将文件的修改从暂存区撤销回工作区修改时的状态,并没有一步到位的撤销完全，（当然git reset HEAD file命令也可以实现暂存区撤销，退回到工作区，但是为了区分reset主要是为了回退版本，所以此条命令不推荐），然后再次查看状态：

$ git restore --staged readme.txt     #从暂存区撤回，退回到工作区状态

$ git status    #再次查看状态
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   readme.txt

可以看到，文件当前的状态只是在工作区还处于修改的状态，此时既可以继续添加到咱出去怒，也可以撤销，我想只要你不傻，就不会再添加到暂存区了吧（毕竟刚从暂存区撤回来），然后我们就把工作区的修改也撤回，再次查看状态：

$ cat readme.txt   #先查看下当前的内容（确实还处于修改的状态）
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.


$ git restore readme.txt   #撤回工作区的修改
$ git status    #查看状态（发现没有待提交和处于修改状态的文件了）
On branch master
nothing to commit, working tree clean

$ cat readme.txt    #再次查看当前文件的内容（发现胡话没有了，于是你再次仰天大笑）
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

小结：

• 撤回工作区修改命令：

  git restore readme.txt（推荐）
git check -- readme.txt（也可以，但是不推荐）

• 撤回暂存区修改命令：

  git restore --staged readme.txt（推荐）
git reset HEAD readme.txt（也可以，但是不推荐）

  • 注意：从暂存区撤回后，工作区的也要接着撤回

    git restore readme.txt

2.5、Git删除文件（重点理解）

我们上述说了，在Git中，删除也是一个修改操作，我们先添加一个新文件test.txt，并提交到Git本地版本仓库：

$ touch test.txt   #新建文件(内容可以什么都不写)

$ git add test.txt   #添加到暂存区
$ git commit test.txt  #提交到版本仓库
$ git status   #查看状态（没有待提交的文件了）
On branch master
nothing to commit, working tree clean

2.5.1、从工作区中删除（rm file）

此时，在你的工作区和版本仓库中都有test.txt文件,而且一模一样，我们一般从文件管理器中把没用的文件删了，或者用rm命令删了：

$ rm test.txt   #只是删除工作区的test.txt文件

这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        deleted:    test.txt

no changes added to commit (use "git add" and/or "git commit -a")

可以看出，工作区test.txt文件被删除了，这时候，如果你是删错了，想撤回，没问题，因为你只是在工作区中删除了test.txt文件，版本库中仍然存在，使用命令git restore test.txt（推荐）和命令git checkout -- test.txt（不推荐），都可以撤回删除的test.txt文件；

撤回工作区的删除操作：

$ git restore test.txt  #撤回删除的test.txt文件

$ ls   #查看当前目录下的所有文件和子目录
readme.txt   test.txt（确实又回来了）

2.5.2、工作区和版本库中同时删除（git rm file）

但是如果你是真心想删除这个文件，版本库中也要删除，那就使用命令git rm test.txt，注意在删除后，未提交的时候，是可以撤回的，一旦提交，工作区和版本库中将被删除。

git rm删除但未提交（工作区和版本库中的文件同时被删除）

$ git rm test.txt   #同时删除版本库和工作区中的test.txt文件

特别注意：（增、删、改都要经过暂存区）
git rm test.txt命令执行后，切记是还未提交时，其实也是将test.txt添加到了暂存区中了，这时候如果是误删了，先查看当前状态，git status如果未提交，可以使用git restore --staged test.txt从暂存区中撤回删除（其实这一步有两个作用，一是恢复版本仓库中的test.txt，二是将文件退回工作区的删除状态），将test.txt文件退回到在工作区中删除的状态，因为这个时候版本库中的文件已经恢复了，所以就可以使用git restore test.txt命令或者git checkout -- test.txt命令撤回工作区的删除修改（实质是从版本库中克隆了一份），文件再次恢复。

git rm test.txt删除后，git commit -m "del test.txt"将删除修改提交到版本库中，版本库中也被删除了：

$ git rm test.txt  #同时删除工作区和版本库中的test.txt，此时是将删除修改添加到了暂存区中

$ git commit -m "commit del test.txt"  #这一步一提交到版本库中，说明是提交了删除事务

git commit -m "commit del test.txt" #这一步一提交到版本库中，说明是提交了删除事务,再使用撤销命令git restore test.txt和git checkout -- test.txt，无法恢复，因为这俩命令只能在版本库中还存在的情况下使用；而且命令git restore --staged test.txt也不会生效，因为已经commit提交了，所以暂存区中也就不存在了，所以撤销暂存区命令自然也就失效了。

小结：

先手动删除文件rm file，然后使用git rm file和git add file效果是一样的都是将其添加到暂存区中。


从来没有被添加到版本库就被删除的文件，是无法恢复的！

如果执行了git rm file和git commit -m "record"，使用版本回退命令git reset --hard commit_id是可以回复删除的文件的，只不过会丢失最近一次提交过程中所修改的内容。

三、Git基本操作总结

3.1、Git的工作就是创建和保存你的项目的快照及与之后的快照进行对比。

3.2、Git常用的6个命令：

• git clone
• git push
• git add
• git commit
• git checkout
• git pull

关系图示：

说明：

• workspace：工作区
• staging area：暂存区/缓存区
• local repository：版本库或本地仓库
• remote repository：远程仓库

3.3、基础命令说明

创建仓库命令

命令	说明
git init	初始化仓库
git clone	拷贝一份远程仓库，也就是下载一个项目
提交与修改
命令	说明
–	–
git add	添加文件到暂存区
git status	查看仓库当前的状态，显示有变更的文件
git diff	比较暂存区和版本库中文件的差异
git commit	提交暂存区到本地仓库
git reset	回退版本
git rm	删除工作区和版本库中的文件
git mv	移动或重命名工作区文件
提交日志
命令	说明
–	–
git log (–pretty=oneline)	查看历史提交记录(后者代表每个记录在一行显示)
git blame file	以列表形式查看指定文件的历史修改记录
远程操作
命令	说明
–	–
git remote	远程仓库操作
git fetch	从远程获取代码库
git pull	拉取下载远程代码并合并
git push	将本地代码上传至远程仓库并合并

---

一起学编程，让生活更随和！如果你觉得是个同道中人，欢迎关注博主公众号：【随和的皮蛋桑】。专注于Java基础、进阶、面试以及计算机基础知识分享。偶尔认知思考、日常水文。