【Git】工做流

Git 工做流

概念

在项目开发过程当中使用 Git 的方式

分类

集中式工做流

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

GitFlow 工做流

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

Forking 工做流

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

GitFlow 工做流详解

分支种类

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

GitFlow 工做流举例

分支实战

具体操做

建立分支

切换分支审查代码

检出远程新分支

切换回 master

合并分支

合并结果

合并成功后，把 master