我们是一个由6个开发人员组成的团队，我们已经从TSVC（在TFS2010上）转换为git（在Gitlab上）近一年了。我们采用了http://nvie.com/posts/a-successful-git-branching-model的发布模式并且它正在运作，但我们有时会努力适应。
背景： 我们只为1个独家客户维护内部网络应用程序。通常我们有两种类型的版本：
这两种版本只能在客户批准后部署到生产中。
我们有4种类型的分支，master，release，develop和主题分支。一旦发布准备就绪，我们就会从master分发新版本。对于CR，我们最初从develop分支，但后来我们发现它非常冗余，因此我们现在从master分支。主题分支是错误修正和小CR，它来自正在进行的release或master分支。当我们将足够的错误修正合并到release分支中，或者当需要发布紧急错误修正时，我们将准备release分支出去，并开始新的release科。我们通常在固定的工作日每两周或每月发布一次。我们还通过在每次发布时将次要release分支合并到其中来更新主要release分支。
我们使用Gitlab的CI在每次推送时构建我们的软件包，我们将最后构建的软件包部署到我们的测试环境中，由我们的测试团队进行测试。当release分支稳定时，最终包通过测试并由客户端批准发布，然后将相同的包用于生产部署。
以下是我们的一些困惑。
release分支的提示进行部署，因此我们认为无需将其合并回master。将release合并到master的提交不是已部署的提交。如果我们要使用最终的合并提交，那么我们将不得不再次经历测试周期，这似乎是多余的。我们还应该保留master吗？develop分支似乎也不适合我们的工作流程，我们也应该放弃它吗？最后，似乎对我们有用的只是轻微的＆amp;主要release分支，但我们想知道这是推荐的方式还是我们可以遵循的更好的发布模式。
答案 0 :(得分：1)
我们和您一样进行同样的开发。
对我们来说，Dymitruk的分支模型http://dymitruk.com/blog/2012/02/05/branch-per-feature是完美的。简而言之，它取消了development和release分支，仅使用master，featureXXX，qa（发布前测试）和{{1 （持续集成）分支，最后一个分支更具技术性和可选性。
系统在很大程度上取决于ci和git rebase，因此仅适用于git rerere（我不知道其他任何VCS是否有类似git的内容） ，而且非常干净和强大。