GIT分支管理策略

课程内容

• 介绍git基本操作以及整合idea的git插件使用
• 解读git分支的作用
• 解读git flow分支管理策略

课程目标

• 掌握git的使用
• 了解gitflow相关分支的命名和作用(作业)

git基本操作

git操作的前提条件:

• 本地windows安装git
• 学习idea中的插件使用

idea的git基本操作:

• 远程仓库remote
• 更新fetch:git fetch
• 拉取pull: git pull
• 上传push: git push
• 合并merge: git merge 合并分支
• 本地提交commit:git commit
• 分支branch: git branch 查看分支或者 切换分支

上述命令属于非常常见的git操作命令,基本使用git必用到的,但是相对来讲,使用idea插件会弱化他们原生命令的使用.

好处是简单,坏处是对底层命令不熟悉,会导致在插件中的各种选项问题困扰.本文基于idea的git插件,不需要过多了解,如有兴趣和需要请自行查询相关官方文档即可.

git分支

为了方便资源版本更新中对多人协作的并行开发进行有效的管理,git存在分支的概念.

我们可以利用分支记录一个稳定或者测试通过的版本,在新分支开发新功能,而在出现问题后及时切换回去.

同时一个功能过于复杂的时候,也可以建立并行的多个分支,多人同时开发最终合并等.

在git分支管理中存在远程分支和本地分支两种类型.

远程分支

托管中心平台或者服务器中可以查看的分支.一般是本地提交上传的同步.

本地分支

开发者操作的本地git仓库内容,一般会与远程分支在数量和名称上保持同步.

gitflow分支管理策略

企业中,分支决不能想创建就创建,想删除就删除,必须要遵循一定的规范和约定,那么分支管理策略就诞生了.

gitflow 最完善,最严格,最复杂的分支管理策略.

分支定义(作业)

Git Flow 是最早出现也是最经典的一种分支管理策略，它由两个长期分支和三种类型的临时分支组成。

1、永久分支：

Master 分支 (product stable)

主分支。用于存放经过测试，完全稳定的代码。永远都是可发布分支。

Develop 分支

开发分支一开始从master分离而来，用于存放基本稳定的代码。当该分支代码稳定，可发布版本时，合并到master分支上。

2、临时分支

Feature 分支

功能模块分支，从dev分支分离而来，用于开发项目功能，当开发新功能时以

feature -xxx命名，开发完成后，合并到develop上，合并后删除自己。

Release 分支

版本预发布分支，当v2.0版本发布时，可以从develop分支签出release-2.0，进行测试，测试出现问题，在release-2.0.1进行修改，测试完毕后准备发布将代码合并至master分支和develop分支上，给master打上v2.0.1的标签，合并后删除自己，这样做可以不影响下个版本功能的开发。

Hotfix 分支

线上紧急bug修复的分支，命名为hotfix-xxx,修改完成后，合并到master分支和develop分支，合并到master后打上修复版本的tag,合并后删除自己。

gitflow分支管理策略评价

Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。

更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。

所以一般网站项目不采用gitflow分支管理策略,而严格版本发布的项目比如游戏,可能采纳gitflow更多.

GITHUB FLOW分支管理策略

想必于gitflow的繁重和复杂,github flow可谓是轻盈小巧.其核心目的就是应对长期持续发布的项目.

分支使用流程

和gitflow不太一样,github减轻了流程的重量,只有一个长期分支master,并且没有复杂的短期分支release hotfix.

创建分支（Create a branch）

在你开发任何新功能完成之前,都在当前版本创建一个新分支,这时不需要管其他开发者在做什么.但是你的新分支最好具有具体的功能描述命名,让其他开发者一看就知道他在干什么.

新增提交(add and commit)

只要你创建了分支，就说明你要对它进行修改啦！无论添加、修改、还是删除文件，你都必须进行提交，将它们同步到你的分支上。当你在分支上工作的时候，这些提交操作可以跟踪你的工作进度。

提交操作也建立一个关于你工作的透明历史，通过查看这些提交记录，其他人可以知道你做了什么和为什么这么做。每个提交操作都有一个相关的提交信息（Commit messages），用于描述你做出的修改。此外， 每一个提交操作都被视为一个“修改单元”。如果发现了 bug 或者决定走不同的开发方向，你也可以通过这些“修改单元”进行回滚操作。

提示（ProTip）

提交信息非常的重要，特别是当你将修改的内容提交到服务器之后，Git 可以追踪到你的修改内容并展示它们。通过写清楚的提交信息，你可以让其他人更容易跟上我们的思路并提供反馈。

提出 Pull 请求（Open a pull request）

当你的开发实现了阶段性内容的时候,可以提交pull request.等待审核人员审核.

讨论和评估你的代码（Discuss and review your code）

当你提出 Pull 请求的时候，审查你的更改内容的人或团队可能有一些问题或者意见。也许你的编码风格与项目规范不符，或者缺少单元测试，也有可能所有的东西看起来都很棒，条理清晰。Pull 请求的目的就是鼓励和捕捉这种类型的对话。

你也可以在大家讨论和给出关于你提交内容的反馈时，继续 Push 你的分支。如果有人评论说你什么没有做，或者代码中有 bug，你也可以及时把它修复，然后 Push 这些修改。GitHub 将会给你展示出最新评论和反馈，你也可以在 Pull 请求的视图中统一接收这些消息。

部署（Deploy）

只要你的 Pull 请求被审查并且通过了你的测试，你就可以部署这些修改，在生产环境中验证她们。如果分支发生了问题，你也可以回滚到之前的状态。

合并（Merge）

现在， 你修改的内容已经在生产环境中验证了，是时候将你的代码合并到master分支啦！合并之后，Pull 请求就保存了一份关于你修改代码的历史记录。因为它们是可搜索的，所有任何人都可以通过搜索了解你为什么这么修改以及如何修改的。

github flow分支关了策略评价

Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。

问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。

可是，有些时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。比如，苹果商店的APP提交审核以后，等一段时间才能上架。这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。另一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会导致线上版本落后于master分支。

上面这种情况，只有master一个主分支就不够用了。通常，你不得不在master分支以外，另外新建一production分支跟踪线上版本。

GITLAB FLOW分支管理策略

分支定义

工作流提供了一种简单、透明和有效的 git 工作方式，并与问题跟踪系统相结合。

可以说是gitflow和github的综合体现.

GitLab 推荐用生产分支来解决上述问题：

Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支(开发环境)develop，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

分支使用方案

• 持续发布

对于"持续发布"的项目，它建议在develop分支以外，再建立不同的环境分支。比如，"开发环境"的分支是develop，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到develop，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

• 版本发布

对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

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