1. 分支管理策略
前端采用Git Flow的分支策略，即为功能分支策略。以下为理想的分支管理策略，实际分支管理情况，由各个组长确定。相应分支功能说明如下：
1.1 master分支
主分支，该分支上的代码，已经经过测试，并且无bug，可以直接发版的分支。
分支合并情况：
合并分支：test分支测试完成后，合并到master分支上。
打tag（后端处理）：要发版的时候，后端会从master分支上拉取代码，拉取前，他们会在master分支上打一个tag。表明现在线上拉取的是这个节点代码。
1.2 test(release)分支
测试分支（对应gitflow的预发布分支），根据测试环境和测试功能的不同可能会有test、test2、test3……等多个分支。测试分支是发布到测试环境或者灰度环境的分支。测试同事会测试上面的代码，确保代码没有问题。测试通过后，在发版前，需要把测试分支的代码合并到master分支上。
测试分支上有bug，有两种处理方案。1是直接在test分支上改，2是从test分支上拉取新的分支hotfix_testX(x为分支序号)_xxx（xxx为bug名），在此分支上改。在新分支上，修改bug后再合并会test分支上。
分支合并情况：
拉取分支：从最新的tag上重新拉取testX分支。这样就可以保证testX分支上代码跟线上的代码一致。
合并分支：拉取新的test分支后，把feature分支合并到testX分支上，发版，发版后通知测试同事测试。
上线：testX分支测试通过后，再合并到master分支。保证新功能上线。
删除分支：test分支合并完了，删除test分支（本地，远程都删除）。
目前小药药test分支，命名没有语义化，命名是test、test2、test3。每一个分支，对应什么测试环境、什么测试功能并不明确。用到时可以问下开发。
1.3 feature分支
模块功能分支，有时候我们同一个系统，经常有多个功能同时开发的情况。因此我们需要根据不同的功能，拉取不同的分支。feature分支由组长从最新的tag上拉取，保证feature分支跟线上的一致。
feature分支命名feature-xxx(xxx为新的功能）。
feature分支拉取完成后，可以直接在该分支上开发，也可以每个人从feature分支上拉取一个自己的分支，比如feature-xxx-gxq，开发完成后再合并到feature分支上。
功能可以提测的时候，再把feature分支合并到testX分支上，给开发测试。
分支合并情况：
拉取分支：新功能拉取新的分支，feature分支从最新的tag上拉取，各个开发可以在feature分支上直接开发，也可以拉取自己的分支，开发完成之后再合并上去。
合并分支：功能开发完成后再把feature分支合并testX分支上。
删除分支：合并分支后，删除feature分支（本地，远程一起删）。
1.4 hotfix分支
hotfix为正式线的补丁分支，当线上代码有bug的时候，需要从最新的tag上拉取一个分支来修复bug。这个分支命名通常为hotfix-xxx(xxx为bug名)。
开发在hotfix上修改bug后。拉取一个新的test分支。如果要拉取的分支名已经存在，问下开发这个分支有没有人使用，没有的话，就删除该分支。从最新tag上拉取一个test分支，把你的hotfix分支合并到test分支，测试通过后。再把test分支合并到master分支上，同时还要把你没有问题的hotfix分支，合并到其他所有的test分支上和feature分支上。
分支合并情况：
拉取分支：从最新的tag上拉取分支
合并分支：先是合并到test分支，拿去测试。测试通过后，再合并到所有的test和feature分支上。避免这些分支再合并到master上时，把以前修改过的代码，又修改回来了。
1.5 tag说明
在重要的节点，要给分支打个tag，这样万一出现问题时，方便及时回滚。
1.6 其他分支
除了以上所说的那些分支外，还有些其他分支，比如bench（压测）分支。这些分支一般都是从最新的tag上拉取的。当你需要更新这些分支的时候，建议直接把这个分支删了，重新从最新的tag上拉取。如果担心有意外发生，可以咨询下开发。
另外gitflow中还推荐一个分支develop分支，我们根据我们实际开发需要，不再单独建develop分支。把master分支当develop分支使用，这样可以减少些流程上的麻烦。
2.分支的命名
我们拉分支的时候，不仅要知道分支是什么功能，还需要知道分支从哪里来，那一天建立，由于分支不能加备注说明，因为我们只能在分支命名上加以体现。
分支命名规则如下：
功能-模块-来源-日期
比如saas项目，修改线上灰度会员bug的分支，就可以命名如下：
hotfix(功能)-member(模块)-master(来源)-1111(日期)
3.几个需要谨记的点
1.一旦分支已经上线或者上灰度，就不能在原来的分支上改bug。改bug必须重新拉分支。避免，master上合并的修改别冲掉。
2.回滚不能使用revert命令，而是要尽量使用reset。避免回滚之后，再合并时合并不上。
3.mergeRequest的时候，出现冲突，一定不能在gitlab上解决。gitlab上解决冲突会导致双向merge，把合并分支上的功能合并到feature分支上。
……待补充