版本控制Git 黑马&尚硅谷

Git的前世今生

方向介绍

为什么要学习Git

1.0 Git是什么

1.1 版本控制

1.1.1 本地版本控制

1.1.2 集中版本控制

1.1.3 分布式版本控制

我们已经把三个不同的版本控制系统介绍完了，Git 作为分布式版本控制工具，

虽然目前来讲是最先进使用最广的，但是其实在最开始，他也不是第一个出现的分布式版本控制软件，

接下来我们就介绍一下 Git 的发展历史，以及现在市面上基于 Git 演进的各种平台

1.2 Git发展历史

由于 bitkeeper 不是开源的，所以一开始其实 linux 团队的人就很排斥使用该软件

BitKeeper 是一个专有软件，由于 Linux 项目的一个开发人员，写了一个工具 去连接 BitKeeper, 因此被怀疑是对 Bitkeeper 做了逆向工程，

因此这个公司就不允许 Linux 团队继续使用；有兴趣的可以可以自己去看 Git 的最早的代码历史

随着 Git 的发展，基于 Git 也衍生出了很多平台 除此之外，还有 BitBucket, Coding, 码云，阿里云效平台等等，每个平台都有自己的使用场景和优势， 我们选择最合适自己的平台即可

2.0 Git基本使用方式

在这一节中，我们会演示很多基本的 Git 命令，我们会在操作过程中通过 Git 仓库目录的变化来讲述 Git 的原理，在这个过程中，希望同学们能够跟随我来一起完成这些 Git 操作，通过这个实际操作的过程更深刻的去理解这些命令

常见问题

1.没配置 权限秘钥；

2.1 Git 目录介绍

tree .git /F 查看文件 type

HEAD 表示当前指向的分支；config 当前仓库的配置；hooks 配置hook

Object 存储文件信息； refs 存储分支信息；

改代码新建文件 都是在工作区； Git add 加到暂存区；最后commit提交

重点关心一下这个 git 目录，因为我们后续每一个 git 操作都会映射到这个 git 目录之中，通过这里面的文件我们可以映射出所有版本的代码

2.1.1 Git Config

git 配置到底是个什么东西呢，我们又可以配置哪些内容呢，我们一起来了解一下 Git 配置这个概念

local 存在当前.git目录下的config文件； system系统文件配置存在/etc/gitconfig；全局global 存 在当前用户的.gitconfig下

级别：system > global > local

2.1.2 常见 git配置

2.2 Git Remote

Remote： 本地仓库与远端的关联信息

一个仓库拥有多个 remote， 从没有写权限的仓库 fetch 代码，push 到自己有权限的仓库

2.2.1 HTTP Remote

我们知道了什么是 remote 配置后，那我们本地是如何与 remote 进行通信的呢，

一般会通过 http 和 ssh 两种协议，这两种协议都需要对身份进行认证，

类似 go 这种语言，依赖库很多，所以我们需要不断的输入认证的账号密码，肯定是一件很麻烦的事情，因此我们需要配置一下免密的认证方式

一般情况，不推荐从HTTP访问Git，不那么安全，方便

2.2.2 SSH Remote

配置公司钥 还是拉取不下来代码问题 可能原因之一：

存在一种新版本 Windows代码不允许 使用dsa和rsa的key；在SSH层面拒绝访问

2.3 Git Add

（再次强调观察文件变化）了解好基本的 Git 配置后，我们会重点关注一下 Git 命令的原理，接下来我们一起来进行代码的编写和提交，在这个过程中，我们会更深入的去观察 git 目录下的内容变化，来理解我们执行的 git 命令到底做了什么，git 又是如何把代码通过版本管理起来的

2.4 Git Commit

2.5 Object

2.6 Refs

除了 objects 文件有变化，我们发现 refs 的文件内容也有变化

git checkout -b test #切换到新分支

2.7 附注标签

2.8 追溯历史版本

2.9 修改历史版本

2.10 Objects

2.11 Git GC

不设置为过期的话 在日志里面 还能看到 老的commit引用 ，就不能通过GC真实地删掉他

2.12 完整的 Git视图

将 Git 完整的视图描述一遍，重新强调 git 是怎么存储代码历史的。讲完了 Git 本地的存储方式，

引出多人合作和远端仓库同步的概念，从而进入到 Git Clone Pull Fetch 的内容

2.13 Git Clone&Pull&Fetch

2.14 Push 将本地代码 同步至远端

开篇 问题解答

3.0 Git研发流程

常见问题

3.1 不同的工作流

3.2 集中式工作流

3.2.1 集中式工作流-Gerrit

3.3 分支管理工作流

3.3.1 分支管理工作流 Git Flow

3.3.2 分支管理工作流 Github Flow

Branch protection rule

1、必须和request merge 才能提交；1.1、必须有其它人同意才能提交

2、check；3、讨论都被解决了才能提交；4、线性历史(阻止merge节点的产生)；

Include Adamin...5、保护 对admin也生效（admin 不能为所欲为）

3.3.3 分支管理工作流 Gitlab Flow

总结这几个工作流的共性是都需要通过 git merge 来合入代码，从而引出介绍代码合并的方式

3.4 代码合并

3.5 如何选择合适的工作流

我们刚刚介绍了不同的工作流方式，以及他们的合入原理，其中有集中式工作流，和分支管理工作流，分支管理又分成典型的 GitFlow, Gitlab Flow, Github Flow，

我们有这么多工作流可以选择，那我们又该如何去选择合适的工作流呢。

常见问题答案

总结课程内容

Git 是一个分布式版本控制工具，由 linus 开发，衍生出 github gitlab gerrit 等平台

Git 配置，Git 代码提交，Git 代码同步基本命令，以及 git 管理代码的原理，帮助我们更好的知道如何正确使用 Git 命令

讲述不同的研发流程，有以 gerrit 为代表的集中式工作流，和 gitlab/github 为代表的分支管理工作流，讲述了一些代码提交规范，保护分支，codereview 等概念，帮助我们规范研发流程

希望同学们能够从这节课程中学习到如何使用 Git，以及如何规范我们的研发流程，从而来提升我们的开发效率，以及提升我们的代码质量

非常感谢您阅读到这里，创作不易！如果这篇文章对您有帮助，希望能留下您的点赞👍 关注💖 收藏 💕评论💬感谢支持！！！