1. 版本控制系统简介
1.1 集中式版本控制系统
集中式版本控制系统，版本库是集中存放在中央服务器的，团队中每个成员工作时从中央服务器下载代码（必须联网才能工作，局域网或互联网），个人修改后再提交到中央服务器中。典型的有 SVN（subversion）和 CVS（Concurrent Version System）。
架构图：
1.2 分布式版本控制系统
分布式版本控制系统没有中央服务器的概念，每个人的电脑上都是一个完整的版本库，这样工作的时候，无需要联网，因为版本库就在本地电脑上。多人协作只需要各自修改推送给对方，即可互相看到对方的修改。典型的有 Git（目前使用最多、最先进的分布式版本控制系统）。
架构图
1.3 比较
分布式版本控制系统不需要联网，集中式版本控制系统需要联网。
集中式版本控制系统会造成公共服务器压力和数据量很大，分布式则不会。
分布式版本控制系统速度比集中式快，更加灵活。
分布式版本控制系统可以很容易版本解决冲突。
总之，分布式版本控制系统优点诸多，适合当前数据量急剧增加，工程特别大的项目版本管理需求，使用范围比集中式版本控制系统更广泛。
2. Git 介绍
Git 是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Git 的工作流程：
操作&解释：
| 操作 | 解释 |
| clone(解释) | 从远程仓库中克隆代码到本地仓库 |
| checkout(检出) | 从本地仓库中检出一个仓库分支然后进行修订 |
| add(添加) | 在提交前先将代码提交到暂存区 |
| commit(提交) | 提交到本地仓库，本地仓库中保存修改的各个历史版本 |
| fetch(抓取) | 从远程库抓取到本地仓库，不进行任何的合并动作，一般操作比较少 |
| pull(拉取) | 从远程库拉到本地库，自动进行合并（merge），然后放到工作区，相当于 fetch+merge |
| push(推送) | 修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库 |
3. Git 安装
在 git 官网进行下载，根据不同的操作系统平台下载相应的 git. 例如，我使用的是 windows 操作系统，可以看到最新的发行版本为 2.35.1，点击链接进行下载即可。
下载完成之后进行安装，除了自定义安装位置以外，其他部分全程选择默认选项即可。安装完成之后，在电脑桌面界面按鼠标右键，如果显示 Git GUI 和 Git Bash 菜单，则表示安装成功。
4. Git 的使用
4.1 Git 基本配置
Git 安装完成之后，需要对一些基本信息进行配置。首先要做的事就是设置用户名和 email 地址，这是非常重要的，因为每次 Git 都会用到这些信息，需要用户名和用户的 email 地址。
配置过程如下：
1、鼠标右击打开 Git Bash 命令行。
2、配置用户信息：
git config --global user.name xxx git config --global user.email xxx@163.com
查看配置信息
git config --global user.name git config --global user.email
4.2 获取本地仓库
想要使用 Git 对我们的代码进行版本控制，首先就要让 Git 获取到本地仓库。
流程如下：
首先，在本地位置创建一个空目录（test），作为本地 Git 仓库。
之后，进入创建好的目录，鼠标右键打开 Git Bash 命令行窗口。
然后，输入命令 git init 并执行，进行初始化 git 本地仓库的工作。
最后，如果创建成功，可以看到在创建的目录中，有一个隐藏的目录 .git 文件夹，表示本地仓库创建成功。（一般的系统默认是不显示隐藏的目录的，需要手动勾选显示隐藏的目录，这个自行百度）
4.3 Git 的基本操作指令
那么，创建好本地仓库之后，以后就可以对仓库里的文件进行增加、删除和更新的操作，也就是修改文件的状态，状态的改变需要执行对应的 Git 指令才能生效。
下图展示了状态之间的转化过程：
对于上图的理解，首先，我们可以分为三个区域，分别是工作区、暂存区和本地仓库。
在工作区中，新建一个文件或者修改一个已有的文件，新建的文件标识为 untracked（未跟踪），修改已有的文件标识为 unstaged（未暂存），这时候它们都是在工作区中的。
使用 git add 命令之后，就可以将新建的文件或已经修改的文件，从工作区中放入到暂存区进行暂存，暂存区就是提交到本地仓库之前的一个缓存区，此时状态变为 staged。
当确定要提交文件，便使用 git commit 命令将暂存区的文件提交到本地仓库，提交之后就会形成一条提交记录。
总结一下：
git add（工作区——>暂存区）
git commit（暂存区——本地仓库）
查看修改状态：
命令：git status
作用：查看修改的状态（暂存区、工作区）
添加工作区到暂存区：
命令：git add 单个文件名|通配符，可以添加单个文件名，例如 git add file.txt 或者使用通配符 git add . 添加所有文件。
作用：添加工作区一个或多个文件的修改到暂存区
提交暂存区到本地仓库：
命令：git commit -m '注释内容'
作用：提交暂存区内容到本地仓库的当前分支
查看提交日志：
命令：git log [option]
下表展示了几个option参数以及解释：
| option | 解释 |
| –all | 显示所有分支 |
| –pretty=online | 将提交信息显示为一行 |
| –abbrev-commit | 使得输出的commitId更简短 |
| –graph | 以图的形式显示 |
注意，由于编辑显示的问题，参数前面的 - 数量是两个，只有 abbrev-commit 中间的连接符是一个。
作用：查看提交记录
版本回退
命令： git reset --hard commitId，commitId 可以使用 git log 指令查看。
作用：版本切换
那么在版本切换之后，相当于之前的版本提交记录被删除了，如果想查看已经删除的提交记录，可以使用命令 git relog.
添加文件至忽略列表：
通常来说，一些临时文件或者日志文件是不需要纳入 Git 进行管理的，因此，可以创建一个名为 .gitignore 的文件，列出忽略的文件模式，配置内容参考以下：
# no .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a # only ignore the TODO file in the current directory, not subdir/TODO /TODO # ignore all files in the build/ directory build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt # ignore all .pdf files in the doc/ directory doc/**/*.pdf
练习基础操作：
#######仓库初始化####### # 创建目录（test）并在目录下打开 git bash 命令行窗口 # 初始化 git 仓库 git init ######创建文件并提交###### # 创建file01.txt touch file01.txt # 加入暂存区 git add . # 将修改提交到本地仓库 git commit -m 'create 001' # 查看日志 git log #######修改文件并提交####### # 修改file01的内容为 count=1 vim file01.txt # 略 # 将修改添加到暂存区 git add . # 将修改提交到本地仓库，提交记录内容为 update 001 git commit -m 'update 001' # 查看日志 git log #######回退到第一次版本####### # 查看提交记录 git log # 找到第一次提交的 commitId（就是那个很长的字符串，初学者如果不懂的自己百度） # 版本回退 git reset --hard commitId
4.4 分支操作
几乎所有的版本控制系统都以某种形式支持分支， 使用分支意味着可以把你的工作从开发主线上分离开来进行重大的 Bug 修复以及开发新的功能，以免影响开发主线。
查看本地分支：
命令：git branch
创建本地分支：
命令：git branch 分支名
切换分支：
命令：git checkout 分支名
我们还可以直接切换到一个不存在的分支（创建并切换）
命令：git checkout -b 分支名
合并分支：
命令：git merge 分支名称
作用：一个分支上的提交可以合并到另一个分支上去
删除分支：
注意，这里删除分支的时候，不能删除当前分支，只能删除其他分支。
命令：
# 删除分支时需要做各种检查 git branch -d b1 # 删除分支时不需要做任何检查，强制删除 git branch -D b1
开发中分支使用原则与流程：
几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离 开来进行重大的 Bug 修改、开发新的功能，以免影响开发主线。
在开发中，一般有如下分支使用原则与流程：
master （生产） 分支
线上分支、主分支，中小规模项目作为线上运行的应用对应的分支。
develop（开发）分支
是从 master 创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到 master 分支，准备上线。
feature/xxxx 分支
从 develop 创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完 成后合并到 develop 分支。
hotfix/xxxx 分支
从 master 派生的分支，一般作为线上 bug 修复使用，修复完成后需要合并到 master、test、 develop 分支。
test/UAT（User Acceptance Test） 分支
测试分支，用于在上生产环境之前，进行测试项目代码的分支。
练习分支操作：
#######创建并切换到dev01分支，在dev01分支提交####### # [master] 创建分支 dev01 git branch dev01 # 切换到 dev01 分支 git checkout dev01 # [dev01] 创建文件 file02.txt touch file02.txt # [dev01] 将修改加入暂存区并提交到仓库 git add file02.txt git commit -m 'add file02 on dev' # [dev01] 查看提交记录 git log #######切换到master分支，将dev01合并到master分支####### # [dev01] 切换到 master 分支 git checkout master # [master] 合并 dev01 到 master 分支 git merge dev01 # [master] 查看提交记录 git log #######删除dev01分支####### # [master] 删除 dev01 分支 git branch -d dev01 # [master] 查看提交记录 git log
4.5 获取远程仓库
4.5.1 常用的远程仓库（代码托管平台）
Git 有两种类型的仓库，分别是本地仓库和远程仓库。本地仓库就是个人计算机上的代码仓库，远程就是部署在云服务器上的仓库，又叫代码托管平台，用于不同的仓库协同工作、交换代码。
常用的代码托管平台有 github，相信大家都知道这个平台，上面就有很多的开源项目，但是由于服务器在国外，国内访问时速度可能非常慢。不过没关系，国内也有像 gitee、gitlab 这样的开源的代码托管平台，访问速度上会相比于 github 会快很多。此外，还有像 Azure git 付费的平台。
4.5.2 创建远程仓库
下面就以 gitee 平台为例，创建一个远程仓库，图文教程如下：
创建完成之后，便可以看到仓库的地址，下图中点击 SSH 便可看到对应的地址。
4.5.3 配置 SSH 公钥
得到仓库地址之后，还需要有个公私钥才能进入访问仓库，这个相当于用户名和密码一样，但是一般不会使用用户名和密码登录，大多使用公私钥验证登录。
1、首先，在本地电脑上启动 git bash 命令行窗口，输入命令：
ssh-keygen -t rsa
之后，不断回车，直到没有命令需要输入，重新开启下一行。
2、然后，输入命令获取到生成的公钥：
cat ~/.ssh/id_rsa.pub
3、拿到公钥之后，将公钥部署添加到仓库中。
通过仓库主页 「管理」->「部署公钥管理」->「添加部署公钥」 ，添加生成的 public key 添加到仓库中。
4、添加后，在终端（Terminal）中输入：
ssh -T git@gitee.com
首次使用需要确认并添加主机到本机SSH可信列表。若返回 Hi XXX! You’ve successfully authenticated, but Gitee.com does not provide shell access. 内容，则证明添加成功。
这样，公钥配置便完成了。如果还不明白的，可以去 Gitee帮助中心查看如何生成/添加 SSH 公钥。
4.6 操作远程仓库
4.6.1 添加远程仓库
首先，应该先初始化本地库，然后与已创建的远程库进行对接，本地仓库的命名与远程仓库保持一致，具体如何初始化的步骤上面已经讲过，不再赘述。
命令：git remote add <远端名称> <仓库路径>
远端名称，默认为 origin，具体取决于服务器配置。
仓库路径，从远端服务器获取，例如我这里是 git@gitee.com:huazaizaizai/git_test.git
4.6.2 查看远程仓库
命令：git remote
4.6.3 推送到远程仓库
命令：git push [-f] [--set-upstream] [远端名称[本地分支名][:远端分支名]]
如果远程分支名和本地分支名相同则可以只写本地分支名：
git push origin master
-f 表示强制覆盖
–set-upstream 推送到远端的同时并且建立起和远端分支的关联关系。
git push --set-upstream origin master
如果当前分支已经和远端分支关联，则可以省略分支名和远端名。git push 将 master 分支推送到已经关联的远端分支。
查看远程仓库，发现多出了一个名为 file01.txt 文件，表示确实已经将本地修改的文件 push 上去了。
4.6.4 查看关联关系
查看本地分支与远程分支的关联关系，可以使用如下命令：
git branch -vv
4.6.5 从远程仓库克隆
从远端仓库克隆，可以使用如下命令：
git clone <仓库路径> [本地目录] • 1
在这里，本地目录可以省略，默认会自动生成一个目录。
4.6.6 从远程仓库中抓取和拉取
远程分支其实与本地分支一样，都可以进行合并。只是需要先将远程仓库的更新下载下来，之后再去进行操作。
抓取：抓取就是将仓库里的更新都抓取到本地，不会进行合并。
命令：
git fetch [remote name] [branch name]
如果不指定远端名称和分支名，则抓取所有分支。
拉取：拉取就是将远端仓库的修改拉到本地仓库并自动进行合并，等同于 fetch+merge.
命令：
git pull [remote name] [branch name]
如果不指定远端名称和分支名，则抓取所有并更新当前分支。
5. 总结
本文首先对集中式版本控制系统和分布式版本控制系统作了简单的介绍，以及将两者进行了对比，突出强调了分布式版本控制系统的优点，拥有大量的用户支持，以及未来会有更多的企业用户使用分布式版本控制系统取代集中式版本控制系统。
之后，对分布式版本控制系统中比较常用的几个代码托管平台进行了介绍，例如常见的有 Github、Gitee、Gitlab、Auzure Git 等等。
最后，对 Git 的安装以及使用花了较大的篇幅进行了介绍，包括 Git 的工作流程原理，并结合了国内知名的代码托管平台 Gitee 进行了介绍。
