Git的基本使用

为什么要编写这个教程？因为我在学习 Git 的过程中，在网上找了一堆 Git 相关的文章和教程，感觉都有点差强人意，那就自己写一个自己能看的懂的记录下来，方便以后自己在使用过程出现遗忘问题时能快速找到解决方案。

首先，本教程绝对面向初学者，没有接触过版本控制概念的读者也可以轻松入门，不必担心起步难度，因为我就是初学者！

其次，本教程出自一个初学者，难免会有不恰当的地方，如果您有幸看到我的这篇文章并发现了问题，欢迎您留言指出。

## Git 简介

Git 是什么？Git 是目前世界上最先进的分布式版本控制系统。

说到这里就不得不提分布式版本控制系统。先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件 A，你的同事也在他的电脑上改了文件 A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。当然，Git 的优势不单是不必联网这么简单，后面我们还会看到 Git 极其强大的分支管理。

## Git 安装

安装直接到[官网](https://git-scm.com/downloads)下载对应的版本就行。基本不会有什么问题，这篇文章着重于使用和理解。也可以参考这个[教程](https://www.runoob.com/git/git-install-setup.html)windows 安装完成之后在任一目录下右键查看是否有 GitBash Here，若有则证明安装成功，以后的命令都可以在 Git Bash Here 里面运行。

## 版本库

什么是版本库呢？版本库又名仓库，英文名 repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被 Git 管理起来，每个文件的修改、删除，Git 都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。首先你要学会创建一个本地仓库，你可以在命令行新建一个文件夹(learngit)，然后进入进行管理。

```

mkdir learngit

cd learngit

git init

```

git init 命令把这个目录变成 Git 可以管理的仓库。瞬间 Git 就把仓库建好了，而且告诉你是一个空的仓库（empty repository），然后你可以发现当前目录下多了一个.git 的目录，这个目录是 Git 来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把 Git 仓库给破坏了。接下来你需要明白工作区、暂存区、版本库。工作区就是你创建的目录里面所能看到的(不包括.git)，暂存区和版本库相对来说是不可见的，这个说法只是便于理解，其实他们在自动生成的.git 文件夹里面会有相应的操作记录。

### 文件的添加和删除

刚开始仓库是空的，然后你在工作区写了一个 a.txt 文件，此时这个文件只存在于你的工作区，那么如何将它添加到你的版本库里面呢？首先需要将 a.txt 文件添加到缓存区,然后提交到版本库

```

git add a.txt

git commit -m '添加了a.txt文件'

```

其中 add 后可跟目录名和文件名，如果要添加工作区的所有文件，也可以添加工作区的所有文件，对应代码如下

```

git add 目录名

git add 文件名

git add .

```

当然也可以一次添加多个指定的文件，用空格隔开就行。删除文件同理，只需将 add 替换为 rm 即可。对于工作区的文件，如果不确定其状态，可以通过下面代码来查看其状态

```

git status

```

然后我们分析一下各种情况。当你刚执行完 commit 操作，暂存区是空的时，输入命令会提示你 working tree clean；当你修改了工作区的文件之后再使用 status 命令则会显示文件已修改，并提醒你提交到版本库；当你新增了文件的时候，会提醒你工作区有未追踪的文件，然后提醒你将新文件提交到版本库；当你删除了文件，会提醒你工作区有文件被删除，并提示你更新到版本库。

### 错误修改的补救

当然我们不可避免的会有错误的修改，当我们对 a.txt 文件进行了一次错误的修改，怎么撤回修改呢，具体情况有以下三种：

① 只在工作区做了修改，还未添加至缓存区，此时可以使用下面这个命令将工作区回到最近一次 add 或者 commit 的状态。(工作区误删恢复也可以用这个命令)

```

git checkout -- a.txt

```

② 你做了错误的修改并且已经提交到了缓存区，需要先撤销暂存区的修改，然后就回到了第一种情况。

```

git reset HEAD a.txt

```

③ 如果你已经进行了 commit 提交，那么你只需回退到上一个版本库即可，版本回退下面会细讲。

### 版本管理

对版本库的历史版本管理，使用以下命令查看提交记录。然后会由近到远以此显示你的提交记录，然后通过给出的 commit id 回到指定版

本，当然也有另一种指令，快捷的回退到前 n 个版本，其中 n 与^的数量相对应。

```

git log

git reset --hard  57aa6817806ad984484

//回退到commit id 为57aa6817806ad984484的版本

git reset --hard HEAD^

//回退到上一个版本

```

然后你的工作区和版本库就会是你想要的版本。commit id 不用写全只要写到唯一位就行。如果觉得 git log 显示的信息太繁琐，可以加上参数 --pretty=oneline 只会显示版本号和提交时的备注信息，这样阅读起来更友好得多。这时又有一个问题，假设你有按顺序的三个版本 a，b，c，你从 c 版本回到了 b 版本，你在使用 git log 命令会不显示你的 c 版本的 commit，这是你如果想要再次回到 c 版本，应该怎么做呢？这是需要用到下面这个命令，就可以看到 commit id 了，然后再执行回退命令就可以了。

```

git reflog

```

这里我们就能看出两者的区别，查过资料得到证实，git log 命令可以显示当前分支所有提交过的版本信息，不包括已经被删除的 commit记录和 reset 的操作。(注意: 只是当前分支操作的信息)。git reflog 命令可以查看所有分支的所有操作记录信息（包括已经被删除的commit 记录和 reset 的操作）。

总结一下:

Git 允许我们在版本的历史之间穿梭，使用命令 git reset --hard commit_id。

穿梭前，用 git log 可以查看提交历史，以便确定要回退到哪个版本。

要重返未来，用 git reflog 查看命令历史，以便确定要回到未来的哪个版本。

## 分支

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习前端的时候，另一个你正在另一个平行宇宙里努力学习后端。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你就成了全栈工程师。

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

在版本回退里，我们已经知道，每次提交，Git 都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在 Git里，这个分支叫主分支，即 master 分支(从 2020 年 10 月 1 日开始，Github 将所有“master 分支”一律改名为“main 分支”，注意识别)。HEAD 严格来说不是指向提交，而是指向 master，master 才是指向提交的，所以，HEAD 指向的就是当前分支。

一开始的时候，master 分支是一条线，Git 用 master 指向最新的提交，再用 HEAD 指向 master，就能确定当前分支，以及当前分支的提交点。

每次提交，master 分支都会向前移动一步，这样，随着你不断提交，master 分支的线也越来越长。当我们创建新的分支，例如 dev 时，Git 新建了一个指针叫 dev，指向 master 相同的提交，再把 HEAD 指向 dev，就表示当前分支在 dev 上。Git 创建一个分支很快，因为除了增加一个 dev指针，改改 HEAD 的指向，工作区的文件都没有任何变化！不过，从现在开始，对工作区的修改和提交就是针对 dev 分支了，比如新提交一次后，dev 指针往前移动一步，而 master 指针不变。

假如我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上。合并完分支后，甚至可以删除 dev 分支。删除 dev 分支就是把 dev 指针给删掉，删掉后，我们就剩下了一条 master 分支。

### 分支的创建、切换与合并

首先，我们创建 dev 分支，然后切换到 dev 分支，其实这个代码相当于两行代码，先创建再切换分支。其中，git checkout 命令我们在前面

的恢复文件时也用到了，为了作区分，建议使用 switch 进行分支的切换。

```

git checkout -b dev

git switch -c dev

//等同于下面两行代码

git branch dev

git checkout dev

```

然后，用 git branch 命令查看分支

```

git branch

//当前分支前面会有一个*

```

切换到 dev 分支以后我们就可以在 dev 分支上正常提交，等到提交之后，再回到 master 合并 dev，然后就可以删掉 dev 分支了。

```

git merge dev

//在master分支上合并dev

git branch -d dev

//删除dev分支

```

### 合并冲突的解决

当 Git 无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把 Git 合并失败的文件手动编辑为我们希望的内容，再提交。

### 恢复误删的分支

如果你在分支上做了提交并且没有合并到主分支上就被你删了，可以先找到 commit id，然后恢复误删的分支。

```

git log -g

//找到误删分支上的commit id

git branch newbranch commit id

//恢复分支

git switch newbranch

//切换到恢复的分支

```

## 远程仓库

下载完 Git，安装教程里面有配置的教程，配置完成之后可以通过命令查看绑定的远程仓库，可以删除绑定，添加绑定。

```

git remote -v

//查看绑定的远程仓库信息，没有绑定就是空白，有绑定会显示名字

git remote add 仓库名 仓库地址

//绑定远程仓库

git remote rm origin

//删除绑定的远程仓库，origin为远程仓库名，远程仓库名在本地的名称默认都为origin

git clone 仓库地址

//从远程仓库克隆项目

git push origin master

//将本地master分支推向远程仓库，注意Github现在将默认分支master改为了main

```