笔记视频：https://www.bilibili.com/video/BV1pW411A7a5?p=24

1. 版本控制工具应该具备的功能

协同修改
- 多人并行不悖的修改服务器端的同一个文件。
数据备份
- 不仅保存目录和文件的当前状态，还能够保存每一个提交过的历史状态。
版本管理
- 在保存每一个版本的文件信息的时候要做到不保存重复数据，以节约存储空间，提高运行效率。这方面 SVN 采用的是增量式管理的方式，而 Git 采取了文件系统快照的方式。
权限控制
- 对团队中参与开发的人员进行权限控制。
- 对团队外开发者贡献的代码进行审核——Git 独有。
历史记录
- 查看修改人、修改时间、修改内容、日志信息。
- 将本地文件恢复到某一个历史状态。
分支管理
- 允许开发团队在工作过程中多条生产线同时推进任务，进一步提高效率。

2. 版本控制简介

2.1版本控制

工程设计领域中使用版本控制管理工程蓝图的设计过程。在 IT 开发过程中也可以使用版本控制思想管理代码的版本迭代。

2.2版本控制工具

思想：版本控制
实现：版本控制工具

集中式版本控制工具：

CVS、SVN、VSS……

分布式版本控制工具：

Git、Mercurial、Bazaar、Darcs……

3. Git 简介

3.1 Git 简史

3.2 Git 的优势

大部分操作在本地完成，不需要联网
完整性保证
尽可能添加数据而不是删除或修改数据
分支操作非常快捷流畅
与 Linux 命令全面兼容

3.3 Git 结构

git 的本地结构

3.6 Git 和代码托管中心

代码托管中心是用于维护远程库

局域网环境下
- GitLab 服务器
外网环境下
- GitHub
- 码云

3.7 本地库和远程库

3.7.1 团队内部协作

3.7.2 跨团队协作

4. Git 命令行操作

4.1 本地库初始化

命令：git init
效果
注意：.git 目录中存放的是本地库相关的子目录和文件，不要删除，也不要胡乱修改。

4.2 设置签名

作用：区分不同开发人员的身份
形式
- 用户名：tom
- Email 地址：goodMorning@atguigu.com
辨析：这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。
命令
- 项目级别/仓库级别：仅在当前本地库范围内有效
  - git config user.name tom_pro(_pro 只是一个标识 project)
  - git config user.email goodMorning_pro@atguigu.com
  - 信息保存位置：./.git/config 文件

系统用户级别：登录当前操作系统的用户范围
- git config —global user.name tom_glb
- git config —global goodMorning_pro@atguigu.com
- 信息保存位置：~/.gitconfig 文件

级别优先级
- 就近原则：项目级别优先于系统用户级别，二者都有时采用项目级别的签名
- 如果只有系统用户级别的签名，就以系统用户级别的签名为准
- 二者都没有不允许
  - 存放目录：.git/config

4.3基本操作

4.3.1 状态查看

git status

查看工作区、暂存区状态

4.3.2 添加

git add [file name]

将工作区的“新建/修改”添加到暂存区、

如果之前已经被追踪过（之前添加到了暂存区），可以直接使用 “commit” 进行提交

4.3.3 提交

git commit -m “commit message” [file name]

将暂存区的内容提交到本地库

4.3.4 查看历史记录

git log

多屏显示控制方式：
- 空格向下翻页
- 向上翻页
- 退出
git log —pretty=oneline

git log —oneline
- 只显示指向当前版本的历史版本

git reflog

HEAD@{移动到当前版本需要多少步}

4.3.5 版本跳转

本质

基于索引值操作[推荐]
- git reset —hard [局部索引值]
- git reset —hard a6ace91
使用 ^ 符号：只能后退
- git reset —hard HEAD^
- 注：一个^表示后退一步，n 个表示后退 n 步
使用 ~ 符号：只能后退
- git reset —hard HEAD~n
- 注：n 表示后退 n 步

