git分支策略问题

Question

是这样的，我们公司目前代码库有三个分支，一个Master，一个UAT，一个SIT，我们提交代码一般是永远在SIT上提交，如果要发UAT测试，就合SIT到UAT，UAT没问题再把UAT合Master。现在有一个问题就是，假如我们有两个功能同时在开发，一个刚启动，一个已经测过一段时间了，都已经发到了UAT，有一天那个测过的要发生产了，这个时候刚启动那个，可能还没办法提交生产，可能还有不少问题，这时候我就感觉我们这个合并方法就有点不合理了，总不能把还没测好的发上去吧，revert一部分也不现实

后来考虑过给所有人基于SIT或UAT给每个人都独立建一个分支，但是应该怎么测试呢，总不能为每一个分支都搭一个UAT环境吧，机器成本先不说，维护这么多也很麻烦了

在网上也看了不少分支管理策略的文章，只是简单说有Master,Feature,Release，dev等分支，所有人都在dev开发，最后合Master，感觉跟我们现在差不多，想问一下这种独立分支应该怎么测试？或者说还有没有更好的方法可以解决开发一个功能不影响另一个，而且同时都能UAT测的。

谢谢大家

Answer 1

1、拿到需求，设定任务分支号，假设v001，从master分支新建分支叫v001。
2、v001开发好后，提交sit分支测试。v001merge到sit上。
3、需uat测试，v001merge到uat上。
4、需上线时，v001merge到master。

Answer 2

我们team也有这个问题，我们是2周一个sprint，每个sprint中每个人开发不同的feature，一个feature开发完后会发到testing环境请QA验证。多个feature可能同时开发完并发到testing。sprint结束后，由于不可控因素，这个sprint中开发并验证通过的feature不一定会发到production。这就带来了和楼主一样的分支策略问题。

现在我们的做法是：

• master分支永远和production保持一致，有online bug可以在master上拉hotfix分支fix。
• 开始做一个新feature的时候，从master分支创建feature分支，开发并单元测试过后合并到develop（注意此时不要删除feature分支），从develop分支编译发testing环境请QA验证。
• QA只有一个testing环境，所有的feature都在这个环境验证。
• 开始发布流程之前，从master分支创建release分支，把这次决定好的需要发production的feature，再合并一次到release分支，并告知所有开发人员testing环境已经被占用，请不要再用develop的代码覆盖。从release分支编译发testing请QA再次验证所有feature。如果发现bug，直接在release分支上更改并重新编译。
• 发布流程结束后，把release分支合并回master和develop，删除所有这次已发布的feature分支。通知开发人员testing环境已经可以用develop覆盖了。

这种做法可以解决楼主的问题，但也不是完美：

• 测试环境不纯粹，因为编译的来源是develop而不是feature分支，所以QA验证的时候有可能会被其他feature的改动所干扰，这时就需要开发人员撕逼来找出真正的原因。
• feature分支上的代码需要合并两次，第一次是合并到develop，第二次是合并到release。如果合并冲突很多，这是一个很烦人的事。
• QA验证也需要两次，需要自动测试来减少工作量和风险。

还有另外一个方案是我之前有思考过的：

• 利用docker或者vagrant，可以很方便的搭建一个环境
• 开发人员告知QA某个feature已经开发完成，QA用上面所说的，指定feature分支，快速搭建一个环境进行测试，验证通过后这个环境可以抛弃
• QA有多个环境可以验证，一个是testing环境，一个是用docker或者vagrant快速创建的环境
• 开始发布流程，再把所有feature代码合并到develop，然后创建release分支，占用testing环境测试。

这个方案还是需要QA验证两次，并且快速搭建环境也不是那么容易的事，特别是有database和API等外部依赖的时候。这就需要结合你们自己的情况综合考虑了。

希望有帮助到你。

Answer 3

后端不是很清楚 说说前端部署吧
前端的话可以放在gitlab page测试上 等上一个需求进了dev或者你说的SIT分支 再合一波gitlab page进dev/SIT