【发布时间】：2016-11-25 23:28:50
【问题描述】：
我们是一个由 6 名开发人员组成的团队，我们已经从 TSVC（在 TFS2010 上）过渡到 git（在 Gitlab 上）将近一年了。我们采用了来自 http://nvie.com/posts/a-successful-git-branching-model 的发布模型，它正在工作，但我们有时会努力适应。
背景： 我们只为 1 个独家客户维护一个内部网络应用程序。通常我们有两种版本：
- 次要：错误修复和小更改请求
- major：通常需要数月才能交付的重大变更请求
只有在客户批准后才能将这两种类型的版本部署到生产环境中。
我们有 4 种类型的分支，master、release、develop 和主题分支。一旦一个版本准备好发布，我们就会从master 分支出一个新版本。对于 CR，我们最初从 develop 分支，但后来我们发现它非常多余，因此我们现在从 master 分支。主题分支是错误修复和小 CR，它是来自正在进行的 release 或 master 分支的分支。当我们将足够多的 bugfix 合并到 release 分支中时，或者当需要发布紧急 bugfix 时，我们将准备好该release 分支出去，并启动一个新的release 分支。我们通常在固定的工作日每两周或每月发布一次。我们还通过在每次发布时将次要 release 分支合并到主要 release 分支来更新它。
我们使用 Gitlab 的 CI 在每次推送时构建我们的包，我们会将最后构建的包部署到我们的测试环境中，以供我们的测试团队进行测试。当release 分支稳定后，最终包通过测试并获得客户端批准发布，然后将同一包用于生产部署。
以下是我们的一些困惑。
- 由于我们总是从
release分支的尖端进行部署，我们认为没有必要将其合并回master。将release合并到master的提交不是已部署的提交。如果我们要使用最终的合并提交，那么我们将不得不再次经历测试周期，这似乎是多余的。我们还应该保留master吗？ -
develop分支似乎也不适合我们的工作流程，我们是否也应该放弃它？
最后，似乎对我们有用的是只有次要和主要的 release 分支，但我们想知道这是推荐的方式还是我们可以遵循更好的发布模型。
【问题讨论】：
-
“将发布合并到 master 的提交不是部署的那个。” 如果这是真的，那么您的流程就会有些混乱，因为所有到 master 的合并都应该快进，所以它们应该是相同的提交哈希。
-
@JeffPuckettII 对，它不是同一个提交哈希。所以这是我们应该关注的地方，谢谢
标签： git version-control git-branch branching-and-merging