【Git ：分布式版本控制工具】

了解 Git 基本概念
能够概述 Git 工作流程
能够使用 Git 常用命令
熟悉 Git 代码托管服务
能够使用 IDEA 操作 Git

一、概述

1. 开发中的实际场景

备份
代码还原
协同开发
追溯问题代码的编写人和编写时间

2. 版本控制器的方式

集中式版本控制工具
- 集中式版本控制工具，版本库是集中存放在中央服务器的，团队中的每一个人工作时从中央服务器下载代码，是必须联网才能工作，局域网或互联网，个人修改后然后提交到中央版本库中
- 举例：SVN 和 CVS
分布式版本控制工具
- 分布式版本控制系统没有“中央服务器”，每个人的电脑都是一个完整的版本库，这样工作的时候，无需进行联网，因为版本库就在自己的电脑上，多人协作只需要各自的修改推送给对方，就能互相看到对方的修改了
- 举例：Git

3. Git

Git 是分布式的，Git 不需要有中心服务器，每台电脑拥有的东西都是一样的，我们使用 Git 并且有个中心服务器，仅仅是为了方便交换大家的修改，但这个服务器的地位和我们每个人的 PC 一样的，我们可以把它当作一个开发者的 PC ，是为了大家的代码交流不关机使用，没有它每个人都可以一样正常工作，只不过交换修改意见更加方便而已。
Git 是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大地项目版本管理，Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件
Git 诞生于一个极富纷争大局创新的年代，Linux 内核开源项目有着为数众多的参与者，绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991到2002年间），到2002年，整个项目组开始启用一个专有的分布式版本控制控制系统 BitKeeper 来管理和维护代码。
由于2005年与 BitKeeper 商业公司的合作关系结束，迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出了自己的版本系统，他们对新的系统制定了若干目标：

速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

Git

4. Git 工作流程

Git 工作流程图

命令如下：
1. clone（克隆）：从远程仓库中克隆代码到本地仓库
2. checkout（检出）：从本地仓库中检出一个仓库分支然后进行修订
3. add（添加）：在提交前先将代码提交到暂存区
4. commit（提交）：提交到本地仓库，本地仓库中保存修改的各个历史版本
5. fetch（抓取）：从远程仓库，抓取到本地仓库，不进行任何的合并动作，一般操作比较少
6. pull（拉取）：从远程仓库，拉到本地仓库，自动进行合并（merge），然后放到工作区，相当于： fetch+merge
7. puch（推送）：修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库

二、 Git 安装与常用命令

此示例中的 Git 命令都是在 Git Bash 中演示的，会用到一些基本的 Linux 命令：

ls/ll ：查看当前目录
cat ：查看文件内容
touch ：创建文件
vi ：vi 编辑器（还可以使用记事本、EditPlus、NotePad++等编辑器）

1. Git 环境配置

（1） Git 下载与安装

下载：Git 官网

直接一路默认安装即可，可以更改安装位置
安装成功后会在桌面右击出现如图所示两个选项
备注：
- Git GUI ：Git 提供的图形界面工具
- Git Bash ：Git 提供的命令行工具
- 当安装 Git 后首先要做的事情是设置用户名称和 Email 地址，这是非常重要的，因为每次 Git 提交都会使用该用户信息

（2）基本配置

打开 Git Bash
设置用户信息
- git config --global user.name "xxxxxx"
- git config --global user.email ''xxxxxxxxx@xxx.xxx"
查看配置信息
- git config --global user.name
- git config --global user.email

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

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

打开用户目录（Windows 系统中就是 C 盘中的用户目录），创建 .bashrc 文件
- 部分 Windows 系统不允许用户创建点号开头的文件，可以打开 Git Bash，执行 touch ~/.bashrc 命令
在 .bashrc 文件中输入如下内容：

# 用于输出 Git 提交日志
alias git-log='git log --pretty=oneline --all --graph --abbrev-commit'
# 用于输出当前目录所有文件及基本信息
alias ll='ls -al'

打开 Git Bash，执行 source ~/.bashrc

（4）解决 Git Bash 乱码问题

打开 Git Bash 执行下面命令

