gitflow的规范

背景：

总结一下，目前接触到的两种gitflow规范。

老版本gitflow流程：

master   分支是用于线上生产环境和预环境

develop  分支是开发分支，用于qa测试环境，新功能的开发以及bug的修复分支，都是已改分支作为起始点

feature,bug分支从分支命名上，没有按照feature/xxx,bug/xxx命名，而是以jira问题号命名，示例：section-1324_fix_bug_xxx,section-1299_feature_xxx

feature，bug处理完毕后，研发在开发环境自测无误，就会将分支合并到develop分支，代码上到develop后，测试会在qa测试，通过测试后，就可以将代码发布到master

这个git规范，最有特色的处理方式，是针对develop分支上的commit发布到master，不是通过合并直接合并develop到master，

而是通过cherry-pick命令实现的，这种方式可以很灵活的进行发布，发布前由产品经理会根据研发进度来整理当期需要发布的section问题号（由于某些feature临时测出了新bug，可以先不发），提供给研发，研发根据如下命令，来查找需要发布的commitid：

git log --merges --pretty=format:"%h %ad %s" | grep '\(section-435\)'

ps：–merges参数，能过滤掉非merge类型的commit

为啥要过滤掉非merged类型的commit，原因cherry-pick只能发布merged类型的commit；

这样做，确实灵活性高，但是流程复杂了，导致容易出错，主要是容易漏掉commit，导致线上代码和测试环境不一致，这个漏掉主要是因为git log找commit，可能找漏掉了，例如：你的同事骚操作，在develop分支上做了回滚后的提交操作，这个提交操作就不是merge类型的，导致git log找不到。

另外cherry-pick的执行，需要严格按照操按照时间线性的顺序来操作，类似：

git cherry-pick -m 1 911658b # 1
git cherry-pick -m 1 d7ba21f # 2
git cherry-pick -m 1 9ffd6d2 # 3
若1，2，3中的每一步cherry-pick出现冲突，则git status查看冲突文件，本地解决冲突，git add 冲突文件=>git commit -m"解决了什么冲突"
注意cherry-pick的顺序是按照时间的升序进行，若执行完最后一步cherry-pick后，若无冲突，则执行：
git push origin master:master # 将cherry-pick的commit提交到远程master分支

每一步的冲突都需要你手动解决，这是有风险的，对操作人员要求很高，要胆大心细。

新版本gitflow流程：

后面因为线上发布出现了因为cherry-pick导致代码丢失、代码不一致等问题，开始反思，更换gitflow的规范，以下规范主要就是参考我司方向j的规范；

master分支，用于线上生产环境

rb分支，用于开发分支，rb是有版本号的，一般命名如下：rb-xx.yy.zz  其中xx,yy,zz分别对应三个版本号，xx是主版本号，yy一般是功能迭代且不向下兼容，zz是小bug修复  是预发布环境代码

feature分支，用于新功能

fix_bug分支，用于bug修复

线上发布就是把rb合并到master就好了，省去了cherry-pick的复杂操作，至于某些feature不想发布到master，那么你最开始开发完毕后，就不要把它合并到rb，就行了！这一步到底合不合并，需要请示产品经理，确定发布计划，

另外，为了让rb分支的提交记录看上去是线性的，所以该规范有个额外的git rebase变基操作！如下：

1.先以最新的rb-1.0.0为基础，新建本地seciton-1407_exprot_data作为feature分支

2.代码修改完后，在seciton-1407_exprot_data分支add 然后commit

3.在当前分支seciton-1407_exprot_data 执行 git rebase rb-1.0.0（执行前，务必在rb-1.0.0执行git pull，从而保障rebase钱rb-1.0.0为最新版本，如果git rebase有冲突，就git status查看冲突文件，解决冲突，再git add，git rebase --continue，直到rebeae完毕）

4.推送seciton-1407_exprot_data分支到远程仓库

5.在gitlab上，请求合并seciton-1407_exprot_data到rb-1.0.0分支                                                                                     

关键点在于什么？这样操作的目的，其实就是为了让分支好看些！
第三步，有三个细节，分别阐述：

细节一：git rebase xx 这个xx参数取决于，你这个当前分支是从这个xx分支检出的；

细节二：执行git rebase前，需要保证你的本地xx分支，已同步过远端，是最新的xx分支；

细节三：执行rebase xx，底层的逻辑是变基，把当前分支的基础点，后移，后移至当前xx分支的点，然后把当前分支的变动，再逐一应用到当前已变基的xx分支上，从而达到本地合并了远端的代码的同时，保证了分支是一条线！

那么，通过git rebase的操作你的git graph应该是长这样：

参考文章：

http://jartto.wang/2018/12/11/git-rebase/