4.3.6 reset命令的三个参数对比

—soft 参数
- 仅仅在本地库移动 HEAD 指针

—mixed 参数
- 在本地库移动 HEAD 指针
- 重置暂存区

—hard 参数
- 在本地库移动 HEAD 指针
- 重置暂存区
- 重置工作区

4.3.7 删除文件并找回

前提：删除前，文件存在时的状态提交到了本地库。
操作：git reset —hard [指针位置]
- 删除操作已经提交到本地库：指针位置指向历史记录
- 删除操作尚未提交到本地库：指针位置使用 HEAD

4.3.8 比较文件差异

git diff [文件名]
- 将工作区中的文件和暂存区进行比较
git diff [本地库中历史版本] [文件名]
- 将工作区中的文件和本地库历史记录比较
git diff
- 不带文件名比较多个文件

4.3.9 更新git

git —vertion
- 查看当前版本
git update
- git版本是2.17.1之前的
git update-git-for-windows
- git版本是2.17.1之后的

4.4 分支管理

4.4.1 什么是分支？

在版本控制过程中，使用多条线同时推进多个任务。

4.4.2 分支的好处？

同时并行推进多个功能开发，提高开发效率
各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

4.4.3 分支操作

创建分支
git branch [分支名]
查看分支
git branch -v
切换分支
git checkout [分支名]
合并分支
- 第一步：切换到接受修改的分支（被合并，增加新内容）上
  git checkout [被合并分支名]
- 第二步：执行 merge 命令
  git merge [有新内容分支名]
解决冲突
- 冲突的表现

冲突的解决
- 第一步：编辑文件，删除特殊符号
- 第二步：把文件修改到满意的程度，保存退出
- 第三步：git add [文件名]
- 第四步：git commit -m “日志信息”
  - 注意：此时 commit 一定不能带具体文件名

5. Git 基本原理

5.1 哈希(Hash)

哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下几个共同点：

①不管输入数据的数据量有多大，使用同一个哈希算法，得到的加密结果长度固定（16字节）。

②哈希算法相同，输入数据相同，输出数据能够保证不变

③哈希算法相同，输入数据有变化，输出数据一定有变化，而且通常变化很大

④哈希算法不可逆

Git 底层采用的是 SHA-1 算法。哈希算法可以被用来验证文件。原理如下图所示：

5.2 Git 保存版本的机制

5.2.1 集中式版本控制工具的文件管理机制

以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

5.2.2 分布式版本控制工具的文件管理机制

Git 把数据看作是小型文件系统的一组快照。每次提交更新时 Git 都会对当前的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改， Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。所以 Git 的工作方式可以称之为快照流。

5.2.3 Git文件管理机制细节

Git 的“提交对象”（第一个版本）

提交对象（第一个版本）及其父对象（上一个版本）形成的链条
- 每一个版本都保存着上一个版本的 Hash 值

5.3Git 分支管理机制

5.3.1 分支的创建

SVN 是把文件整个复制一份

Git 是新建一个指针指向提交对象

5.3.2 分支的切换

把 HEAD 指针指向了分支

此时提交内容会影响 testing 的指向，而不会影响 master

5.3.3 分支的提交

分支指针指向了另一个提交对象

此时 mster 也提交了数据，master 和 testing 将会指定两个不同的对象

master 和 testing 的父对象是相同的

6. GitHub

6.1 注册账号

6.2 创建远程仓库

6.3创建远程库地址别名

简化了推送的过程，不需要在 push 后面跟远程仓库地址

git remote -v 查看当前所有远程地址别名
git remote add [别名] [远程地址]

6.4 推送

git push [别名] [分支名]
- 远程库与本地库一致才可以推送，否则会推送失败
- 如果是团队合作可以 pull 之后再推送

6.5 克隆

命令
- git clone [远程地址]
效果
- 完整的把远程库下载到本地
- 创建 origin 远程地址别名
- 初始化本地库

