共计 2211 个字符，预计需要花费 6 分钟才能阅读完成。
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 分支上。
……待补充
