remote 分支管理
主分支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分支不能删除。
local 分支管理
主分支master
同remote端master分支。开发分支dev
同remote端dev分支。测试分支Pre-Release
同remote端Pre-Release分支。修复分支fixbug/hotfix
同remote端fixbug/hotfix分支。功能实现分支feature
该分支主要用于开发某类功能时使用，由dev分支checkout出来，在完成了该类功能的开发之后，将该分支merge到dev分支，并将该分支删除。
注意：原则上不允许将feature分支push到remote，除非某个feature是由多人共同开发；另外，将feature分支merge到dev的时候请尽量添加–no-ff参数，以在dev分支生成一个commit。
git相关参数使用
- merge的 –no-ff参数
默认情况下，git之行“快进式合并”(fast-forward merge)，如果子分支从父分支之checkout出来之后当前分支(父or子)没有做任何修改，此时合并父子分支的时候，git会将当前分支直接指向另一分支的最新提交处。此方式并不能很好的保证版本演进的清晰，因此建议在merge的时候添加上–no-ff参数，此方式能在merge之后，在当前分支生成一个新节点。如图示：
- rebase的 -i参数
当feature分支或fixbug分支完成之后，合并到dev分支时可能不希望生成那么多个commit，那么则可使用git rebase命令并添加 -i 参数，详细说明和使用可参考附录中《Git使用规范流程》。
附录
(Done)