GIT工作流程

Git工作流程

Git 能从众多版本控制系统中脱颖而出，其’必杀技特性’是其分支模型，Git分支模型使版本的分支合并起来非常的方便。但是滥用其分支特性也会产生副作用，很可能会出现一个纷乱丛生、结构复杂的分支系统。于是Vincent Driessen 提出了一个分支管理模型Git-Flow。它可以使版本库的更新迭代结构清晰，各分支各司其职~

Git-Flow

• Master – 线上分支（发布分支，长期存在）
• Develop – 开发分支（本地分支，长期存在）
• Feature – 新功能分支
• Release – 预热分支（预发布分支）
• Hotfix – 修复分支（Bug分支）

---

需求是开发的起点，当我们进行功能开发时，先有需求再有功能分支（feature branch）。功能分支是从Develop分支上面分出来的，完成新功能后，该分支上的功能就被合并到Develop分支上，然后删除 Feature分支。

---

当develop分支积累足够的功能（预定的发布日期临近），就可以建立一个预发布分支（release branch）。预发布分支是从Develop分支上面分出来的，预发布结束以后，再合并到 Develop 和 Master 分支，然后删除 Release 分支。

---

当功能正常运行后，如果遇到紧急问题需要修复，这个时候需要创建一个独立的修复分支（hotfix branch）。修复分支是从Master分支上面分出来的，当问题修复之后，再合并到 Develop 和 Master 分支，然后删除 Hotfix 分支。

---

优点：

• 结构清晰
• 适合大型团队

缺点：

• 相对复杂
• 频繁切换分支
• 维护两个长期分支 Master 和 Develop
• 不太适合"持续发布"的项目

Github-Flow

Github flow是Git flow的简化版，专门配合"持续发布"。它是 Github使用的工作流程。

它只有一个长期分支，就是Master分支。官方流程如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ONIs1aPo-1578238409057)(images/QQ截图20191201210343.png)]

1. 根据需求，从Master分支拉出新的分支，不区分功能分支与补丁分支。
2. 在分支中的增删改查都要进行提交，会保留一个清晰的历史记录。
3. 你可以在开发过程中任意时刻发起一个Pull Request，让别人看到你的请求（困难、想法、建议、工作）。
4. 大家一起评审、讨论、评论你的代码，对话过程中，你还可以不断提交代码。
5. 部署阶段，合并之前你可以在生产分支中进行最终测试，根据测试结果选择合并还是回滚。
6. 验证通过，合并代码到Master分支，合并请求后，如果有对应的问题，对应的问题也将被关闭。

优点：

• 简单
• 适合"持续发布"的项目

缺点：

• 线上版本 < Master分支（无法控制发布时间，IOS应用商店功能审核）
• 需要多维护一个 Production 分支来追踪线上版本

Gitlab-Flow

Gitlab flow是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。

持续发布

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KO5SvsoY-1578238409065)(images/gitlab_flow_production_branch.png)]
在 Master 分支之外建立线上 Production 分支，有新需求的情况下，以 Master 分支为基础迁出一个分支进行开发，功能完成之后 merge 到 Master 分支，确认没问题后 merge 到 Production 分支。 Master 分支被称为上游分支，代码的变化必须由"上游"向"下游"发展。

版本发布

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-weWtJaI7-1578238409068)(images/gitlab_flow_release_branches.png)]
对于"版本发布"的项目，才会使用发布分支，以master为起点拉出一个分支，每个分支都要包含次要版本，比如2-3-stable、2-4-stable等。

以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新次要版本号。

参考链接

Git实操网站 - 生动形象
ngulc - 博客园
阮一峰 - Git分支管理策略
阮一峰 - Git工作流程
Github-Flow
Gitlab-Flow