关于 【pre-releases】的一些见解

主分支master

代码库有且只有一个master分支，用于保存正式版本对应的tag，并不用于version的发布。

开发分支dev

remote端必须存在一个dev分支，主要用于项目功能的开发以及多个开发者之间代码的同步。另，不允许直接将dev分支的代码merge到master分支上。

测试分支Pre-Release

remote端在适当的时候应该存在一个Pre-Release分支，其主要功能是打上tag以提交到测试组进行测试、测试结果bug的修复以及测试通过之后的version的发布。dev、Pre-Release、master分支关系如下：

当某一版本的功能开发完毕时，由dev分支checkout出Pre-Release分支，并打上tag提交到测试组进行测试，tag的格式为：TEST-$(VersionName)-$(TestTime)，其中VersionName为版本名，TestTime为该版本的第几次测试，测试的tag由指定的一位负责人进行标示。当一轮测试完成之后，开发者在Pre-release分支进行bug的修复。修复完bug之后负责人打上对应tag并提交到测试组进行新一轮的测试，并将此分支merge到dev分支。当该版本的测试通过之后，在对应的tag上打出release的包进行线上验证，只有线上验证通过之后，才允许将Pre-Release分支的代码merge到master分支。

注意：将Pre-Release分支的代码merge到master的时候，需添加–no-ff参数，以在master分支生成一个commit；当一个版本的发布之后，可以将remote端对应的Pre-Release分支删除。

修复分支fixbug/hotfix

当项目发布之后，如果发现某个version有bug，则在master对应的tag上checkout出fixbug/hotfix分支来进行bug修复，fixbug/fotfix分支本质上跟Pre-Release分支类似，需要修复bug之后打对应的tag提交到测试组，通过测试之后根据情况打出version或patch。fixbug/hotfix与dev和master分支的关系如下：
-----------------------------------
 

fixbug/hotfix分支的最终是否删除也需要视情况而定:

a. 如果在该version后续的version中都存在该bug，但是并不影响项目的主流程，则可以将该分支的提交cherry-pick到dev分支，并将该分支merge到master以发布一个小版本的更新，最后可删掉对应的fixbug分支。

b. 如果在该version后续的version中都存在该bug，且影响到项目的主流程，则应该将该分支的提交cherry-pick到dev，并合并代码到master，同时根据该hotfix分支打出相应的patch进行发布，以及发布对应版本更新，而对应的hotfix分支，则不能删除。

c. 如果只是某个旧版本存在该bug，则且影响到主流程，则应该根据hotfix分支打出对应的patch进行发布，以及对应的hotfix分支不能删除。