Git版本管理

[一]、Git版本管理的挑战

虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

如何开始一个Feature的开发，而不影响别的Feature？

由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？

哪些分支已经合并回了主干？

如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？

线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?

大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是master, 一个是develop, 还有一个是基于develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。

[二]、git-flow应用背景

当在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情，然而，如果在你的团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。

基本上你可以定义一个完全适合你自己项目的工作流程，或者使用一个别人定义好的。

[三]、git-flow如何开启

git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。

严格来讲，你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。

（3.1）git-flow开启方式一：

执行如下命令即可在当前git仓库开启git-flow工作流模式。

$ git flow init

（3.2）git-flow开启方式二：

基于SourceTree或者IDEA等工具开启git-flow工作流模式。

[四]、git-flow使用及分支模式

（4.1）git-flow各个分支使用规则：

master分支：当release分支上测试通过，表示代码随时能够发布时，会将代码merge到maste分支，并且打上tag，至此，该版本封版，所有发现的bug均视为线上bug。

develop分支：开发者在接到需求之后主要从事开发工作的分支。

release分支：测试在接到测试工作时主要使用的分支，在版本进入测试周期之后，会将该版本的测试代码从develop分支merge到release分支上，表示等待发布状态，此时将不会再添加新功能，只负责当前功能的bug修复。

另外还有两类次要分支:

hotfix分支：该分支适用于存在热修复功能的开发系统，当发现线上bug之后，如果该bug可以使用hotfix进行修复的，就会在hotfix分支上修复，并且进行测试。测试通过后并入maste分支，并且打上tag号。

feature分支：功能分支是develop分支的辅助分支，将新功能在独立分支进行开发，开发完成后再并入develop分支。这样能够减少多人开发中，单个开发者由于新功能添加过程中修改代码对其他开发者造成的影响。

（4.2）git-flow 模式默认预设分支说明：

master分支 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。

master只能用来作为稳定的产品代码的合并。并且在master分支上的merge应该Tag。

develop分支 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是开发的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。

（4.3）git-flow 模式其他功能性分支说明：

release分支 当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了。当你需要一个发布一个新Release的时候，我们基于develop分支创建一个release分支，完成release后，我们合并到Master和Develop分支。

这两个默认分支被称作为长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉，当前也可以保留。

feature分支 这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release。feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留。

hotfix分支 当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回master和develop分支，所以Hotfix的改动会进入下一个Release。分支基于Master分支创建，开发完后需要合并回master和develop分支，同时在master上打一个tag。

（4.4）git-flow 模式分支生命周期管理说明：

注意的地方：

1. master分支永远是稳定的代码，未经测试的代码不得合并入master分支。该分支只负责发布，不负责开发以及bug修复。
2. 在版本开发完成之后，代码会合并入release分支进行测试。release分支的所有提交应该不包含新业务的开发，只包含当前需要发布版本的bug修复。
3. 线上版本出现问题分为两类，一类能用hotfix修复，我们会使用hotfix分支修复后合并入master并且打上tag，并且还需要将hotfix分支的修复内容merge到release或者develop分支上（如果在release上修复，需要记得合并到develop分支中）。还有一部分无法进行hotfix修复，这些bug的修复分支可以在release上，也可以在develop上（如果在release上修复，需要记得合并到develop分支中）。
4. 功能分支属于辅助分支，当新功能开发完毕并且合并入develop分支之后就逐渐失去作用，等到包含该功能的版本进入测试阶段，并入release之后，我们可以删除该分支，否则时间久了将会积累非常多的功能分支，反而不方便管理。

5. 有时候我们需要测试接入对功能模块的单独测试，所以测试可能直接使用功能分支代码进行测试，这时候的bug修复就需要在功能分支上进行修复。