【Git】分布式版本控制系统

1.版本管理工具概念

我在大学毕业写论文的时候的时候碰到过如下的现象

<<毕业论文第一版.doc>>
<<毕业论文第二版.doc>>
<<毕业论文第三版.doc>>
<<毕业论文最终版.doc>>
<<毕业论文最终版2.doc>>

类似的问题我曾经也碰到过很多,例如:

领导让写文档,写好了,领导让修改,改好了,领导觉得第一版不错,改回来吧,此时内心一脸懵,第一版长啥样没存档啊

实际上,代码开发中也需要这样的软件来管理我们的代码. 例如我们经常会碰到如下的现象:

改之前好好的,改完就报错了,也没怎么修改啊

在这种情况下如果不能查看修改之前的代码,查找问题是非常困难的.

如果有一个软件能记录我们对文档的所有修改,所有版本,那么上面的问题讲迎刃而解.而这类软件我们一般叫做版本控制工具

版本管理工具一般具有如下特性:

1) 能够记录历史版本,回退历史版本
2) 团队开发,方便代码合并

2. 版本管理工具介绍

现在比较流行的版本管理工具是git ,但是实际上git 是近几年才发展起来的,可能有一些老的项目,还在用一些老的软件,比如svn

2.1版本管理发展简史(维基百科)

2.1.1 SVN(SubVersion)

工作流程

SVN是集中式版本控制系统，版本库是集中放在中央服务器的.
工作流程如下:
	1.从中央服务器远程仓库下载代码
	2.修改后将代码提交到中央服务器远程仓库

优缺点:

 优点: 简单,易操作
 缺点:所有代码必须放在中央服务器  
  	   1.服务器一旦宕机无法提交代码,即容错性较差
       2.离线无法提交代码,无法及时记录我们的提交行为

svn流程图

2.1.2 Git

工作流程

Git是分布式版本控制系统（Distributed Version Control System，简称 DVCS），分为两种类型的仓库：
本地仓库和远程仓库
工作流程如下
    1．从远程仓库中克隆或拉取代码到本地仓库(clone/pull)
    2．从本地进行代码修改
    3．在提交前先将代码提交到暂存区
    4．提交到本地仓库。本地仓库中保存修改的各个历史版本
    5．修改完成后，需要和团队成员共享代码时，将代码push到远程仓库

总结:git和svn的区别

1. svn 是集中式版本控制工具,git 是分布式版本控制工具
2. svn 不支持离线提交,git 支持离线提交代码

3. Git 发展简史

林纳斯·本纳第克特·托瓦兹（Linus Benedict Torvalds, 1969年~ ）

很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？

事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！

你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？那个年代不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。而授权的前提是:Linux 社区的人不能开发具有相同功能的竞争产品!

另一方面,BitKeeper不是开源的. 显然与Linux 的开源精神不相符,所以linux 社区的很多人抱怨,不愿意使用.

典型的就是 Andrew Tridgell (Samba 开发服务的创造者) 非常不满.偷偷违反了和 BitKeeper 的协议,反编译 BitKeeper 的源代码,开发了个爬虫,然后爬取信息被人发现了. BitKeeper 公司的领导非常不满意,然后开始发布消息说,(下个版本)不再为Linux 提供免费的服务.

Linus 本人就出面协调(几周或者几个月),但是不管用, 没办法. 估计谈判的过程感觉到了憋屈–“吃人嘴短,拿人手软”

Linus 本人 花了10天的时间Git 出来了,一个月之内，Linux系统的源码已经由Git管理了！

Git 出来以后毕竟是一个人做的,开始并不好用(刚开始只能用勉强可以用来形容), 还是很多人抱怨,发展了很多年都没有干过其他软件.

直到 2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub,从此git 迎来了飞速发展,当下git 已经成为了最流行的版本控制工具

4. Git的安装与配置

4.1 下载与安装

下载地址： https://git-scm.com/download

过程直接选择默认配置即可

点击右键，如果能够看，到如下两个菜单则说明Git安装成功

备注：

• Git GUI：Git提供的图形界面工具

• Git Bash：Git提供的命令行工具

• 注意：当安装Git后首先要做的事情是设置用户名称和email地址。这是非常重要的，因为每次Git提交都会使用该用户信息
  Git版本控制要记录哪个人什么时候做了什么事情，Git就是通过邮箱去辨识是哪个人的

4.2 Git 基本配置

1.打开Git Bash