git config --global core.quotepath false

${git_home}/etc/bash.bashrc 文件最后加入下面两行（${git_home} 就是 Git 的安装目录）

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

2. 获取本地仓库

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

在电脑的任意位置创建一个空目录，作为我们的本地 Git 仓库
进入这个目录中，点击右键打开 Git Bash 窗口
执行命令：git init（命令含义：初始化当前目录为一个 Git 仓库）
如果创建成功后可在文件夹下看到隐藏的 .git 目录（可以使用 ll 命令查看）

3. 基础命令操作

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

此处主要说明如何使用命令来控制这些状态之间的转换
1. git add ：（工作区 → 暂存区）
2. git commit ：（暂存区 → 本地仓库）

（1）查看修改的状态（status）

作用查看修改的状态（暂存区、工作区）
命令形式：git status

（2）添加工作区到暂存区（add）

作用：添加工作区一个或多个文件的修改到暂存区
命令形式：git add 单个文件名/通配符
- 将所有修改加入到暂存区：git add .

（3）提交暂存区到本地仓库（commit）

作用：提交暂存区内容到本地仓库的当前分支
命令形式：git commit -m "注释内容"

（4）查看提交日志（log）

由于之前的别名配置中 git-log 包含了这些参数，所以后续可以直接使用 git-log ，即可包含以下所有参数，进行最优最简化操作与显示

作用：查看提交记录
命令形式：git log [option]
- options
  - --all ：显示所有分支
  - --pretty=oneline ：将提交信息显示为一行
  - --abbrev-commit ：使得输出的 commitID 更简短
  - --graph ：以图的形式显示

（5）基本使用流程

使用 touch 命令创建一个文件
使用 git status 命令查看文件状态，此时处于未跟踪状态
使用 git add 文件名 命令，使文件进入暂存区，这里也可以使用 . 通配符操作，更加快速便捷

之后使用 git commit -m "注释" 即可进行提交，到达仓库
之后查看状态，就会发现工作区“干净”
提交日志命令 git log
之后进行文件修改，可以使用 vi 编辑器，进行修改
- vi test01.txt 进入 vi 编辑器
- 输入 i 输入模式，然后，输入或更改部分内容，之后 Esc 按钮，进入命令模式，之后输入 :wq（保存并退出）
之后就可以再次进行以上流程

（6）版本回退

作用：版本切换
命令形式：git reset --hard commitID（commitID ：就是提交时自动分配的 ID 属性）
- commitID ：可以使用 git-log 或 git log 指令查看
查看已删除的记录
- git reflog
- 这个指令记录了所有的操作记录，可以看到已经删除的提交记录

版本回退

注意：对于此命令窗口，选中目标即为自动复制成功，到目标位置点击滚轮即可粘贴
进行版本回退之后，如果又不想版本回退，可以直接输入回退之前的版本号（在此示例中：git reset --hard ea94ac6）
如果进行了清屏（clear）操作，依旧可以找到版本号，使用 git reflog 命令，查看已经删除的提交记录

查看并回退

（7）添加文件至忽略列表

一般我们总会有些文件无需纳入 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

4. 分支

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

（1）查看本地分支

命令：git branch

所以从这里可以看出 HEAD -> 的标记，就是指向当前分支

（2）创建本地分支

命令：git branch 分支名

（3）切换分支（checkout）

命令：git checkout 分支名

命令：git checkout -b 分支名
- 可以直接切换到一个不存在的分支（创建并切换）

创建并切换

（4）合并分支（merge）

一个分支上的提交可以合并到另一个分支
- 命令：git merge 分支名陈
示例：模拟多人协作过程：假如现在切换到 branch01 分支下，创建并提交 test02.txt 文件
但是，如果切换到 master 分支下，会显示
操作过程
经过协作开发后，一般把分支合并到 master 分支上

合并结果

（5）删除分支

不能删除当前分支，只能删除其他分支
git branch -d b1 ：删除分支时，需要做各种检查
git branch -D b1 ：不做任何检查，强制删除（一般使用这种是由于要删除的分支并没有合并到主分支上，所以用 -d 方式删不掉，如果确定不进行合并，就使用这种删除方式）

