git版本管理
1：常规的git版本控制
针对目前我公司的版本迭代，就发现满足不了公司的需求。
案例：7月10号突然接到需求要开发一个秒杀活动，预计在8月10号上线。拉取最新代码，开始开发，
然后7月30号开发完毕，合并到develop分支；8月1号有个需求来了，评估8月3号上线，我拉develop分支，那就意味着我
开发分支融合了秒杀代码，一旦上线就会把秒杀代码也跟着上线了（这时就会出现大问题）。
2：作为项目管理—就要根据需求（需求变更快，上线时间无顺序）来进行整合分支管理
1：测试develop，堡垒pre，正式master同步到最新代码
2：7月10号，开启活动1项目研发，基于master创建feature1分支代码，开启本地开发
3: 7月30号，活动1开发完毕，融合到develop分支上，进行测试
4: 8月1号，开启活动2项目研发，如果我基于develop分支创建分支feature2（就会融合到活动1代码，要是活动1需求不明确撤回或者晚于自己上线—我到时上线就会出问题），如果是基于pre分支创建分支feature2（跟测试一样，也有可能出问题），因此这里是基于master分支创建feature2
5:8月2号，活动2开发完毕，合并到develop分支进行测试（这是develop就包含两个活动，活动1和活动2）
6:8月3号，活动2测试验收通过，开始要进入验收阶段，而测试1还在测试中，所以develop不能向pre合并，所以是feature2向pre合并
7:8月4号，pre验收通过，因此pre直接向master分支合并，同时master合并到其他分支上
8:8月6号，活动1测试通过，准备向pre融合，要是pre有其他分支在验收，就评估，能否跟其他分支一起上线，如果能一起上线，就融合进pre分支，pre验收多个分支，如果不能，就等待，等待pre验收通过，合并到master之后，在合并。—这里又会出现一个问题就是，假如堡垒pre分支功能比较大验收需要半个月时间，而活动1不能登它一起上线，要提前上线，这时，可以建一个抢占分支pre_*,活动1进入堡垒抢占分支，这时，堡垒走的是活动1项目，而不是之前pre验收项目。等pre_*活动1验收通过之后，直接合并master分支（也可以pre撤回上一个功能验收，然后把活动1融合进pre分支—这块看各自项目理解）