2.设置用户信息

git config --global user.name "用户名"

git config --global user.email "邮箱地址"

3. 为常用指令配置别名（可选）

• 有些常用的指令参数非常多，每次都要输入好多参数，我们可以使用别名。

• 打开用户目录，创建 .bashrc 文件
  部分windows系统不允许用户创建点号开头的文件，可以打开gitBash,执行 touch ~/.bashrc
  
  

• 打开gitBash，执行 source ~/.bashrc
  

4. 解决GitBash乱码问题

• 打开GitBash执行下面命令

git config --global core.quotepath false

• ${git_home}/etc/bash.bashrc 文件最后加入下面两行

export LANG="zh_CN.UTF-8" 
export LC_ALL="zh_CN.UTF-8"

4.3 获取本地仓库

• 要使用Git对我们的代码进行版本控制，首先需要获得本地仓库

1）在电脑的任意位置创建一个空目录作为我们的本地Git仓库

2）进入这个目录中，点击右键打开Git bash窗口

3）执行命令git init

4）如果创建成功后可在文件夹下看到隐藏的.git目录。

5. Git的使用

5.1 Git基础操作指令

Git工作目录下对于文件的修改(增加、删除、更新)会存在几个状态，这些修改的状态会随着我们执行Git的命令而发生变化。

• git add (工作区 --> 暂存区) git add .添加所有文件、文件夹和子文件夹，包括.gitignore和以点开头的任何其他内容；

• git commit (暂存区 --> 本地仓库)

5.1.1 查看修改的状态（status）

• 作用：查看的修改的状态（暂存区、工作区）

• 命令形式：git status

新创建的文件是未跟踪状态

即将被提交的意思

提交完后显示缓冲区没有东西可以提交了

新建文件是显示new file 修改文件就是实现modified

5.1.2 添加工作区到暂存区(add)

• 作用：添加工作区一个或多个文件的修改到暂存区

• 命令形式：git add 单个文件名|通配符

• 将所有修改加入暂存区：git add .

5.1.3 提交暂存区到本地仓库(commit)*

• 作用：提交暂存区汇总所有内容到本地仓库的当前分支

• 命令形式：git commit -m ‘注释内容’

5.1.4 查看提交日志(log)

• 作用:查看提交记录

• 命令形式：git log [option]

• options

  • all 显示所有分支

  • pretty=oneline 将提交信息显示为一行

  • abbrev-commit 使得输出的commitId更简短

  • graph 以图的形式显示

查看log我们一般都是会加上上面全部的参数的，这样显示更美观有序，我们在上面给这个指令设置了别名

#用于输出git提交日志 
alias git-log='git log --pretty=oneline --all --graph --abbrev-commit' 

5.1.5 版本回退

撤回到之前的某个操作，他回去删除我们撤回到位置之后的版本

• 作用：版本切换

• 命令形式：git reset --hard commitID

• commitID 可以使用 git-log 或 git log 指令查看

• 如何查看已经删除的记录？

  • git reflog

  • 这个指令可以看到已经删除的提交记录

我们可以在reflog里面知道删除文件的id，我们可以直接使用命令git reset --hard commitID 还原 所以git reset --hard commitID既可以做版本回退，也可以做版本还原

5.1.6 添加文件至忽略列表

一般我们总会有些文件无需纳入Git 的管理，也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。 在这种情况下，我们可以在工作目录中创建一个名为 .gitignore 的文件（文件名称固定），列出要忽略的文件模式。

创建后记得也需要提交

5.2 分支

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。master是我们的主线

每个人开发的那一部分就是一个分支，使得每个人的开发互不影响，在每个人都开发完后就将所有的代码汇总到一起，此时就要执行分支的合并操作

工作区只能在一个分支工作，每个分支存放的文件或者资源是不一样的，就相当于不同的文件夹

5.2.1 查看本地分支

• 命令：git branch

• *号表示所在的分支

5.2.2 创建本地分支

• 命令：git branch 分支名
• 创建的新分支会建立在当前分支的版本之上，所以新建的分支会有当前分支的内容

5.2.3 切换分支(checkout)

• 命令：git checkout 分支名

• 我们还可以直接切换到一个不存在的分支（创建并切换）

  • 命令：git checkout -b 分支名

5.2.4 合并分支(merge)

• 注意：分支上的内容必须先提交,才能切换分支

• 一个分支上的提交可以合并到另一个分支

