大纲
1.Git工作流程是什么
Git工作流程是有关如何使用Git以一致且富有成效的方式完成工作的秘诀或建议。
Gitflow 工作流定义了一个围绕项目发布的严格分支模型。
Gitflow 工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FSHFBgjZ-1621491278010)(https://best2geek.com/img/git-model.png)]
2.为什么需要Git工作流程
Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。
Git 作为一个源码管理系统，不可避免涉及到多人协作。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。“工作流程"在英语里，叫做"workflow"或者"flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
清晰可控，使多人项目协作开发更加规范。
3.有那些广泛的Git工作流程
软件业界常用的软件分支流程有多种，但本质上可以分为两类：
- 主干开发模式（Trunk Based Development）
- 特性分支开发模式（Feature Branch Development）
3.1-主干开发模式
主干开发，是指开发人员直接向主干（习惯上主干分支通常为：trunk 或 master）提交/推送代码。通常，开发团队的成员1天至少1次地将代码提交到主干分支。在到达发布条件时，从主干拉出发布分支（通常为 release），用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。
流程：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c7cfiiRV-1621491278014)(https://best2geek.com/img/tbd.png)]
优点：
- 分支模型简单高效，开发人员易于掌握不容易出现错误操作
- 避免了分支合并、冲突解决的困扰
- 随时拥有可发布的版本
- 有利于持续集成和持续交付
缺点：
- 基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关；
- 自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能在获得快速和可靠的质量反馈；
- 最好有代码评审：若代码质量要求高，需要配套代码评审（CR）机制，在代码提交到主干时，触发CR，通过 Peer Review 后才能正式合入；
- 最好有特性开关：主干开发频发合入主干的情况下，特性拆分得很小，可能是半成品特性，需要配套特性开关（Feature Toggle），只有当特性整体开发完才通过灰度发布等手段逐步打开；
适用环境：
- 对迭代速度要求高，希望需求快速交付上线
- 基础架构强，持续集成工具高效；
- 团队成员习惯TDD（测试驱动开发），代码自动化测试覆盖率高（至少增量代码的自动化测试覆盖率高）；
3.2-特性分支开发模式
也称为"功能驱动式开发"（Feature-driven development，简称FDD），它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
一般流程就是创建一个或多个特定的需求/缺陷/任务创建代码分支（branch），在其上完成相应的开发（一般经过增量测试）后，把它合并（merge）到主干/集成分支。
通常这种分支生命期会持续一段时间，从几天到几周不等，极少数情况甚至以月算。
流程：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s6S8GzJ7-1621491278016)(https://best2geek.com/img/fbd.png)]
优点：
- 特性开发周期宽松：因为生命期可以较长，较大的需求特性可以在宽松的时间内完成再合入主干；
- 分支测试的时间宽松：因为生命期可以较长，可以有较多时间对分支进行测试，甚至手工测试；
缺点：
- 分支管理复杂：原因在于大量采用代码分支，且来源分支和合入目标分支各异，操作复杂 —— 以上图为例，可以从master（Tag 1.0.0） 拉出 hotfix 1.0.2 分支，然后合入到 develop 分支，开发阶段结束后合入到 release branches，发布后合入 master，非常复杂，很容易出错；
- 合并冲突多、解决难：分支生命期越长，意味着与主干的代码差异越大，冲突概率越高，冲突的解决难度越大（甚至成为不可能）；
- 迭代速度慢：特性分支生命期长（数天至数周）意味着特性上线速度慢，相应的迭代速度也慢；
- 需要较多测试环境：每个特性分支都需要分配至少1个测试环境，且长期占用（有状态）；
适用环境：
- 对版本迭代速度要求不高
- 测试自动化程度低，或说主要靠人工测试的
特性分支开发模式三种开发流程：
Git相关教程：
4.如何使用Git工作流程
4.1-Git flow
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
它最主要的特点有两个。
- 主分支
master - 开发分支
develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
- 功能分支（feature branch）
- 补丁分支（hotfix branch）
- 预发分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
Git分支管理
A.主分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
B.开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
Git创建Develop分支的命令：
git checkout -b develop master
将Develop分支发布到Master分支的命令：
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop
上一条命令的–no-ff参数说明：
默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
使用–no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Git Workflow》。
C.临时性分支
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
- 功能（feature）分支
- 预发布（release）分支
- 修补bug（bugfix）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
bugfix听起来很像hotfix，但是区别在于更正的时间和执行。
bugfix通常描述在生产或测试阶段甚至在产品正常发布周期中部署后发现并解决的问题。
hotfix仅在产品发布并投入使用后才适用。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2YQwdFdZ-1621491278024)(https://best2geek.com/img/patch-hotfix-coldfix-bugfix.png)]
C1.功能分支
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
git checkout -b feature-x develop
开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x
删除feature分支：
git branch -d feature-x
C2.预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
创建一个预发布分支：
git checkout -b release-1.2 develop
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
C3.修补bug分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1
4.2-Github flow
略
4.3-Gitlab flow
略
References:
扫一扫
526
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
