Git工作流指南：Gitflow工作流（gitee + phpstorm）

一、简述

分支：

a）Master衍生Develop分支，Develop又衍生各种Feature分支！

b）Master衍生Hotfix分支

c）不存在Release分支

权限：

项目为私有项目，Master和Develop为只读分支，即只接收PR；各种Fearture，Hotfix为常规分支，可以push。

流程：

a）Feature PR到Develop，代码审核通过，由测试工程师集中测试Develop，没有问题后，Develop PR到Master。这些顺序一定不能变。

b）每个人有自己的Feature分支，有的人开发完成，Feature就可以删除了，有的依然保留（后边我们再讨论）

c）Feature本地开发完成，push到远程Feature分支，开发原始阶段尽量做到一两天发起一次pull Request，长时间容易起冲突。

d）Feature->PR->Develop，有冲突如何解决？先pull一份最新的Develop，merge到自己的Feature项目解决冲突，然后重新push Fearture，再发起PR，选择合并为一个commit，防止多个提交混乱。

e）Develop->PR->Master，合并为多个commit

f）Develop一般为开发功能或者新版本阶段，Hotfix为打补丁阶段，二者可同时进行

g）Hotfix由Master衍生新的分支，比如出现了两个bug，则命名为hotfix；bug解决后，并通过了测试，直接PR到Master，再pull Develop分支解决冲突，完成后PR到Develop；这样操作后，Develop->PR->Master不会产生冲突；

h）如果Develop->PR->Master产生冲突，可先Master衍生一个新分支，然后在pull一份Develop，之后再去PR到Develop，可解决冲突。

i）里程碑式只产品部门发布的一个新产品需求，对应一个新项目；而Issue指的是将这个新项目分几步来解决；解决一个bug可以单独建一个Issue而不需要新建一个里程碑

j）Master正常运行后，发布相关版本号

二、服务器

服务器可以分为正式环境、测试环境、个人测试环境、本地测试环境，环境通过git clone初始化项目，后期通过webhook pull更新项目，本地测试环境可通过VM虚拟机搭建完成。正式、测试、个人测试环境可购买相关云产品。

三、举例

我们以phpStorm IDE开发为例

我们发现，clone了三个分支，默认为master分支工作环境

checkout fearture对应本地分支

当前工作分支为Feature，当然你也可以把本地master删除，因为我们不能对master和develop分支进行push操作

我们修改了一个文件，右键项目根目录，提交，并push

ok，push完成后新建一个Pull Request，等待代码审核员审核

这是代码审核员界面，这里有两点要注意，合并分两种：合并分支，所有提交接在原来develop分支上，Feature分支做任何提交都会提交都不会产生冲突；扁平化分支，生成了新的提交，那么当前Fearure再次提交时，一定会产生冲突。如下图

不可自动合并，那我们先解决冲突

首先我们先pull最新develop分支

因为当前工作分支为Feature，所以直接pull操作后直接可以Merge，双击可查看信息，左边为Feature分支，右边为新pull的develop分支，我们选择左边最新

我们提交(IDE好像又bug，如果不能提交，则修改点东西再次提交)

ok，可以继续PR了！

============================================== 分割线，以下注意点==============================================

这个的意思是，当前工作分支为本地分支为master（对应远程分支master），Merge into Current是把develop Merge into 到当前工作本地分支 master（就是把蓝色条目，merge到当前正在进行的工作分支上）；这样当前工作分支就可以push了。首先我们先pull最新的develop分支

当develop-base_loign->PR->develop的时候，最好不要选择扁平化合并，否则产生冲突会很麻烦。

当develop->PR->master的时候，最好不要选择扁平化合并，否则产生冲突会很麻烦。