• 命令：git merge 分支名称
  在每个人都开发完后就将所有的代码汇总到一起，此时就要执行分支的合并操作

5.2.5 删除分支

• 不能删除当前分支，只能删除其他分支

• git branch -d b1 删除分支时，需要做各种检查

• git branch -D b1 不做任何检查，强制删除
  
  
  

5.2.6 解决冲突

当我们合并分支后，两个或者多个分支对同一个文件的同一个地方进行修改的时候（不是同一个地方是不会出现冲突的 ），此时git就不知道要取哪个分支修改的值，是取a分支修改的值，还是取b分支修改的值呢，此时就产生了冲突

此时的文件样子

• 第一个count值表示的是当前分支修改的值

• 第二个count值是在dev分支修改的值

当两个分支上对文件的修改可能会存在冲突，例如同时修改了同一个文件的同一行，这时就需要手动解决冲突，解决冲突步骤如下：

其实我们就是直接手动去删除文件中的一个分支，留下一个分支，这样就不会冲突了

• 处理文件中冲突的地方

• 将解决完冲突的文件加入暂存区(add)

• 提交到仓库(commit)
  

5.2.7 开发中分支使用原则与流程

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。

在开发中，一般有如下分支使用原则与流程：

• master （生产） 分支
  ​ 线上分支，主分支，中小规模项目作为线上运行的应用对应的分支；

• develop（开发）分支
  ​是从master创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线​。
  要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到master分支,准备上线。

​例如我们要开发新功能，我们要可以在develop分支上在建一个分支，新功能一般叫做feature分支，开发完以后在合并到 develop分支上面去，而不是直接提交到master分支，最后项目做完了develop在合并到master分支上

develop和master分支是不可删除的

• feature/xxxx分支（用完可删）
  ​从develop创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完成后合并到develop分支，用完后可删除。

• hotfifix/xxxx分支，
  ​从master派生的分支，一般作为线上bug修复使用，修复测试完成后需要合并到master、test、develop分支。

• 还有一些其他分支，在此不再详述，例如test分支（用于代码测试）、pre分支（预上线分支）等等。
  

5.3 Git远程仓库

5.3.1 常用的托管服务[远程仓库]

前面我们已经知道了Git中存在两种类型的仓库，即本地仓库和远程仓库。那么我们如何搭建Git远程仓库 呢？我们可以借助互联网上提供的一些代码托管服务来实现，其中比较常用的有GitHub、码云、GitLab等。

• gitHub（ 地址：https://github.com/ ）是一个面向开源及私有软件项目的托管平台，因为只支持 Git 作为唯一的版本库格式进行托管，故名gitHub

• 码云（地址： https://gitee.com/ ）是国内的一个代码托管平台，由于服务器在国内，所以相比于 GitHub，码云速度会更快

• GitLab （地址： https://about.gitlab.com/ ）是一个用于仓库管理系统的开源项目，使用Git作 为代码管理工具，并在此基础上搭建起来的web服务,一般用于在企业、学校等内部网络搭建git私服。

5.3.2 创建远程仓库

仓库创建完成后可以看到仓库地址，如下图所示:

5.3.3 配置SSH公钥

• 生成SSH公钥

  • ssh-keygen -t rsa
    不断回车
    如果公钥已经存在，则自动覆盖

• Gitee设置账户共公钥

  • 获取公钥
    cat ~/.ssh/id_rsa.pub

• 验证是否配置成功

  • ssh -T [email protected]

5.3.4 操作远程仓库

5.3.4.1 添加远程仓库

此操作是先初始化本地库，然后与已创建的远程库进行对接。

我们要将本地仓库和远程仓库连接起来，一般一个本地仓库对应一个远程仓库远侧，远程仓库默认名为origin

• 命令： git remote add <远端名称> <仓库路径SSH>

  • 远端名称，默认是origin，取决于远端服务器设置

  • 仓库路径，从远端服务器获取此SSH

5.3.4.2 查看远程仓库

• 命令：git remote
  

5.3.4.3 推送到远程仓库

• 命令：git push [-f] [–set-upstream] [远端名称 [本地分支名][:远端分支名] ]

  • 如果远程分支名和本地分支名称相同，则可以只写本地分支

    本来是：git push origin master ：master 表示将本地仓库的master分支提交到远程仓库的master分支

    git push origin master 这里表示将本地仓库当前master分支的内容推到远程仓库上面去

  • -f 表示强制覆盖

  • –set-upstream 推送到远端的同时并且建立起和远端分支的关联关系。

    • git push --set-upstream origin master