6.6 团队成员邀请

“岳不群”使用其他方式把邀请链接发送给“令狐冲”，“令狐冲”登录自己的 GitHub

账号，访问邀请链接接受邀请。

6.7 拉取远程库

pull=fetch+merge
git fetch [远程库地址别名] [远程分支名]
- 只把远程库下载到本地，并不会改变本地工作区的文件
- git checkout [远程库地址别名/远程分支名] 切换为拉取下来的仓库分支
- 再使用 cat 就可以查看内容
git merge [远程库地址别名/远程分支名]
git pull [远程库地址别名] [远程分支名]

6.8 解决冲突

要点
- 如果不是基于 GitHub 远程库的最新版所做的修改，不能推送，必须先拉取。
- 拉取下来后如果进入冲突状态，则按照“分支冲突解决”操作解决即可。

6.9 跨团队协作

团队以外的成员 Fork 下来（复制一份）

本地修改，然后推送到远程
其中有一系列操作（clone commit…）
Pull Request(拉取请求，申请原仓库的合并同意)

发送描述信息

查看请求（原仓库）

交流

审核代码

合并代码

将远程库修改拉取到本地

6.10 SSH登录

进入当前用户的家目录
$ cd ~
删除.ssh 目录
$ rm -rvf .ssh
运行命令生成.ssh 密钥目录
$ ssh-keygen -t rsa -C [邮箱
[注意：这里-C这个参数是大写的 C]
进入.ssh 目录查看文件列表
$ cd .ssh
$ ls -lF
查看 id_rsa.pub 文件内容
$ cat id_rsa.pub
复制 id_rsa.pub 文件内容，登录 GitHub，点击用户头像→Settings→SSH and GPG keys
New SSH Key
输入复制的密钥信息
回到 Git bash 创建远程地址别名
git remote add origin_ssh git@github.com:atguigu2018ybuq/huashan.git
推送文件进行测试

6.11 如何寻找开源项目

可以叠加条件进行查询

按照项目名/仓库名搜索（大小写不敏感）
- in:name xxx
按照 README搜索（大小写不敏感）
- in:readme xxx
按照 description 搜索（大小写不敏感）
- in:description xxx
stars 数大于 xxx
- stars:>xxx
forks 数大于 xxx
- forks:>xxx
编程语言为 xxx
- language:xxx
最新更新时间晚于 YYYY-MM-DD
- pushed:>YYYY-MM-DD

7. Git 工作流

视频地址：https://www.bilibili.com/video/BV1pW411A7a5?p=54

7.1 分类

7.1.1 集中式工作流

像 SVN 一样，集中式工作流以中央仓库作为项目所有修改的单点实体。所有修改都提交到 Master 这个分支上。这种方式与 SVN 的主要区别就是开发人员有本地库。Git 很多特性并没有用到

7.1.2 GitFlow 工作流

Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

7.1.3 Forking工作流

Forking 工作流是在 GitFlow 基础上，充分利用了 Git 的 Fork 和 pull request 的功能以达到代码审核的目的。更适合安全可靠地管理大团队的开发者，而且能接受不信任贡献者的提交。

7.2 GitFlow工作流详解

7.2.1 分支各类

主干分支 master
- 主要负责管理正在运行的生产环境代码。永远保持与正在运行的生产环境完全一致。
开发分支 develop
- 主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。
bug 修理分支 hotfix
- 主要负责管理生产环境下出现的紧急修复的代码。从主干分支分出，修理完毕并测试上线后，并回主干分支。并回后，视情况可以删除该分支。
准生产分支（预发布分支） release
- 较大的版本上线前，会从开发分支中分出准生产分支，进行最后阶段的集成测试。该版本上线后，会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除。
功能分支 feature
- 为了不影响较短周期的开发工作，一般把中长期开发模块，会从开发分支中独立出来。开发完成后会合并到开发分支。

Git&GitHub