开头Git的三个特色，分支，暂存区，工作流程，今天终于要写在工作流程上了。 我开始走，仿佛看到了胜利的曙光。
工作流工作流的字义、工作流或工作流是什么？ 在分支篇中，我说过正因为有分支的存在，才构成了多工作流的特色。 确实如此。 在项目开发中，多人合作，存在许多分歧。 虽然每个人在分支上互不干涉，但我们需要把分支聚在一起。 此外，在实际项目中还涉及许多问题，包括版本迭代、发布和错误修复。 为了更好地管理代码，必须创建工作流。 这就是我们说的工作流程，也有人称之为分支管理战略。
工作流程与任何指令无关。 那是规则，因为开发者完全定制，自我遵守。 没有规则是这个理由。
工作流最受欢迎的排名当前最常用的工作流前三名(排名先后无关，分别为以下三类：
Git FlowGitHub FlowGitLab Flow是其中Git Flow出现得最早的，GitHub Flow基于Git Flow进行了一些优化，适合持续版本的发布，但GitHub Flow的出现时间
Git Flow这一工作流程是vincentdriessen在2010年推出的他自己的分支管理模式，至今为止使用非常频繁，我自己一直在管理项目。 也可以说比较熟悉。
Git Flow的分支结构很特别，从功能上来说，可以分为5种分支，从5种分支的生命时间来看，可以分别分为长期分支和暂时分支，或者更恰当地分为主要分支和合作分支。
主要分支：在采用Git Flow工作流的项目中，代码的中央仓库有两个长期分支：
3358 www.Sina.com/http://www.Sina.com /其中origin/master分支的最新代码始终处于版本发布状态。 origin/develop分支是最新的开发进度。
当develop上的代码处于稳定状态并可以发布版本时，develop上的这些更改会以某种特殊方式合并到主分支中，并标记相应的版本标签。
帮助分支：除了主要分支之外，Git Flow开发模式还需要一系列帮助分支来帮助您同时开发更好的功能，并简化功能开发和问题修复。 是的，以下三种分支。 这种分歧是一种短暂的分歧，非常无私的奉献，当它们需要的时候迫切地创造出来，当它们用尽的时候挥臂完全消失。
帮助分支分为以下几类：
http://www.Sina.com/http://www.Sina.com/feature分支用于查看开发人员的喜好，避免与其他类型分支的命名混淆举个不好的例子，命名为master分支的模块完成后，它将合并到develop分支中并删除自己。
用于发行版的已发行分支，用作发行前的发行分支。 建议将其命名为release-xxx。 例如，在开发了软件版本1.0.0的所有功能并提交测试之后，将从develop中检测版本1.0.0。 在release分支中修复并提交测试中遇到的小问题，在测试完成并准备发行时，代码将合并到master和develop中，并合并和关联master分支
热修复分支是用于在线紧急错误修复的分支，建议将其命名为热修复- XXX。 如果联机版本遇到问题，请检出相应版本的代码，创建热传真分支，并在问题修复后将其合并到主和开发中以删除自己。 请在这里注意。 合并到主页时，请同时标记修复后的版本。
在合并分支时，Git Flow作者Vincent Driessen非常建议在合并分支时添加no-ff参数，以向合并中添加no-ff参数。 此参数不选择快速向前合并方法，而是指策略合并。 策略合并提交多个合并。 这样做的好处是，可以确保非常明确的提交历史记录，并看到合并分支的存在。
下面是比较图，左侧是添加参数，后者是普通提交：
Git Flow图像下方的图。 我刚学Git的时候，看过很多次这张图。 并购蛋，我一直没理解。 我还不知道这张图来自Git Flow。 我只能说，我学习Git的方法确实不太认真和系统。 幸运的是，我现在必须了解这张图，写博客，感叹。 时间真不可思议，人会遇到不同的自己。
图中描绘了Git Flow的五个分支： master、develop、feature branchs、release branchs和hoxfixes。 其中，master和develop的字体用粗体表示主要分支。 每当主分支合并一个分支时，无论是热传真还是版本
会打一个版本标签。通过箭头可以清楚的看到分支的开始和结束走向，例如 feature 分支从 develop 开始，最终合并回 develop ，hoxfixes 从 master 检出创建，最后合并回 develop 和 master，master 也打上了标签。
看懂之后，觉着这个图画的还挺好看的，嗯，配色也不错。
GitHub Flow
GitHub Flow 是大型程序员交友社区 GitHub 制定并使用的工作流模型，由 scott chacon 在 2011 年 8月 31 号正式发布。
文章中说，因为 Git Flow 对于大部分开发人员和团队来说，稍微有些复杂，而且没有 GUI 图形页面，只能命令行操作，所以为了更好的解决这些问题，GitHub Flow 应运而生了。
GitHub Flow 示意图
对比上面那张 Git flow 分支模型图，真的可以称得上简单明了啦，因为 GitHub Flow 推荐做法是只有一个主分支 master，团队成员们的分支代码通过 pull Request 来合并到 master 上。
GitHub Flow 模型简单说明 只有一个长期分支 master ,而且 master 分支上的代码，永远是可发布状态,一般 master 会设置 protected 分支保护，只有有权限的人才能推送代码到 master 分支。如果有新功能开发，可以从 master 分支上检出新分支。在本地分支提交代码，并且保证按时向远程仓库推送。kqdxbw需要反馈或者帮助，或者你想合并分支时，可以发起一个 pull request。当 review 或者讨论通过后，代码会合并到目标分支。一旦合并到 master 分支，应该立即发布。 特色之 Pull Request
在我看来，GitHub Flow 最大的特色就是 Pull Request 的提出，这是一个伟大的发明，它的用处并不仅仅是合并分支，还有以下功能：
可以很好控制分支合并权限。
分支不是你想合并就合并，需要对方同意呐
问题讨论 或者 寻求其他小伙伴们的帮助。
和拉个讨论组差不多，可以选择相关的人参与，而且参与的人还可以向你的分支提交代码，可以说，是非常适合代码交流了。
代码 Review 。
如果代码写的很烂，有了 pull request 提供的评论功能支持，准备好接受来自 review 的实时吐槽吧。当然你如果写的很棒，肯定也能被双击666的。
特色之 issue tracking 问题追踪
日常开发中，会用到很多第三方库，然后使用过程中，出现了问题，是不是第一个反应是去这个第三方库的 GitHub 仓库去搜索一下 issue ，看没有人遇到过，项目维护者修复了没有，一般未解决的 issue 是 open 状态，已解决的会被标记为 closed。这就是 issue tracking。
如果你是一个项目维护者，除了标记 issue 的开启和关闭，还可以给它标记上不同的标签，来优化项目。当提交的时候，如果提交信息中有 fix #1 等字段，可以自动关闭对应编号的 issue。
issue tracking 真的是非常适合开源项目。
如果你想体验 GitHub Flow
GitHub 社区使用的就是这个工作流模型，而且帮助文档非常详细，可以建个项目，多耍耍。
GitLab Flow
这个工作流十分地年轻，是 GitLab 的 CEO Sytse Sijbrandij 在 2014 年 9月 29 正式发布出来的。因为出现的比前面两种工作流稍微晚一些，所以它有个非常大的优势，集百家之长，补百家之短。
GitLab 既支持 Git Flow 的分支策略，也有 GitHub Flow 的 Pull Request（ Merge Request ） 和 issue tracking。
Git Flow & GitHub Flow 的瑕疵
当 Git Flow 出现后，它解决了之前项目管理的很让人头疼的分支管理，但是实际使用过程中，也暴露了很多问题：
默认工作分支是 develop，但是大部分版本管理工具默认分支都是 master，开始的时候总是需要切换很麻烦。Hotfix 和 Release 分支在需要版本快速迭代的项目中，几乎用不到，因为刚开发完就直接合并到 master 发版，出现问题 develop 就直接修复发布下个版本了。Hotfix 和 Release 分支，一个从 master 创建，一个从 develop 创建，使用完毕，需要合并回 develop 和 master。而且在实际项目管理中，很多开发者会忘记合并回 develop 或者 master。
GitHub Flow 的出现，非常大程度上简化了 Git Flow ，因为只有一个长期分支 master，并且提供 GUI 操作工具，一定程度上避免了上述的几个问题，然而在一些实际问题面前，仅仅使用 master 分支显然有点力不从心，例如：
版本的延迟发布（例如 iOS 应用审核到通过中间，可能也要在 master 上推送代码）不同环境的部署 （例如：测试环境，预发环境，正式环境）不同版本发布与修复 （是的，只有一个 master 分支真的不够用） GitLab Flow 解决方案
为了解决上面那些毛茸茸的小问题，GitLab Flow 给出了以下的解决方法。
版本的延迟发布–Prodution Branch
master 分支不够，于是添加了一个 prodution 分支，专门用来发布版本。
不同环境的部署–Environment Branches & Upstream First
每个环境，都对应一个分支，例如下图中的 pre-production 和 prodution 分支都对应不同的环境，我觉得这个工作流模型比较适用服务端，测试环境，预发环境，正式环境，一个环境建一个分支。
这里要注意，代码合并的顺序，要按环境依次推送，确保代码被充分测试过,才会从上游分支合并到下游分支。除非是很紧急的情况，才允许跳过上游分支，直接合并到下游分支。这个被定义为一个规则，名字叫 “upstream first”，翻译过来是 “上游优先”。
版本发布分支–Release Branches & Upstream First
只有当对外发布软件的时候，才需要创建 release 分支。作为一个移动端开发来说，对外发布版本的记录是非常重要的，如果线上出现了一个问题，需要拿到问题出现对应版本的代码，才能准确定位问题。
在 Git Flow ,版本记录是通过 master 上的 tag 来记录。发现问题，创建 hotfix 分支，完成之后合并到 master 和 develop。
在 GitLab Flow ，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。发现问题，就从对应版本分支创建修复分支，完成之后，先合并到 master，才能再合并到 release 分支，遵循 “上游优先” 原则。
最后
这个博客，真的写好久，因为我之前对工作流的这个概念，也只限于 Git Flow ，写博客的过程中，自己也学习到很多，我目前的工作项目中，使用的是 GitLab + Git Flow 这种混搭 Style，侧面证明了 Git 的使用真的很灵活自由。但是我很喜欢 GitHub 的 Pull Request 和 GitLab 的 Merge Request，以后会多尝试。
GitHub Flow 和 GitLab Flow 的介绍很多都是来源于各自的英文介绍文档，不对之处，还请评论指证，下篇博客见。See you~
2020.05.28 加：
关于工作流，最近还看到一片很好的文章，按照集中式工作流，功能分支工作流，Gitflow 工作流，Forking 工作流分类讲解，配上了图，清晰易懂，推荐大家看下，链接在此：不熟练 Git 被优化了！腾讯是如何使用 Git 的 ？
参考链接： Git Flow 英文文档GitHub Flow 英文文档GitLab Flow 英文文档悦耳的裙子-Git 工作流程 欢迎订阅我的Git系列文章 01. 请回答：Git是什么？ 02. Git常用命令一日游活动 03. Git三大特色之Branch(分支) 04. Git三大特色之Stage(暂存区) 05. Git三大特色之WorkFlow(工作流) 06. Git-你好, HEAD 同学 07. Git-用 cherry-pick 挑好看的小樱桃 08. Git-rebase 黑魔法之打造完美的线性历史 09. Git-rebase 黑魔法之打磨 commit 颗粒度 10. Git-少年，你想学回滚吗？想撤销文件修改吗？ 11. Git-移动记录仪 & 忧虑的热狗 reflog 12. Git-丢失的 commit 是真的消失了吗？ 13. Git-叹为观止的 log 命令 & 其参数 14. Git-送娃子们一本关于如何自学 Git 的秘籍 欢迎关注个人微信公众号「浅浅同学的开发笔记」，最新的博客，好玩的事情，都会在上面分享，期待与你共同成长。
支付宝扫一扫
微信扫一扫