• 如果当前分支已经和远端分支关联，则可以省略分支名和远端名。

  • git push 将master分支推送到已关联的远端分支。

• [-f] 表示强制覆盖远程仓库的内容

• 查看关联关系我们可以使用 git branch -vv 命令

5.3.4.4 从远程仓库克隆

如果已经有一个远端仓库，我们可以直接clone到本地。

• 命令: git clone <仓库路径> [本地目录]
  本地目录可以省略，会自动生成一个目录，就是SSH后面那部分
  

左边是我们上传的仓库，右边是克隆下来的仓库

不同的主机都把修改完了版本资源放在远程仓库上，然后其他人都是克隆，这样就可以实现不同主机之间的数据同步了，数据都是一样的

克隆一般只会执行一次，就是在你进去公司的时候，别人提交了以后，我们不需要去克隆整个仓库，仓库是很大的，克隆也需要花很多时间，所以要去远程仓库中抓取我们要的版本信息，就是那些别人新增加的提交

5.3.4.5 从远程仓库中抓取和拉取

远程分支和本地的分支一样，我们可以进行merge操作，只是需要先把远端仓库里的更新都下载到本地，再进行操作。

• 抓取 命令：git fetch [remote name] [branch name]
  抓取指令就是将仓库里的更新都抓取到本地，不会进行合并，不合并本地仓库就是没有更新，此时还没有拿到远程仓库的内容，合并后才会拿到更新的内容
  如果不指定远端名称和分支名，则抓取所有分支。

• 拉取 命令：git pull [remote name] [branch name]
  拉取指令就是将远端仓库的修改拉到本地并自动进行合并，等同于fetch+merge
  如果不指定远端名称和分支名，则抓取所有并更新当前分支。

为什么将远程仓库更新的资源抓取到本地要合并呢？

• 总结：push的时候要使远程仓库的更新是最新的，就是最后一个修改的版本要使远程仓库的，pull要使本地仓库的更新是最新的，就是最后一个修改的版本要使本地仓库的

• 因为我们此时我们获取到的是远程仓库的版本更新，但是我们本地的版本不是最新的，也就是说此时我们本地和远程仓库不是同步的，所以我们要将远端拿到的修改合并到本地仓库的master上，使得本地的版本修改变为最新的

5.3.4.6 解决合并冲突

我们要更新远程仓库的资源时，先要获取此时远程仓库的资源后，在合并到自己的master分支中，然后再上传到远程仓库上

在一段时间，A、B用户修改了同一个文件，且修改了同一行位置的代码，此时会发生合并冲突。A用户在本地修改代码后优先推送到远程仓库，此时B用户在本地修订代码，提交到本地仓库后，也需要推送到远程仓库，此时B用户晚于A用户，故需要先拉取远程仓库的提交，经过合并后才能推送到远端分支

6. 在Idea中使用Git

6.1 在Idea中配置Git

安装好IntelliJ IDEA后，如果Git安装在默认路径下，那么idea会自动找到git的位置，如果更改了Git的安装位置则需要手动配置下Git的路径。选择File→Settings打开设置窗口，找到Version Control下的git选项

点击Test按钮，配置完成

6.2 在Idea中操作Git

• 创建项目远程仓库
  

• 初始化本地仓库（将当前项目初始化为仓库）

• 此时我们的项目目录就变成了一个本地仓库
  
  绿色的文件代表已添加到git中
  爆红的文件没有被添加到git当中，被Git识别为冲突文件
  灰色的文件代表已忽略的文件，可以在gitignore文件中配置
  

• 设置远程仓库
  远程仓库名默认为origin
  

• 提交到本地仓库
  

• 推送到远程仓库
  在将本地仓库的修改推送到git远程仓库的时候，我们要先pull，先拿到此时远程仓库的版本信息，再去此版本信息上修改
  
  
  

• 克隆远程仓库到本地
  

• 创建分支

  • 最常规的方式
    
  • 最强大的的方式
    

• 切换分支及其他分支相关操作
  

• 解决冲突
  执行merge或pull操作时，可能发生冲突
  
  

• 之后提交再推导远程仓库

附:几条铁令

• 切换分支前先提交本地的修改

• 代码及时提交，提交过了就不会丢

• 遇到任何问题都不要删除文件目录

IDEA集成GitBash作为Terminal