git flow

基于

 

 

（1）每个sprint开始，假设是s8，从master分支延伸出一个release/x.x.0分支，假设叫release/1.1.0，假设，大家开发各个功能的feature分支，只要是这个sprint要上线的，都往这个release/x.x.0 也就是 release/1.1.0 合并

（2）在我要测试部分功能的时候，可以把feature分支，或者合并部分功能的release分支部署到sit环境 ，如果已经开发完本sprint要上线的所有功能 ，需要对release/x.x.0（release/1.1.0 ）打tag，tagName为
x.x.0-build${index} index from 1 on（比如1.1.0-build1）,基于这个x.x.0-build${index}（比如1.1.0-build1） 进行一轮一轮的sit和改bug，change代码后重新部署一版的时候，index+1

（3）在我要进行uat测试的时候，可以把sit测试完毕的x.x.0-build${index}（比如1.1.0-build3）部署到uat环境，再进行一轮一轮的uat测试，change代码后重新部署一版的时候，index+1，直到可以上生产的程度

（4）在我要上prod的时候，就选取uat最后测到可接受程度的x.x.0-build${index}（比如1.1.0-build5）

（5）上线成功后，将release/x.x.0分支合并到master分支

（6）如果在sprint-a（对应release/1.1.0）期间有不跟着未来sprint-b（对应release/1.3.0）上线的需求出现，
如果sprint-a=sprint-b
这种现象应该是不会出现的，因为如果要在比如s8期间强行加入一个需求r1，那么按照敏捷的原则，这个r1应该被排到s9，如果非要在s8上线，也是跟着s8一起上线，不会在s8功能还没有上线的情况下，非得上这么一个r1，因为，不差那么几天，

 

如果sprint-a<sprint-b，比如sprint-a=s8 , sprint-b=s9

也就是sprint-a(s8)进行期间sprint-b(s9) minus 1还没有上线，所以，
sprint-b(s9) minus 1的最终release/1.1.0的分支 没有走到最终状态 ，那就找到sprint-b(s9) minus 2对应的release分支（比如release/1.0.0），拉出一个release/1.2.0分支来包括这些不跟sprint-b(s9)上线的需求，
假设这个release/1.2.0包括ticket-1和ticket-2，为了对应他们，要再从这个
release/1.2.0创建feature/ticket-1/dev1,feature/ticket-2/dev1,feature/ticket-1/dev2,feature/ticket-2/dev2 这些分支，这个release/1.2.0可以和这个sprint要上线的release/1.3.0并行不悖的开发和测试

当前还在sprint-a(s8)，在对这个记录不跟着sprint-b上线功能的release/1.2.0分支进行sit和uat测试时，也会产生tag，但这样的tag是不能上生产的，因为他不包含sprint-a(s8)要发布的功能，这样的tag记作
1.2.0-incomplete${index}，当sprint-a(s8)的功能上线以后，那么sprint-a(s8)的功能的release/1.1.0分支也会被合并到master分支上，然后，将release/1.1.0这个分支合并到release/1.2.0分支里，然后
继续开发和测试，这个时候，如果再要打tag，就要命名为1.2.0-build${index}

 

（7）基于当前的情况，前后台每个应用（be,fe-h5,fe-mgmt）应该创建一个release/1.0.0分支，内容为vendor s7上线的内容+vendor最新的代码修正+vendor oval依赖的源码+多环境配置的修改，然后基于此创建release/1.2.0分支（因为s8是release/1.1.0），
在这个release/1.2.0分支上进行capp 的dev,sit,uat，然后等release/1.1.0分支的内容上线并合并到master分支之后，将release/1.1.0分支合并到release/1.2.0，然后依据(6)条中 sprint-a<sprint-b的规则 继续release/1.2.0的进程

（8）建立release分支的时候，请在备注中写明这个release是在哪个sprint的上线的，或者在哪个sprint期间，但是不跟着那个sprint上线的

（9）brokerage-be 每次要打tag的时候，要把pom.xml里面的version改掉，改成要打的tag的名字，形如1.1.0-build1

（10）Brokerage Releases 记录着Brokerage各个release的详细情况，他不仅记录历史，也记录未来上线的安排。

（11）hotfix:

            一旦发现生产有bug，需要建立hotfix分支，命名是hotfix/生产版本的patchVersionInMasterBranch+1，比如master是1.2.0，要对他建立hotfix分支，就是hotfix/1.2.1，这个分支就和release/x.x.x差不多，不能直接改他，要从他再延伸出一个feature分支，比如叫feature/IN-12345/Benedict.Xu ，在feature分支上修改好了，合并到hotfix分支，hotfix分支也要接受测试，要对他打tag然后测试tag，比如hotfix分支叫hotfix/1.2.1，那么 tag名字就像是hotfix-1.2.1-buidl1，测好signoff之后，将测好的hotfix tag上线，将hotfix分支合并到master上，和其他正在开发的分支上。

 

（12）分支合并时候遇到冲突怎么办，可以依照下面的例子解决，注意gitlab有一个坑，如果在将a分支在线合并到b分支上遇到冲突，并在线手动解决冲突提交之后，这些change也会作用到源头分支a分支上，这是我们不希望的。

r/1.1.0 分支应该合并到r/1.2.0上 --- for capp download url release
先提merge request，看看有没有冲突，没有冲突，提交审核完后合并就行了 ，如果有冲突：

方法1：应对合并的时候有冲突，并且merge request里面有resolve conflicts按钮的 ：从r/1.1.0延伸出一个分支，命名为f/t1/dev1,提一个merge request,from f/t1/dev1 to r/1.2.0,手工解决冲突，提交审核，approve，然后就能执行合并了，这时候，f/t1/dev1和 r/1.2.0都一样了，但r/1.1.0不会被修改

方法2：应对合并的时候有冲突，并且merge request里面没有resolve conflicts按钮的 ：从r/1.2.0延伸出一个分支，命名为feature/t1/dev1（可以用下面提到的SPDCN-933或者934），将feature/t1/dev1拉到本地，将r/1.1.0合并到feature/t1/dev1的时候，出现冲突，手工解决冲突，将feature/t1/dev1 push到远程，再建立
merge request: from feature/t1/dev1 to r r/1.2.0，没有冲突，平滑合并。

建了两个用于处理临时工作的ticket，比如分支合并的时候有冲突，可以用这两个ticket作为中间操作的缓冲，以及没有ticket可用于创建分支的时候，这种临时周转的ticket在每个sprint都会有。
SPDCN-933

SPDCN-934
 

（13）多个release的合并

让大家记住自己做的任务要合并到的release分支（设为r1）是从哪个release(设为r2)创建的，要经常性的从r2合并代码到r1，也就是把r1创建之后对r2的change同步到r1里，所以创建release分支的时候，需要遵循这样的法则，如果在时刻1存在r1，未来有r2和r3需要上线，r2和r3现在都不存在，r2早于r3上线，那么在时刻1创建r2的时候要基于r1，创建r3的时候要基于r2，这样，在做前面所说的同步代码动作的时候，把r1合并到r2，把r2合并到r3就可以了，显得很有次序

 

建议，在将release发布到测试环境，以及临上线的时候，递次查看一下要发布的release有没有遗漏前面的change.