（6）解决冲突

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

解决冲突的步骤：
1. 处理文件中冲突的地方
2. 将解决完冲突的文件加入暂存区
3. 提交到仓库
模拟流程：此时创建并进入一个分支 branch02，并且修改 test01.txt （数据只有一行，且只有一个数字，既不为1，也不为2）其中数字为2，然后加入暂存区，提交，之后进入 master 分支，也修改其中的数字为1，之后加入暂存区，提交，最后合并分支 branch02 到 master 分支，此时就会出现冲突
从结果得知，此时文件的内容变得“独特”，此时“等号”前面指向当前分支所做的修改，“等号”后面指向，合并来的分支做出的修改，这种情况直接，手动进行修改文件即可，修改完之后加入暂存区，提交即可

vi 编辑器中，修改前
vi 编辑器中，修改后

（7）开发中分支使用的原则与流程

在开发中，一般有如下分支使用原则与流程
- master （生产）分支
  - 线上分支，主分支，中小规模项目作为线上运行的应用对应的分支
- develop （开发）分支
  - 是从 master 创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到 master 分支，准备上线
- feature/xxxx 分支
  - 从 develop 创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完成后合并到 develop 分支
- hotfix/xxxx 分支
  - 从 master 派生的分支，一般作为线上 Bug 修复使用，修复完成后需要合并到 master、test、develop 分支
- 还有一些其他分支，例如 test 分支（用于代码测试）、per 分支（预上线分支）等

三、 Git 远程仓库

1. 常用的托管服务（远程仓库）

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

GitHub GitHub 官网是一个面向开源及私有软件项目的托管平台，因为只支持 Git 作为唯一的版本库格式进行托管，故名为 GitHub
Gitee （码云）Gitee 官网是国内的一个代码托管平台，由于服务器在国内，所以相比 GitHub，码云的速度会更快
GitLab GitLab 官网是一个用于仓库管理系统的开源项目，使用 GIt 作为代码管理工具，并在此基础上搭建起来的 Web 服务，一般用于在企业、学校等内部网络搭建的 Git 私服

2. 注册 Gitee

此示例使用 Gitee 作为远程仓库

新建仓库
可以按照下图选择

3. 配置 SSH 公钥

为了方便后期进行推送仓库，所以使用 SSH 公钥方式证明身份

生成 SSH 公钥（在本地仓库使用 Git Bash 命令窗口）
- 使用 ssh-keygen -t rsa 命令
- 直接多次回车确定
  - 如果公钥已经存在，则自动覆盖
Gitee 设置账户公共公钥
- 获取公钥
  - 使用命令 cat ~/.ssh/id_rsa.pub 查看公钥
  - 然后在命令行中复制公钥，到 Gitee 处的个人页面的设置处，找到 SSH 公钥
进行配置（标题处可以更改），之后输入密码验证
- 验证是否配置成功
  - 命令 ssh -T git@gitee.com
    - 其中的提示输入 yes 即可
如果配置 GitHub 的密钥，依旧可以使用此方法，两者的配置方式没有区别。（同一台电脑生成一个 SSH 密钥，就可以提交到不同的平台，如果有特殊需要，需要配置文件，可以达到一台电脑生成多个密钥）
- 生成命令：ssh-keygen -t rsa -C "GitHub 使用的邮件地址"（如果只使用一个 SSH 密钥可以不用生成）
- 验证配置：ssh -T git@github.com

4. 操作远程仓库

（1）添加远程仓库

命令：git remote add <远端名称> <仓库路径>
- 远端名称：默认是 origin ，取决于远端服务器设置
- 仓库路径：从远端服务器获取此 URL
远程仓库的添加，先进行 SSH 地址的复制
进入 Git Bash 中本地仓库的位置，输入命令：git remote add origin 复制的地址 ，没有报错，就证明添加成功（此处的 origin 处可以自定义，但是规范默认为 origin）

（2）查看远程仓库

使用 git remote 命令就可以查看到远程仓库：origin

（3）推送到远程仓库

