git分布式版本控制系统

git 命令操作示意图

1. 软件测试

右键菜单

选择Git Bash Here，输入任意一条后回车来查看当前Git软件的安装版本。

git -v
git --version

2. git的基础使用

2.1 区域

Git软件为了更方便地对文件进行版本控制，根据功能得不同划分了三个区域

存储区域：Git软件用于存储资源得区域。一般指得就是.git文件夹
工作区域：Git软件对外提供资源得区域，此区域可人工对资源进行处理。
暂存区：Git用于比对存储区域和工作区域得区域。Git根据对比得结果，可以对不同状态得文件执行操作。

2.2 Git基础指令

Git软件是免费、开源的。最初Git软件是为辅助 Linux 内核开发的一套软件，所以在使用时，简单常用的linux系统操作指令是可以直接使用的

2.2.1 linux系统操作指令

2.2.2 Git软件指令

2.2.2.1 配置信息

作为一个工具软件来讲，一般都会有默认的配置文件来保存基础的配置信息，Git软件的配置文件位置为：Git安装路径/etc/gitconfig

我们可以通过指令获取软件的配置信息：git config -l

2.2.2.2 名称和邮箱

如果是第一回使用Git软件，需要告诉Git软件你的名称和邮箱，否则是无法将文件纳入到版本库中进行版本管理的。
输入相关指令:

git config --global user.name Muko
git config --global user.email txk0x7d2@163.com

2.2.2.3 初始化版本库

我们需要指定某一个文件目录作为软件的管理目录。因为这个目录主要就作为Git软件的管理文件的版本变化信息，所以这个目录也称之为Git软件的版本仓库目录。

具体操作过程如下：

我们首先通过指令进入到指定文件目录（也可以直接进入该文件夹）
cd /e/git/gitTest
执行指定的指令，创建文件版本库
git init
版本库创建成功后，会在目录中创建.git目录，用于管理当前版本库。

2.2.2.4 向版本库中添加文件

虽然创建了版本库，但是现在版本库中还没有任何的文件，所以这里我们先手动创建文件：test.txt

因为文件已经放置在版本库中了。所以可以通过软件的指令查看版本库状态
git status

此时会发现，test.txt文件属于untracked files（未追踪文件）,这里表示当前的test.txt文件虽然放置到了版本库的文件目录中，被Git软件识别到了，但是未纳入到版本库管理中。所以属于未追踪文件。通过这个现象可以认为，系统文件夹物理目录和版本库管理目录的含义是不一样的。只有文件被纳入到版本库管理后，Git软件才能对文件修改后的不同版本内容进行追踪处理，也就是所谓的tracked files了。那么如何将文件纳入到版本库的管理呢，这就需要我们执行以下命令了：
git add test.txt

文件要带扩展名

此时你再查看版本库状态，就会发现文件状态的变化。

此时文件状态为cached file，这也是Git管理文件时的一种状态：暂存状态。就是我们生活中常说的草稿状态。也就是说对于Git来讲，它认为此时文件只是一种临时草稿状态，随时可能会进行修改或删除，并不算真正的操作完成状态。所以并不会把文件纳入到版本库管理中。

如果确定要把文件放置在版本库中，那么就需要执行确定提交指令。

# commit表示真正地纳入到版本库中
# -m 表示提交时的信息（message），是必须输入的。用于描述不同版本之间的差别信息
git commit -m "my first git file"

再查看Git状态

提交后，Git会对当前的操作进行Hash计算，通过计算后的值将数据保存下来，保存的位置为版本库.git文件目录的objects中，我们可以通过指令查看当前提交
git show

由于文件内容进行了转换处理，直接打开你是看不懂的

2.2.2.5 修改版本库文件

现在文件已经被纳入到版本库中，因为咱们的文件是空的，所以这里我们增加一些内容

此时，Git版本库中的文件和本地的文件就有了不同。我们可以查看状态

modified 表示文件已经修改了，我们可以把这一次的修改提交到版本库中

原则上来讲，这里的操作顺序依然应该是：

# 先增加，再提交
git add test.txt
git commit

但是这里我们简化了一下操作
git commit -a -m "update file"

这个指令操作中多了一个-a的参数，等同于将增加，提交两步操作融合成了一步。

提交成功后，我们来展示以下当前Git软件库

2.2.2.6 查看版本库文件历史

版本库中的文件我们已经修改并提交了，那么文件的版本信息就会发生变化，那我们如何来查看这个变化呢？这里我们可以采用log指令进行查看
git log

如果感觉看着不舒服，也可以美化一下显示方式:
git log --pretty=oneline

