目录
一、版本控制
1. 概念
2. 功能
01 – 不同版本的存储管理
02 – 重大版本的备份维护
03 – 恢复之前的项目版本
04 – 记录项目的点点滴滴
05 – 多人开发的代码合并
3. 历史
01 – 版本控制的史前时代（没有版本控制）
02 – CVS（Concurrent Versions System）
03 – SVN（Subversion）
04 – Git（Linus的作品）
4. 集中式版本控制
01 – 概念
02 – 优点
03 – 缺点
5. 分布式版本控制
二、准备 Git
1. 安装
2. Bash – CMD – GUI 区别
3. Git 的配置分类
01 – 仓库的通用配置
02 – 针对当前用户，所有的仓库生效
03 – 针对该仓库
4. Git 的配置选项
01 – 设置用户名
02 – 设置邮箱
03 – 检测配置信息
5. Git的别名（alias）
三、Git 操作本地仓库
1. 获取Git仓库
01 – 初始化Git仓库
02 – Git拉取远程仓库
2. 文件的状态划分
3. git status
4. git add
5. git commit
6. git merge
7. git log
8. git reflog
9. git reset
10. Git 的忽略文件 GitHub – github/gitignore
1. git 底层原理
四、Git 远程仓库和本地仓库建立联系
1. 概念
2. 本地无仓库，远程有仓库
01 – 远程仓库的验证 – 凭证
拉取代码
输入账 密码
提交代码
删除凭证
windows
mac
02 – 远程仓库的验证 – SSH密钥
one 生成公钥和私钥 生成/添加SSH公钥 – Gitee.com
two 拿到公钥
three 把公钥放置在服务器中
fore拉取代码
3. 本地有仓库，和远程仓库建立连接
01 – 添加远程地址
02 – 建立连接 ( 重要 )
本地有分支，远程有分支
本地有分支，远程没分支
03 – 查看远程仓库地址
04 – 重命名远程仓库别名
05 – 移除远程地址
五、Git 操作远程仓库
1. git clone
2. git push
3. git fetch
4. git merge
5. git pull
六、git tag
1. 创建标签
01 – 轻量标签
02 – 附注标签
2. 查看标签
3. 把打的标签推送到远程仓库中
4. 删除本地tag
5. 删除远程tag
6. 检出tag，回退到打tag的版本
七、git 分支
1. 创建分支
2. 查看分支
3. 切换分支
4. 分支所在HEAD
5. 创建分支并同时切换
6. 在分支上提交图解
01 – 初始状态在master上提交
02 – 创建新分支testing，并在新分支上继续提交
03 – 切换回master分支上，并继续提交
04 – 在master分支上创建新分支dev，并继续提交
7. 分支的开发与合并
01 – 遇到线上bug
02 – 解决完后合并hotfix分支
8. 删除分支
9. 修改分支名称
10. git merge
八、git rebase
1. 使用了merge
2. 使用了rebase
3. 原理
4. rebase和merge的选择
九、总结操作
十、Git常见命令速查表
一、版本控制
1. 概念
- 版本控制的英文是 Version control
- 是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程
版本控制在软件开发中，可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作
2. 功能
01 – 不同版本的存储管理
- 一个项目会不断进行版本的迭代，来修复之前的一些问题、增加新的功能、需求，甚至包括项目的重构
- 如果我们通过手动来维护一系列的项目备份，简直是一场噩梦
02 – 重大版本的备份维护
- 对于很多重大的版本，我们会进行备份管理
03 – 恢复之前的项目版本
- 当我们开发过程中发生一些严重的问题时，想要恢复之前的操作或者回到之前某个版本
04 – 记录项目的点点滴滴
- 如果我们每一个功能的修改、bug的修复、新的需求更改都需要记录下来，版本控制可以很好的解决
05 – 多人开发的代码合并
- 项目中通常都是多人开发，将多人代码进行合并，并且在出现冲突时更好的进行处理
3. 历史
01 – 版本控制的史前时代（没有版本控制）
-
人们通常通过文件备份的方式来进行管理，再通过diff命令来对比两个文件的差异
02 – CVS（Concurrent Versions System）
- 第一个被大规模使用的版本控制工具，诞生于1985年
-
由荷兰阿姆斯特丹VU大学的Dick Grune教授实现的，也算是SVN的前身（SVN的出现就是为了取代CVS的）
03 – SVN（Subversion）
- 因其命令行工具名为svn因此通常被简称为SVN
- SVN由CollabNet公司于2000年资助并发起开发，目的是取代CVS，对CVS进行了很多的优化
- SVN和CVS一样，也属于集中式版本控制工具
- SVN在早期公司开发中使用率非常高，但是目前已经被Git取代
04 – Git（Linus的作品）
- 早期的时候，Linux 区使用的是BitKeeper来进行版本控制
- 但是因为一些原因，BitKeeper想要收回对Linux 区的免费授权
- 于是Linus用了大概一周的时间，开发了Git用来取代BitKeeper
- Linus完成了Git的核心设计，在之后Linus功成身退，将Git交由另外一个Git的主要贡献者Junio C Hamano来维护
4. 集中式版本控制
01 – 概念
- CVS和SVN都是是属于集中式版本控制系统（Centralized Version Control Systems，简称 CVCS）
- 它们的主要特点是单一的集中管理的服务器，保存所有文件的修订版本
- 协同开发人员通过客户端连接到这台服务器，取出最新的文件或者提交更新
02 – 优点
相较于老式的本地 管理来说，每个人都可以在一定程度上看到项目中的 其他人正在做些什么
03 – 缺点
是集中式版本控制有一个核心的问题：中央服务 器不能出现故障
- 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作
- 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据
5. 分布式版本控制
Git是属于分布式版本控制系统（Distributed Version Control System，简 称 DVCS）
- 客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录
- 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复
- 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份
集中式版本控制 : 将仓库放到服务器，一旦服务器崩溃可能会导致代码及记录都消失
分布式版本控制 : 通过git clone把仓库完全镜像到本地，就算服务器出现问题也没有关系，记录和代码会在本地仓库保存一份，提交到远程仓库时会进行同步刷新
二、准备 Git
1. 安装
git : Git – Downloads
2. Bash – CMD – GUI 区别
-
Bash，Unix shell 的一种，Linux 与 Mac OS X 都将它作为默认 shel
- Git Bash 就是一个 shell，是 Windows 下的命令行工具，可以执行 Linux 命令
- Git Bash 是基于 CMD 的，在 CMD 的基础上增添一些新的命令与功能
- 所以建议在使用的时候，用 Bash 更加方便
-
Git CMD
- 命令行提示符（CMD）是 Windows 操作系统上的命令行解释程序
- 当你在 Windows 上安装 git 并且习惯使用命令行时，可以使用 cmd 来运行 git 命令
-
Git GUI
- 基本上针对那些不喜欢黑屏（即命令行）编码的人
- 它提供了一个图形用户界面来运行 git 命令
3. Git 的配置分类
Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量
01 – 仓库的通用配置
地址 : /etc/gitconfig => 包含系统上每一个用户及他们仓库的通用配置
- 如果在执行 git config 时带上 –system 选项，那么它就会读写该文件中的配置变量
- 由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它
- 开发中通常不修改
02 – 针对当前用户，所有的仓库生效
地址 : ~/.gitconfig => 只针对当前用户
- 可以传递 –global 选项让 Git 读写此文件，这会对你系统上所有的仓库生效
03 – 针对该仓库
地址 : 当前使用仓库的 Git 目录中的 config 文件，即.git/config => 针对该仓库
- 可以传递 –local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它
4. Git 的配置选项
设置Git的 用户名和邮件地址
01 – 设置用户名
02 – 设置邮箱
03 – 检测配置信息
5. Git的别名（alias）
如果不想每次都输入完整的 Git 命令
可以通过 git config 文件来轻松地为每一个命令设置一个别名
命令 : git checkout
设置别名 : git config –global alias.co checkout
使用 : git co
三、Git 操作本地仓库
1. 获取Git仓库
需要一个Git来管理源代码，本地也需要有一个Git仓库
通常有两种获取 Git 项目仓库的方式：
- 方式一：初始化一个Git仓库，并且可以将当前项目的文件都添加到Git仓库中（目前很多的脚手架在创建项目时都会默认创建一个Git仓库）
- 方式二：从其它服务器 克隆（clone） 一个已存在的 Git 仓库（第一天到公司通常我们需要做这个操作）
01 – 初始化Git仓库
git init
- 该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的核心
- 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪
02 – Git拉取远程仓库
git clone 地址
2. 文件的状态划分
需要对文件来划分不同的状态，以确定这个文件是否已经归于Git仓库的管理：
- 未跟踪：默认情况下，Git仓库下的文件没有添加到Git仓库管理中，需要通过add命令来操作
- 已跟踪：添加到Git仓库管理的文件处于已跟踪状态，Git可以对其进行各种跟踪管理
通过使用 ( git add . ) 命令，可以使得文件被git跟踪，文件状态变为暂缓区
ps : 但是此时的文件并没有和commit对象建立联系，git log查看不到更改的记录
已跟踪的文件又可以进行细分状态划分：
- staged：暂缓区中的文件状态
- Unmodified：commit命令，可以将staged中文件提交到Git仓库
-
Modified：修改了某个文件后，会处于Modified状态
不管是新增的文件、修改的文件，都需重新让 add && commit
3. git status
git status => 检测文件的状态
git status -s || git status –short => 文件状态的简洁信息
4. git add
git add => 文件添加到暂存区
git add 文件 => 跟踪新文件,并将其加入到暂存区
git add . => 将所有文件加入到暂存区
5. git commit
git commit => 文件更新提交，将暂存区的文件提交，和commit对象联系在一起
git commit –m “提交信息” => 提交文件，并写上记录
git commit –no-verify -m “XXX” => 忽略提交限制，一般eslint有
git commit -a -m “haha” => 相当于 git add. -> git commit -m ‘haha’ 的简写
6. git merge
git merge => 合并两分支代码 => git merge xxx分支名称
git merge dev –allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并，可加 )
7. git log
git log => 查看一下所有的历史提交记录
git log => 详细记录
git log –oneline => 好看一点的记录
git log –pretty=oneline => 更好看一点的记录
git log –pretty=oneline –graph => 可以看到多分支的记录
ps : 空格继续看记录，q是退出键
8. git reflog
git reflog => 不仅可以查看历史提交记录，而且切换版本的记录也会留下来
9. git reset
git reset => 版本回退
Git通过HEAD指针记录当前版本 :
- HEAD 是当前分支引用的指针，它总是指向该分支上的最后一次提交
- 理解 HEAD 的最简方式，就是将它看做 该分支上的最后一次提交 的快照
- 切换版本就是在改HEAD的指向
可以通过HEAD来改变Git目前的版本指向( 切换版本 )
- 上一个版本就是HEAD^，上上一个版本就是HEAD^^ => git reset –hard HEAD^
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！