Gitflow 工作流

#1. sourceTree 初始化工作流

1，有特殊含义的分支只有三种：master、release、feature。master分支为主干，其含义是master分支代码就是线上跑的代码；release分支为发布分支，它会承载功能发布、QA回归等流程；feature分支为功能分支，它承载了具体的功能开发，所有的开发者都将基于feature分支签出自己的个人开发分支。

2，从master签出的分支只能是release和feature分支，master上的改动必然都是来自release分支。换句话说，除了release分支，其他的所有类型的分支都不允许直接合并到master分支。这一点是强硬要求，否则无法保证master分支的代码质量。言下之意，master上的代码都是来自release分支，而release分支都是经过QA回归过，有质量把关的。

3，master、release、feature这三个分支的签出与合并都由一个人来操作，其他人没有操作权限。我们把这个人称之为pudge，屠夫的意思，因为都是通过pudge切割出来一个个核心分支。一般pudge还有一个backup。

4，当有开发任务过来时，pudge按照具体的业务从当前的master分支签出带有业务标识的feature分支，比如 feature-finds-20161212 ，同时分支会带有时间戳来表达此分支大致的生命周期。

5，具体的开发人员按照自己的工种和定位，从 feature-finds-20161212 上签出自己的开发分支，我们称之为RD分支。即图中的RD1，RD2，RD3分支。RD分支一般而已都是相互独立的，分支名不作要求。因为除了开发者自己，其他人理论上是不会关注某一个具体的RD分支的。当然，同一个feature分支上可以签出多个RD分支，环境相互隔离。

6，经过一段时间的开发后，RD分支完成自己的开发任务了，开发者要主动将自己的RD分支合并至feature分支。这个合并过程中，在不同的场景下，可能会有一些额外的操作。比如RD分支游离的时间过长，开发者可以先同步feature分支到自己的RD分支，然后再合并。开发者也可以在合并的时候走Merge Request流程，将Code Reviewer指定为他人或自己。理论上MR在此环节的合并不作强硬要求。

7，RD分支合并进feature分支之后，通过测试人员针对feature分支进行QA。也就说，测试人员只关注feature分支，其他的RD分支不需要care。

8，若测试在feature上QA时发现有问题，通过相关的开发去修复。开发在自己的RD分支进行bugfix，完毕后再次合并到feature。通知测试人员进行回归。

9，若feature分支的测试无问题，确定可以上线。此时通知pudge从master签出带有日期版本号的release分支，然后通过Merge Request将feature分支合并进release分支。这一步有两个关键点，一个是由pudge从master签出release分支，另一个是由pudge来操作feature分支通过MR的方式合并进release分支。此外，当某一个release节点需要同时发布多个feature分支，那我们就针对多个feature分支重复7，8，9。

10，测试人员在release分支上进行回归。若无问题，即对release分支走上线流程（注意：这里是对release而不是master）。上线完毕，由pudge将release分支合并进master。若release的回归出现问题，则重复8，9。

11，若需要紧急处理线上问题或者一些小问题，比如文案修复之类的。由pudge从master签出release分支，通知相关开发人员评估工作量，能否直接在release上修改，还是需要走更多的分支流程，灵活处理。

主要的流程和场景如上所述，应该条理还是比较清晰的。所有的流程中，有一个关键角色，就是pudge。基本上核心分支的签出、合并、MR操作都是由这个人来完成。其他的开发和测试，只需要关注自己需要关心的分支即可，其他的不用关注。在具体的开发工作中，若遇到一些不太好处理的分支操作，也都交由pudge来处理。 // 个人总结笔记 master new hotfix

Hotfix merge to master

Release

Develop new master

feature new develop,merge dev

1.1开发新功能使用dev作为父分支 ,没个新功能位于自己的分支

1.2 新功能分支不可以和master分支交互,假设新建球队creatTeam,点击完成,发现feature 分支已经被删除,合并到dev分支.

#2.发布分支 ,当dev分支完成功能合并后,建立release 1.0 只面向发布的修改->文档准备和bug修复此时 点击发布完成当前版本 确定可以发布!

打tag 比如1.0
用release1.0版本,合并到master上
合并release1.0版本到dev版本
删除release1.0分支
发布最终master 和dev 分支都是目前最新代码!

#3. 后期bug 可以从masterfork的分支,修复完成,应该马上合并奥master和dev ,分支名词 hotfix/bugname/bug no

假设创建球队有个bug,但是在release过程中已经没了当初的分支,此时需要

1.从master 打出hotfix 分支名字 bug_问题fix

2.hotfix 修复 bug

3.点击完成,为此消息打tag