需求生命周期阶段和git分支

我们的项目代码使用git来管理，需求要经历技术方案设计、开发、测试、部署上线等生命周期阶段，代码也对应着有不同的状态，有的是线上的，有的是在开发中的，有的是在测试阶段的，对于各种状态的代码，我们都会建立对应的分支来管理，比如 master对应线上和灰度的代码，dev对应开发阶段或者测试阶段的代码，当然也可以单独一个test分支来管理测试代码。

需不需要test分支

dev和test的划分，与开发模式是敏捷式还是瀑布式、以及需求的多少有关系有关系。

如果需求多到有一个需求池，每个版本从中取出一些来做，而且是敏捷式的有固定的上线时间，这样的模式下，如果有某个需求开发过程或者测试过程中遇到问题，可能就不上线了，到下个版本再上，那么测试自然就不测这一个需求的代码了。dev和test不一致，需要两个分支来管理。

如果是瀑布式的，且需求不多，开发全部完成之后才进入测试，那么dev和test是一致的，直接使用dev部署测试环境就好了，没必要单独分出一个和dev一模一样的分支。

开发时需不需要拉一个新分支

同样，开发的时候需不需要拉一个新的分支也是同样的考虑。

瀑布式情况下

如果是瀑布式的，开发、测试、上线都是同步的顺序进行的，那么dev部署到测试环境测完之后，直接dev合并到master。这种情况下基于master还是基于dev 拉分支都是可以的，因为两者一致，也就是开发、测试、上线的代码是完全一致的，那么只需要一个master一个dev分支就够了。

其实也没必要拉一个新的分支，因为拉了分支还要合并回去，测试也只对dev分支测试，要上线时也是dev合到master，拉一个分支没任何意义。

测试

灰度

这种情况下，单独拉一个开发分支没有任何的意义，还会导致不方便经常合并远程dev分支。

敏捷式情况下

但如果是敏捷式的，在测试的过程中同时也进行着开发，那么dev分支上的代码并不全部进行测试，在测试的代码也不一定全部上线，也就是是异步的关系，那么就需要一个test分支来管理测试代码，并且每个需求都需要单独一个分支来管理，开发完合并到dev，测试的时候合并到test，然后上线的这个分支合并到master。

此外，dev分支的代码也不会全部不测试的情况下，dev其实没啥意义，可以直接去掉，测试的时候把新功能分支的代码合并到test就可以了。dev只是开发分支的集合，如果dev本身是异步的，不能合并到test，那么就没必要保留了。

我遇到的情况

我们公司现在就是瀑布式的，也就是需求评审，开发、测试、发灰度和线上的过程是完全同步的，不会有某个需求没上线的情况，所以只有master和dev两个分支。

最近我开发的时候基于dev拉了一个新的分支，然后又合并回去，还因为没经常合并dev导致有较多冲突。整个过程中，开发分支没一点意义，后来我就直接在dev分支改了。

总结

软件项目是不断迭代的，迭代方式可能是瀑布式的同步，也可能是敏捷式的异步，这与分支的划分以及开发新功能需不需要拉新分支有关。
瀑布式情况下，因为开发和测试以及上线的代码是完全一致的，所以保留master和dev分支就好了，并且开发新功能直接基于dev，也没必要拉新分支。

敏捷式的情况下，因为开发和测试以及上线的代码可能都不一样，所以需要master以及test分支来存放各种状态的代码，并且开发新功能需要基于master新拉分支，上线也是功能分支合并master。

简单来说就是瀑布式需要master、dev分支，开发新功能直接在dev分支，不需要拉新分支，最后dev合并到master上线。敏捷式需要master、test分支，开发新功能基于master拉新的分支，最后新功能分支合并test测试，合并到master上线。如果其中有几个需要是关联的，可以拉个小的dev分支，类似Promise.all的作用。

敏捷式还是瀑布式影响着git管理的项目代码和各个环境的关系，也影响着开发过程中分支合并流程，要区分清楚，才不会做无意义的操作。