Git --- 常用命令、分支操作、团队协作机制
一、Git 概述
Git 是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目
Git 易于学习，占地面积小，性能极快。它具有廉价的本地库，方便的暂存区域和多个工作流分支等特性
其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具
官网地址：Git
1.1、何为版本控制？
版本控制是一种记录文件内容变化，以便将来查阅特定版本修订情况的系统
版本控制其实最重要的是可以记录文件修改历史记录，从而让用户能够查看历史版本，方便版本切换
1.2、为什么需要版本控制？
个人开发过渡到团队协作
1.3、版本控制工具
集中式版本控制工具
CVS、SVN（Subversion）、VSS.......
集中化的版本控制系统诸如 CVS、SVN 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法
这种做法带来了许多好处，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易
事分两面，有好有坏。这么做显而易见的缺点是中央服务器的单点故障。如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作
总结
- 优点：可以看到其他人正在做些什么；开发者权限控制
- 缺点：中央服务器的单点故障，无法提交历史记录
分布式版本控制工具
Git、Mercurial、Bazaar、Darcs.......
像 Git 这种分布式版本控制工具，客户端提取的不是最新版本的文件快照，而是把代码仓库完整地镜像下来（本地库）。这样任何一处协同工作用的文件发生故障，事后都可以用其他客户端的本地仓库进行恢复。因为每个客户端的每一次文件提取操作，实际上都是一次对整个文件仓库的完整备份
分布式的版本控制系统出现之后，解决了集中式版本控制系统的缺陷：
- 服务器断网的情况下也可以进行开发（因为版本控制是在本地进行的）
- 每个客户端保存的也都是整个完整的项目（包含历史记录，更加安全）
优点：
- 版本控制在本地，可以断网开发
- 保存完整项目，包含历史记录，更安全
1.4、Git 工作机制
- 工作区写代码，通过
git add命令添加至暂存区
- 暂存区临时存储代码，通过
git commit提交至本地库
- 本地库记录历史记录，通过
git push推送至远程库
1.5、Git 和代码托管中心
代码托管中心是基于网络服务器的远程代码仓库，一般我们简单称为远程库
- 局域网：
GitLab
- 互联网
GitHub（外网）
Gitee码云（国内网站）
二、Git 安装
官网地址：Git
右键任意位置，在右键菜单里选择 Git Bash Here 即可打开 Git Bash 命令行终端
在 Git Bash 终端里输入 git --version 查看 git 版本，如图所示，说明 Git 安装成功
三、Git 常用命令
| 命令 |
作用 |
| git config user.name 用户名 |
设置用户签名 |
| git config user.email 邮箱 |
设置用户签名 |
| git init |
初始化本地库 |
| git status |
查看本地库状态 |
| git add 文件名 |
添加至暂存区 |
| git commit -m "日志信息" 文件名 |
提交至本地库 |
| git reflog |
查看历史记录 |
| git reset --hard 版本号 |
版本穿梭 |
3.1、设置用户签名
基本语法
git config --global user.name 用户名
git config --global user.email 邮箱案例:
全局范围的签名设置
说明：
签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的
Git 首次安装必须设置一下用户签名，否则无法提交代码
注意：这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任何关系
3.2、初始化本地库
基本语法
git init案例:
3.3、查看本地库状态
基本语法
git status案例:
新增文件前
新增文件后
3.4、添加暂存区
基本语法
git add 文件名案例:
红色表示仍在工作区，修改尚未被追踪；绿色表示已添加至暂存区，修改被追踪
使用命令，删除暂存区该文件（只是删除暂存区，不影响工作区）
git rm --cached hello.txt
3.5、提交至本地库
基本语法
-m 表示添加一个版本日志信息，不写此参数也会打开日志信息的文件框。一般带参数
git commit -m "日志信息" 文件名案例:
3.6、修改文件
案例:
git 里是按照行维护文件的，所以修改内容其实就是之前的行删除，修改过后的行添加进来
因此在commit之后提示信息1 insertion(+), 1 deletion(-)
3.7、历史版本
查看历史版本
基本语法
查看精简版本信息
git reflog
查看详细版本信息
git log案例:
版本穿梭
基本语法
git reset --hard 版本号案例:
文件验证当前版本号
Git 切换版本，底层其实是移动的 HEAD 指针，具体原理如下图所示
四、Git 分支操作
4.1、什么是分支
在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本（分支底层其实也是指针的引用）
4.2、分支的好处
同时并行推进多个功能开发，提高开发效率
各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可
4.3、分支的操作
| 命令 |
作用 |
|
|
创建分支 |
|
|
查看分支 |
|
|
切换分支 |
|
|
把指定的分支合并到当前分支 |
创建分支、查看分支
基本语法
git branch 分支名
git branch -v案例:
切换分支
基本语法
git checkout 分支名案例:
合并分支
基本语法
git merge 分支名案例:
正常合并
冲突合并:
冲突产生的原因：合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改。Git无法替我们决定使用哪一个。必须人为决定新代码内容
解决冲突
创建分支和切换分支图解
master、hot-fix 其实都是指向具体版本记录的指针。当前所在的分支，其实是由 HEAD 决定的。所以创建分支的本质就是多创建一个指针
- HEAD 如果指向 master，那么我们现在就在 master 分支上
- HEAD 如果指向 hotfix，那么我们现在就在 hotfix 分支上
所以切换分支的本质就是移动HEAD指针
五、Git 团队协作机制
5.1、团队内协作
5.2、跨团队协作
