关于 git 发布管理和混淆的建议
Advice on git release management & confusion
我们是一个由 6 名开发人员组成的团队，我们已经从 TSVC（在 TFS2010 上）过渡到 git（在 Gitlab 上）将近一年了。我们采用了 http://nvie.com/posts/a-successful-git-branching-model 的发布模型并且它正在运行，但我们有时会努力适应。
背景：
我们只为 1 个独家客户维护一个内部网络应用程序。通常我们有 2 种版本：
- 次要：错误修复和小的更改请求
- major：通常需要几个月才能交付的主要变更请求
这两种类型的版本只有在客户批准后才能部署到生产环境中。
我们有 4 种类型的分支，master、release、develop 和主题分支。一旦一个版本准备好发布，我们就会从 master 分支出一个新版本。对于 CR，我们最初从 develop 分支，但后来我们发现它非常多余，因此我们现在从 master 分支。主题分支是错误修复和小型 CR，它是正在进行的 release 或 master 分支的分支。当我们将足够多的 bugfixes 合并到一个 release 分支中时，或者当一个紧急的 bugfix 需要发布时，我们将准备那个 release 分支出去，并开始一个新的 release 分支。我们通常在固定的工作日每两周或每月发布一次。我们还通过在每次发布时将次要 release 分支合并到其中来更新主要 release 分支。
我们使用 Gitlab 的 CI 在每次推送时构建我们的包，我们会将最后构建的包部署到我们的测试环境，由我们的测试团队进行测试。当 release 分支稳定后，最终包通过测试并获得客户批准发布，然后将相同的包用于生产部署。
下面是我们的一些困惑。
- 由于我们总是从
release 分支的顶端部署，我们认为没有必要将其合并回 master。将 release 合并到 master 的提交不是已部署的提交。如果我们要使用最终的合并提交，那么我们将不得不再次经历测试周期，这似乎是多余的。我们还应该保留 master 吗？
develop 分支似乎也不适合我们的工作流程，我们是否也应该放弃它？
最后，似乎对我们有用的是只有次要和主要 release 分支，但我们想知道这是否是推荐的方式或我们可以遵循的更好的发布模型。
我们与您进行相同类型的开发。
对我们来说，Dymitruk 的分支模型http://dymitruk.com/blog/2012/02/05/branch-per-feature 是完美的。简而言之，它取消了 development 和 release 分支，仅使用 master、featureXXX、qa（预发布测试）和 ci（持续集成）分支，最后一个分支更具技术性且相当可选。
系统严重依赖git rebase和git rerere，因此只能与git一起使用（我不知道其他VCS是否有类似rerere的东西） ，而且非常干净有力。
我们是一个由 6 名开发人员组成的团队，我们已经从 TSVC（在 TFS2010 上）过渡到 git（在 Gitlab 上）将近一年了。我们采用了 http://nvie.com/posts/a-successful-git-branching-model 的发布模型并且它正在运行，但我们有时会努力适应。
背景： 我们只为 1 个独家客户维护一个内部网络应用程序。通常我们有 2 种版本：
- 次要：错误修复和小的更改请求
- major：通常需要几个月才能交付的主要变更请求
这两种类型的版本只有在客户批准后才能部署到生产环境中。
我们有 4 种类型的分支，master、release、develop 和主题分支。一旦一个版本准备好发布，我们就会从 master 分支出一个新版本。对于 CR，我们最初从 develop 分支，但后来我们发现它非常多余，因此我们现在从 master 分支。主题分支是错误修复和小型 CR，它是正在进行的 release 或 master 分支的分支。当我们将足够多的 bugfixes 合并到一个 release 分支中时，或者当一个紧急的 bugfix 需要发布时，我们将准备那个 release 分支出去，并开始一个新的 release 分支。我们通常在固定的工作日每两周或每月发布一次。我们还通过在每次发布时将次要 release 分支合并到其中来更新主要 release 分支。
我们使用 Gitlab 的 CI 在每次推送时构建我们的包，我们会将最后构建的包部署到我们的测试环境，由我们的测试团队进行测试。当 release 分支稳定后，最终包通过测试并获得客户批准发布，然后将相同的包用于生产部署。
下面是我们的一些困惑。
- 由于我们总是从
release分支的顶端部署，我们认为没有必要将其合并回master。将release合并到master的提交不是已部署的提交。如果我们要使用最终的合并提交，那么我们将不得不再次经历测试周期，这似乎是多余的。我们还应该保留master吗？ develop分支似乎也不适合我们的工作流程，我们是否也应该放弃它？
最后，似乎对我们有用的是只有次要和主要 release 分支，但我们想知道这是否是推荐的方式或我们可以遵循的更好的发布模型。
我们与您进行相同类型的开发。
对我们来说，Dymitruk 的分支模型http://dymitruk.com/blog/2012/02/05/branch-per-feature 是完美的。简而言之，它取消了 development 和 release 分支，仅使用 master、featureXXX、qa（预发布测试）和 ci（持续集成）分支，最后一个分支更具技术性且相当可选。
系统严重依赖git rebase和git rerere，因此只能与git一起使用（我不知道其他VCS是否有类似rerere的东西） ，而且非常干净有力。