Git - 基本原理与分支管理

【1】分支基础

① 什么是分支

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

这里写图片描述


② 分支的好处?

同时并行推进多个功能开发,提高开发效率。

各个分支在开发过程中,如果某一个分支开发失败,不会对其他分支有任
何影响。失败的分支删除重新开始即可。


【2】分支操作

① 创建分支

git branch [分支名]

这里写图片描述


② 查看分支

git branch -v

③ 切换分支

git checkout [分支名]

这里写图片描述


④ 合并分支

如下所示,修改hot_fix分支中的apple.txt,然后提交:

这里写图片描述

那么如何合并到master中呢?

第一步:切换到接受修改的分支(被合并,增加新内容)上

git checkout [被合并分支名]
# git checkout master

第二步:执行merge 命令

git merge [有新内容分支名]
# git merge hot_fix

这里写图片描述


当然也可以将master合并到hot_fix :

这里写图片描述


⑤ 解决冲突

冲突的表现:

比如master中修改apple.txt第三行如下图:
这里写图片描述
hot_fix中修改apple.txt第三行如下图:
这里写图片描述

再次切换到master合并hot_fix,apple.txt将会出现冲突现象:

这里写图片描述


冲突的解决

第一步:编辑文件,删除特殊符号;
第二步:把文件修改到满意的程度,保存退出;
第三步:git add [文件名];
第四步:git commit -m "日志信息"。
注意:此时commit 一定不能带具体文件名

这里写图片描述


【3】哈希

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

①不管输入数据的数据量有多大,输入同一个哈希算法,得到的加密结果长度固定。
②哈希算法确定,输入数据确定,输出数据能够保证不变。
③哈希算法确定,输入数据有变化,输出数据一定有变化,而且通常变化很大。
④哈希算法不可逆。

Git 底层采用的是SHA-1 算法。

这里写图片描述


哈希算法可以被用来验证文件。原理如下图所示:

这里写图片描述

Git 就是靠这种机制来从根本上保证数据完整性的。


【4】Git 保存版本的机制

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

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

这里写图片描述

即,获取到的完整文件是基本文件拼接各个“差异”得来的。


② Git 的文件管理机制

Git 把数据看作是小型文件系统的一组快照。每次提交更新时Git 都会对当前
的全部文件制作一个快照并保存这个快照的索引。

为了高效,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。所以Git 的工作方式可以称之为快照流。

这里写图片描述


③ Git 文件管理机制细节

  • Git 的“提交对象”

这里写图片描述


  • 提交对象及其父对象形成的链条

这里写图片描述


【5】Git 分支管理机制

Git分支管理的本质是创建和移动指针。

① 分支的创建
这里写图片描述


② 分支的切换

这里写图片描述

切换分支后,提交新的内容:

这里写图片描述


再次切换回主分支:

这里写图片描述


主分支提交内容:

这里写图片描述


【6】Git工作流

Git工作流其实就是在项目开发过程中使用Git 的方式。

① 分类

  • 集中式工作流

像SVN 一样,集中式工作流以中央仓库作为项目所有修改的单点实体。所有
修改都提交到Master 这个分支上。

这种方式与SVN 的主要区别就是开发人员有本地库。Git 很多特性并没有用到。

这里写图片描述


  • GitFlow 工作流(最为经典的方式)

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

这里写图片描述


  • Forking 工作流

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

这里写图片描述


【7】GitFlow工作流详解

① 分支种类

  • 主干分支master

主要负责管理正在运行的生产环境代码。永远保持与正在运行的生产环境
完全一致。

  • 开发分支develop

主要负责管理正在开发过程中的代码。一般情况下应该是最新的代码。

  • bug 修理分支hotfix

主要负责管理生产环境下出现的紧急修复的代码。从主干分支分出,修
理完毕并测试上线后,并回主干分支。并回后,视情况可以删除该分支。

  • 准生产分支(预发布分支) release

较大的版本上线前,会从开发分支中分出准生产分支,进行最后阶段的集
成测试。该版本上线后,会合并到主干分支。生产环境运行一段阶段较稳定后
可以视情况删除。

  • 功能分支feature

为了不影响较短周期的开发工作,一般把中长期开发模块,会从开发分支
中独立出来。开发完成后会合并到开发分支。


② GitFlow 工作流举例

这里写图片描述


③ 分支实战图示

如下图所示 lhc创建分支featureA并推送到远程仓库featureA分支。

ybq从远程仓库拉取下来进行测试并合并到master分支后,推送到远程Master分支。

这里写图片描述


④ 分支实战具体操作

首先是lhc的操作。

  • 创建分支

项目右键-Team-Switch To-New Branch

这里写图片描述

这里写图片描述


  • 在新分支hot_fix中修改代码并提交本地库

这里写图片描述

这里写图片描述


  • 将hot_fix推送到远程库

这里写图片描述


  • 查看GitHub远程库
    这里写图片描述

接下来是ybq的操作。

  • 从远程库拉取到本地
项目-右键-pull

  • 切换分支审查代码
项目-右键-Team-Switch To -Other

这里写图片描述


  • 选择Remote Tracking下的origin/hot_fix,然后点击Check Out

这里写图片描述

  • finish

这里写图片描述

此时项目自动切换到hot_fix,可以看到lhc修改的代码。


  • 审查代码过后,切换回master,准备合并

这里写图片描述


  • 合并代码
项目-右键-Team-Merge

这里写图片描述
这里写图片描述


  • 将合并后的master推送到远程仓库

这里写图片描述

猜你喜欢

转载自blog.csdn.net/J080624/article/details/81288484