Git 工作流程

在项目的源码管理中，如今非常多公司，非常多项目组都会在内网架设一个Git server，利用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分支还是有点不一样的，一般这样的救急的分支改动的东西不会非常多，都是会由某一个开发人员完毕，所以一般不须要在server上专门为其创建一个分支，仅仅须要在本地修补完，然后推送到master分支和develop分支就可以。

Feature分支

在Develop分支以下，还能够存在不同的Feature分支，事实上这就是每位开发人员在项目中每一个迭代中须要完毕的工作了。所以普通情况下，这些分支都是创建在开发人员自己本地的环境上的。

当完毕某个功能点之后，开发人员就能够将相应Feature分支的内容推送到Develop分支上了。

结束。