命令：git push [-f] [--set-upstream] [远端名称[本地分支名]:[远端分支名]]
- -f ：表示强制覆盖
- 如果远程分支名称和本地分支名称相同，则可以只写本地分支
  - git push origin master（git push origin master:master）
- --set-upstream ：推送到远端的同时并且建立起和远端分支的关联关系
  - git branch -vv ：查看关联关系
  - git push --set-upstream origin master （一般就是第一次推送时使用，建立绑定关系并且推送，之后就不需要继续绑定）
- 如果当前分支已经和远端分支关联，则可以省略分支名和远端名
  - git push ：将 master 分支推送到已关联的远端分支

（4）本地分支与远程分支的关联关系

查看关联关系使用： git branch -vv 命令

（5）从远程仓库克隆

如果已经有一个远端仓库，可以直接克隆（clone）到本地

命令：git clone <仓库路径> [本地目录];
- 本地目录可以省略，会自动生成一个目录
操作过程：在目标文件夹，打开 Git Bash 命令窗口，然后执行命令
仓库路径
之后就可以在目标文件夹看到克隆出的文件

（6）从远程仓库中抓取和拉取

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

抓取命令：git fetch [remote name] [branch name]
- 抓取指令就是将仓库里的更新都抓取到本地，不会进行合并
- 如果不指定远端名称和分支名称，则抓取所有分支
拉取命令：git pull [remote name] [branch name]
- 拉取指令就是将远端仓库的修改拉到本地并自动进行合并，等同于抓取加合并（fetch + merge）
- 如果不指定远端名称和分支名，则抓取所有并更行当前分支
示例：先进行本地仓库修改，添加 test03.txt 文件，然后按顺序加入暂存区、提交，之后查看日志，再推送到远程仓库，查看日志，之后在从克隆来的仓库处进行抓取操作，获取新的提交工作，之后查看日志，然后进行合并操作，更新克隆的仓库，之后查看日志，对比四处日志
- 本地仓库，推送之前
- 本地仓库，推送之后
- 克隆仓库，抓取之后
- 进行合并（注意此处的合并命令的写法：git merge origin/master，即为未合并之前远程仓库分支的更新处的路径）
最后发现，三处最终合并的结果文件目录、内容等一致
最后两步中的”抓取加合并“操作，可以直接使用拉取（pull）命令完成

（7）解决合并冲突

在一段时间内，A、B两个用户修改了同一个文件，且修改了同一行位置的代码，此时会发生合并冲突

A 用户在本地修改代码后优先推送到远程仓库，此时 B 用户再本地修订代码，提交到本地仓库后，也需要推送到远程仓库，此时 B 用户晚于 A 用户，所以需要先拉取远程仓库的提交，经过合并后才能推送到远端分支
在 B 用户拉取代码时，因为 A、B 用户同一段时间修改了同一个文件的相同位置代码，所以会发生合并冲突
远程分支也是分支，所以合并冲突的解决方式也和解决本地分支冲突相同
所以在实际发生这种情况，都是在执行 git push 命令时，发生合并冲突，所以此时需要执行 git pull 命令，将远程仓库中的文件抓取下来，进行确定的冲突修改后，再进行 git push 命令即可

四、在 IDEA 中使用 Git

1. 在 IDEA 中配置 Git

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

Git

2. 在 IDEA 中操作 Git

场景：本地已经有一个项目，但是并不是 Git 项目，需要将这个项目放到远程的仓库中，和其他人员一起协作开发

（1）创建项目远程仓库

创建一个空的远程仓库（与上文一致）

（2）在 IDEA 中创建本地仓库及基础操作

可以直接将以前的项目直接在 IDEA 中本地打开（此处演示重新创建的 Maven 框架下的模块）

打开项目之后，对于某些文件不需要 Git 进行管理，所以引入 .gitignore 文件
.gitignore 文件通用

*.class
.mtj.tmp/
*.jar
*.war
*.ear
*.zip
hs_err_pid*
.idea
*.iml
*.bak
*.class
*.rar
*.log
.project
.settings
.classpath
target
classes
lib
*.DS_Store
.gradle
build
out
log