持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第2天，点击查看活动详情
相信许多同学，在刚刚步入职场时对分支管理策略会很模糊，尤其是一些公司没有什么开发规范，大家都只在master分支上修改，测试，发布，这就使大家对Git分支的理解更容易出现偏差。相当而言，一些大公司，一些知名的开源项目分支管理都是做的比较好的，当我们想要为一个开源项目贡献代码时，也需要一个规范的流程，才能被开源项目的维护者所接受。
1. Git 为什么会需要分支管理
首先，Git是目前最为主流的版本控制软件，类似的还有SVN，而GitHub、Gitee、GitLab等都是代码仓库，用于存放代码的地方。
那么Git的分支是为了解决什么问题呢？
分支主要作用是分割开发，当你在新签出的分支进行修改，优化，增加功能时，你提交的代码并不会影响到主干的代码，这样就可以保证我们的主分支一直保持可发布的状态。还有一个作用就是让我们的一个项目具有多套不同的代码。
与分支管理配合使用的还有tag，这个功能常被应用于发布关键版本的标记，也就是我们常常在开源软件中看到的v1.0.0、v2.0.2等。
2. Git 的分支管理策略
对于Git需要维护哪些分支这个话题，就需要看我们要选择哪种Git分支策略，也被称为Git的工作流程模型，主流的Git分支策略有Git Flow、GitHub Flow、GitLab Flow。
-
Git Flow
Git Flow是最早出现也是 最经典的一种分支管理策略，它由两个长期分支和三种类型的零时分支（合并后需删除）组成。
- Master 永远都是可发布版本。
- Develop 最新开发版本，当该分支代码稳定，可发布版本时，合并到master分支上。
- Feature 功能模块分支，当开发新功能时以feature-xxx，开发完成后，合并到develop上，合并后删除自己。
- Release 版本预发布分支，当v1.0.1版本发布时，可以从develop分支签出release-1.0.1，进行测试，测试出现问题，在release-1.0.1进行修改，测试完毕后准备发布将代码合并至master和develop分支上，给master打上v1.0.1的标签，合并后删除自己，这样做可以不影响下个版本功能的开发。
- Hotfix 线上紧急bug修复的分支，命名为hotfix-xxx，修改完成后，合并到master和develop分支，合并到master后打上修复版本的tag，合并后删除自己。
-
GitHub Flow
GitHub Flow是由GitHub 制定的一种分支策略，它也是开源社区惯用的一种分支策略模型，GitHub Flow推荐做法是只有一个master分支，团队成员通过pull Request来合并代码。但一般的团队也会建立对应的开发分支，并维护一些其他分支，我们参与开源项目时，需要按照具体项目的要求进行。
- Master 永远都是可发布版本。
- 参与项目需要将项目fork 到自己的仓库。
- 按项目要求切换对应开发分支。
- 发起 pull request 。
- 项目团队 Code Review。
- 通过则会被合并代码，完成开源贡献。
-
GitLab Flow
GitLab Flow出现的较晚一些，正因如此它吸收了其他分支管理策略的优势。
GitLab Flow 最大的原则叫做上游优先，master是所有分支的上游，它建议每个环境都去建立对应的分支，比如预发环境分支 pre-production，生产环境分支 production。代码变化，必须由上游向下游发展，如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，预发布没有问题，才允许进入生产环境。除非是很紧急的情况，才允许跳过上游分支，直接合并到下游分支。
GitLab Flow还建议每个稳定版本都应该拉出一个分支，发现问题后从对应版本分支创建修复分支，修复后再合并到master分支，然后才允许合并到预发布和生产分支。
3 工作中我们应该怎么设置分支比较合理
我个人认为大部分公司使用的Git分支管理策略是基于Git Flow的，当然也会结合 GitHub Flow这种pull request的方式去做Code Review，如下图所示，我们的程序刚创建时只有默认的master分支，也就是节点A，这时我们需要进行功能版本的开发，于是从A节点签出一个Develop分支，这时就有了节点B，于是产品需要开发新功能时，从B，C的时间节点签出了D，E进行功能开发，功能开发完成后相继有了节点F，G，然后将完成的新功能合并到Develop分支上，有了节点H，然后需要发布，签出到Release分支，有了节点I，然后进行测试，测试中发现Bug，由程序员修复，进而有了J，K节点，然后测试完成，将预发布合到Develop和Master分支上，得到了节点L，M，M节点需要打上相应的tag，标记是一个发布版本，然后项目上线，上线后出现紧急Bug，需要签出到HotFix分支，进行修复，修复后将代码签入Develop和Master分支。
其中Feature、Release、HotFix完成合并到Develop和Master后需删除对应的分支。
如果感觉有所帮助，点赞，收藏走一走
