Git 工作流程

在项目的源代码管理中，现在很多公司，很多项目组都会在内网架设一个Git 服务器，利用Git 来管理不同项目组的不同项目。

在自己的日常学习中， 我们利用Git来管理自己的项目的时候，在自己本地想怎么弄就怎么弄，弄坏了也不会影响别人。

但是处于一个项目组中，要跟其他同事一起来开发，那就不是这么简单了，一个弄不好，可能就把别人的努力给白费了。

所以，利用Git的分支特性，就有人归纳总结出了所谓的Git工作流。

一句题外话：总结是学习中一个很重要的阶段，能帮助一个人更好的回顾所学的知识，更好地掌握知识。

具体到每一个项目组中，每一天都会有新的代码产生，有新的功能要测试，有新的Bug要回归，有新的模块要上线，这么多的繁乱代码，要是都往一个分支上放，到时候有哪些代码是要上线的，有哪些不能上的，怎么打出这个版本的代码，会死人的。

master分支

在创建Git项目的时候，一般的默认分支都是master。

在master分支上，我们一般会放置比较稳定的代码。何谓稳定？就是已经发布到生产上的版本，正式给客户用的产品。

如果这一次上线失败，需要回滚，可以直接定位到上一个版本，实现回滚。同时，不用担心，在这个期间的改动会影响到这个分支的代码。

所以在master分支，一般只有在成功发布到生产环境上之后，才会将对应的代码给推送到对应的分支。

不过由于Git提交的是加密的一长串字符串，不好记，所以一般会利用打标签的方式，为每一次推送打对应的版本号，如上面的1.0等。

Develop 分支

而在发布版本之后到下一次发布版本之前，应该也必须定好下一次要发版的需求（这个计划很重要，会影响版本控制的质量）。项目中有多个开发人员，每一个人在本地开发完自己的功能点或者模块之后，必须确定是下一次要发版的代码，才将其推送到Develop分支。这样，才能由对应的测试组或者测试人员获取此分支下的内容来进行测试。

总结一下，Develop分支必须存放的是下一次要发版的需求功能点，当经过测试之后，直接拿此分支的内容发布到生产环境。发布成功，将此分支的内容推送到master分支上。

一般，Develop分支的内容经过测试，可能会需要几次修改才能测试通过，然后才上生产环境。

相比起master分支，Develop分支可能每天都会有更新，时时刻刻对应着项目组中最新的开发进度。

Release分支

有很多时候，当在Develop分支上实现了基本的功能之后，但是还没有通过测试的时候，项目组可能就会开始进入下一轮的需求开发了。这个时候可以基于Develop分支临时创建一个Release分支，一般叫做预发布分支。

这样在测试阶段产生的问题或者临时添加的功能点之类的就可以推送到这个分支上进行，然后基于此分支来测试和发布生产环境。

这样的好处就在于，Develop分支可以提前进入下一轮的需求开发，而不需要等这一轮的测试通过和发布。

不过有一点的要注意的就是，在Release分支上所做的修改，当发布到生产环境上之后，必须将对应的内容分别推送到master分支和Develop分支，尤其后一点要注意，因为Develop分支并没有Release后续的修改内容。

所以，在图上，我们会在master分支和Develop分支中间插入一个Release分支。

对于Release分支创建有个时机要掌握好的就是，只有当Develop分支基本上实现了这一次版本要发布的需求之后，Release分支存在的目的则只是对Develop分支的一些细节或者小小的完善。

而当其所做的修改推送到master分支和develop分支之后，就可以把它删了，直到下一次临发布前，再创建出来。

HotFix分支

测试总是没有我们想像中可靠的，很多时候上了生产环境之后，才会爆出一些之前根本没有想到的问题，从而需要马上进行修改，马上上线，这就是HotFix存在的意义。

因为Develop分支已经在进行下一轮的需求开发了，里面的代码跟稳定的master分支可能差别很大了，在本分支也已经提交多次了。

这个时候，可以基于发版的master分支，创建一个HotFix分支，在此分支上进行修改，修改完成，经过测试之后，上线，然后再将其修改推送到master和Develop分支。它跟Release分支有点类似，只是基于的分支不一样，但本质 上都应该是进行小修小补的分支，不适宜大动干戈。

同样的，跟Release分支类似，当急求完成之后，Hotfix分支也就完成了其存在的使命，可以将其删去了。

不过其跟Release分支还是有点不一样的，一般这种救急的分支修改的东西不会很多，都是会由某一个开发者完成，所以一般不需要在服务器上专门为其创建一个分支，只需要在本地修补完，然后推送到master分支和develop分支即可。

Feature分支

在Develop分支下面，还可以存在不同的Feature分支，其实这就是每位开发者在项目中每个迭代中需要完成的工作了。所以一般情况下，这些分支都是创建在开发者自己本地的环境上的。

当完成某个功能点之后，开发者就可以将对应Feature分支的内容推送到Develop分支上了。

结束。