也可以使用简单方式查看
git log --oneline

就是把版本号缩写了，只展示了前7位16进制版本号

2.2.2.7 删除文件

一般情况下，Git软件就是用于管理文件的版本变更，但是在一些特殊的场景中，文件可能作废或不再使用，那么就需要从版本库中删除，记住，这里说的并不是从物理文件目录中删除，而是从版本库中删除。

将本地文件从目录中删除
查看Git版本库状态信息

此时Git软件会识别出来，版本库中有一份文件和当前用于临时操作文件的暂存区内的文件状态不一致：版本库中文件还在，但是操作区内的文件已经没有了。所以软件提供了两个选择：一个是将版本库中的文件也进行（提交）删除操作。另外一个就是从版本库中恢复文件。
使用指令从版本库中恢复文件
git restore test.txt
如果想要真正删除文件，那么也要将版本库中同时删除
此时查看Git日志

2.2.2.8 恢复历史文件
版本库管理的是文件不同版本的变更操作，这个不同版本的概念还是非常重要的。也就是说，最后的那个删除的文件版本已经没有了，但是之前版本的文件其实还是存在的。所以如果我们能将文件恢复到某一个版本，那么那个版本的文件就依然存在。
查看版本库信息
将版本库文件重置到某一个版本

这里的9416d2f就是版本Hash值，用于唯一确定版本库中此版本的标记

当然了这是一个简短版，完整的比较长

如果不记得具体的版本值，版本值也可以使用HEAD值，比如最新的上一个版本：HEAD^

如果后退更多的版本,可以使用 HEAD~N

git reset --hard 9416d2f

3. Git进阶使用

将本地测试环境和服务器测试环境区分开，分别进行文件版本维护。这个操作，在Git软件中，我们称之为branch，分支。

这里的分支感觉上就是树上的分叉一样，会按照不同的路线生长下去。有可能以后不再相交，当然，也可能以后会不断地纠缠下去，都是有可能的。

3.1 Git分支

3.1.1 主干分支

默认情况下，Git软件就存在分支的概念，而且就是一个分支，称之为master分支，也称之为主干分支。

这就意味着，所有文件的版本管理操作都是在master这一个分支路线上进行完成的。

默认的所有操作本身就都是基于master分支完成的。而master主干分支在创建版本库时，也就是git init时默认就会创建。

3.1.2 其他分支

就像之前说的，如果仅仅是一个分支，在某些情况并不能满足实际的需求，那么就需要创建多个不同的分支。

3.1.2.1 创建分支

# git branch 分支名称
git branch b1
git branch b2

现在我们创建了2个分支，不过这两个分支都是基于master主干分支为基础的。

3.1.2.2 查看分支

git branch -v

3.1.2.3 切换分支

我们将工作线路切换到b1

git checkout 分支名称

git checkout b1

此时我们添加新的文件b1.txt
然后提交到版本库
此时，查看分支信息，会发现不同分支的版本进度信息发生了改变
如果此时切换回到主干分支的话，那么b1.txt文件就不存在了，因为对应版本信息不一样。

3.1.2.4 删除分支

如果觉得某一个分支建立的不太理想或已经没有必要在使用了，那么是可以将这个分支删除的。

# git branch -d 分支名称
git branch -d b2

3.2 Git合并

无论我们创建多少个分支，都是因为我们需要在不同的工作环境中进行工作，但是，最后都应该将所有的分支合在一起。形成一个整体。作为项目的最终结果。

3.2.1 主干分支

首先我们先将主干分支的所有文件清空掉
在当前主干分支中创建一份文件master.txt，并提交

3.2.2 其他分支

基于主干分支的内容，我们创建其他分支，并直接切换到新的分支

# git checkout -b 分支名称
git checkout -b new_branch

在新的分支中添加新文件branch.txt
此时切换回主干分支，只有master.txt文件。
再切换回new_branch分支，branch文件就又回来了。

3.2.3 合并分支

这里我们将new_branch分支的文件内容合并到主干分支中。首先先切换回主干分支
然后执行分支合并指令

git merge 分支名称

git merge new_branch

此时再次查看文件，就会发现branch.txt文件已经可以看到了。

3.3 Git冲突

在多分支并行处理时，每一个分支可能是基于不同版本的主干分支创建的。如果每隔分支都独立运行而不进行合并，就没有问题，但是如果在后续操作过程中进行合并的话，就有可能产生冲突。比如B1, B2的两个分支都是基于master分支创建出来的。B1分支如果和B2分支修改了同一份文件的话，那么在合并时，以哪一个文件为准呢，这就是所谓的冲突。