使用 git-flow 进行持续集成和持续交付
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/32387201/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Continuous integration and continuous delivery with git-flow
提问by alejokf
We have been doing continuous integration and continuous delivery since a while with Subversion commits as the pipelines triggers. Recently, we started using git in some projects with git-flowand we are trying to decide which of the branches of git-flow should we use to trigger the continuous integration and continous delivery pipelines.
一段时间以来，我们一直在做持续集成和持续交付，Subversion 提交作为管道触发。最近，我们开始在一些带有git-flow 的项目中使用git，我们正在尝试决定我们应该使用 git-flow 的哪个分支来触发持续集成和持续交付管道。
Here are two approaches:
这里有两种方法：
1. Use develop branch
1. 使用开发分支
Problem: With git-flow we are supposed to deploy the release (or master) branch in production, so we would have to build two different pipelines, one for continuous integration (branch develop) and one for continuous delivery (branch master). This could introduce bugs in production because the version in production will not be the same that the one in other environments (integration, test, staging).
问题：使用 git-flow 我们应该在生产中部署发布（或主）分支，所以我们必须构建两个不同的管道，一个用于持续集成（分支开发），另一个用于持续交付（分支主）。这可能会在生产中引入错误，因为生产中的版本与其他环境（集成、测试、暂存）中的版本不同。
2. Use master branch:
2.使用主分支：
Problem: This way, we would not have a truly continuous integration, since changes to these branches are pushed not very frequently.
问题：这样，我们不会有真正的持续集成，因为对这些分支的更改不是很频繁地推送。
Which is the rigth branch to use in the pipelines?
哪个是管道中使用的 rigth 分支？
回答by xpmatteo
Git-flow and continous integration are, by definition, incompatible. Branches are a mechanism for delaying integration: when you commit to a branch other than master (or trunk, if you come from Subversion), you are avoiding continous integration. Doing continous integration is simple, but not easy.
根据定义，Git-flow 和持续集成是不兼容的。分支是一种延迟集成的机制：当您提交到 master 以外的分支（或主干，如果您来自 Subversion）时，您是在避免持续集成。进行持续集成很简单，但并不容易。
回答by Arman
The truth lies between the two. If you want to adopt git-flow in a strict CD pipeline, you should use the release-branch for your CI:
真相介于两者之间。如果你想在严格的 CD 管道中采用 git-flow，你应该为你的 CI 使用 release-branch：
- For every (batch of) develop-branch commit(s), let your CI server automatically create a release-branch and run all your tests on it.
- If it fails, let it report and/or delete the branch, otherwise merge it to master.
- 对于每（一批）开发分支提交，让您的 CI 服务器自动创建一个发布分支并在其上运行所有测试。
- 如果失败，让它报告和/或删除分支，否则将其合并到 master。
The basic idea comes from John Ferguson Smart's slide about CI/CD in Java Maven projects (BDD in Action, Jenkins Definite Guide).
基本思想来自 John Ferguson Smart 关于 Java Maven 项目中 CI/CD 的幻灯片（BDD in Action，Jenkins Definite Guide）。
回答by sergi
In my view, if you want to apply git-flow in Continuous Delivery, you should have two different pipelines as you said in your first approach.
在我看来，如果你想在持续交付中应用 git-flow，你应该有两个不同的管道，就像你在第一种方法中所说的那样。
I'd suggest this approach:
我建议这种方法：
1. Develop branch
1. 开发分支
- Develop branch will trigger the Commit Build: As soon a feature is added to the develop branch (on merge or pull request), the CI will build, test (Unit Testing & Code revision) and package the solution (with a "-develop-vX" suffix). So the team is able to react fast in case of failure.
- Once the Commit Build has finished successfully, the task is done (otherwise, the change is reverted and the developer who committed the change must fix it immediately). In parallel, the Acceptance Test Stage starts deploying the previous build to the Development environment for executing the Acceptance Test Suits (e.g. Functional & Regression testing) without blocking the developer's work. Once it's finished, the develop branch status is communicated to the team. Therefore, the team is aware of the solution's stability during the current Sprint: if the Acceptance Test Stage finishes successfully, the product is ready for merging with the Master branch (Otherwise, it'll be fixed).
- Develop 分支将触发 Commit Build：一旦将功能添加到开发分支（在合并或拉取请求时），CI 将构建、测试（单元测试和代码修订）并打包解决方案（使用“-develop- vX”后缀）。因此，团队能够在出现故障时快速做出反应。
- 一旦 Commit Build 成功完成，任务就完成了（否则，更改将被还原，提交更改的开发人员必须立即修复它）。同时，验收测试阶段开始将先前的构建部署到开发环境，以在不妨碍开发人员工作的情况下执行验收测试套件（例如功能和回归测试）。完成后，开发分支状态将传达给团队。因此，团队了解当前 Sprint 期间解决方案的稳定性：如果验收测试阶段成功完成，则产品已准备好与 Master 分支合并（否则，它将被修复）。
2. Master branch
2.主分支
- Once the Sprint is finished, the stable Developer branch (it's stable) is merged and tagged to Master Branch. So the Master Branch will trigger the Trunk Commit Build that will build the solution, test it and package for deployment (the package now is stored with a release candidate or master suffix).
- If the Trunk Commit Build finishes successfully (it should work), the Acceptance Test Stage will deploy and validate the acceptance tests against an Integration environment. And in case of success, the new version is ready for production. Otherwise, in case of error at Commit Build or Acceptance Test Stage, the merge is reverted.
- 一旦 Sprint 完成，稳定的 Developer 分支（它是稳定的）被合并并标记到 Master 分支。因此，Master 分支将触发 Trunk Commit Build，它将构建解决方案、测试它并打包以进行部署（该包现在与发布候选或主后缀一起存储）。
- 如果中继提交构建成功完成（它应该可以工作），验收测试阶段将针对集成环境部署和验证验收测试。如果成功，新版本就可以投入生产了。否则，如果在 Commit Build 或 Acceptance Test 阶段出现错误，合并将恢复。
