我们一直在进行持续集成和持续交付，因为Subversion会在管道触发时提交。最近，我们开始在git-flow的一些项目中使用git，我们正在尝试决定使用哪个git-flow分支来触发持续集成和连续交付管道。
以下是两种方法：
1。使用开发分支
问题：使用git-flow，我们应该在生产中部署发布（或主）分支，因此我们必须构建两个不同的管道，一个用于持续集成（分支开发），另一个用于持续交付（分支主管） ）。这可能会在生产中引入错误，因为生产中的版本与其他环境中的版本（集成，测试，登台）不同。
2。使用主分支：
问题：这样，我们就不会有真正的持续集成，因为这些分支的更改不会频繁推送。
哪个是在管道中使用的rigth分支？
3 个答案:
答案 0 :(得分：13)
根据定义，Git-flow和持续集成是不兼容的。分支是延迟集成的机制：当你提交除master（或trunk，如果你来自Subversion）之外的分支时，你就是在避免持续集成。持续集成很简单，但并不容易。
答案 1 :(得分：8)
真相在于两者之间。如果你想在严格的CD管道中采用git-flow，你应该为你的CI使用release-branch：
- 对于每个（批量）开发分支提交，让CI服务器自动创建一个发布分支并在其上运行所有测试。
- 如果失败，请让它报告和/或删除分支，否则将其合并为主分支。
基本思想来自John Ferguson Smart关于Java Maven项目中的CI / CD的幻灯片（BDD in Action，Jenkins Definite Guide）。
答案 2 :(得分：6)
在我看来，如果你想在持续交付中应用git-flow，你应该有两个不同的管道，就像你在第一种方法中所说的那样。
我建议采用这种方法：
<强> 1。开发分支
- 开发分支将触发提交构建：一旦功能被添加到开发分支（在合并或拉取请求上），CI将构建，测试（单元测试和代码修订）并打包解决方案（使用＆＃34; -develop-vX＆＃34;后缀）。因此，团队能够在发生故障时快速做出反应。
- 提交构建成功完成后，任务完成（否则，更改将被还原，提交更改的开发人员必须立即修复）。同时，验收测试阶段开始将先前的构建部署到开发环境以执行验收测试套件（例如功能和回归测试），而不会阻碍开发人员的工作。完成后，将开发分支状态传达给团队。因此，团队了解当前Sprint期间解决方案的稳定性：如果验收测试阶段成功完成，则产品已准备好与Master分支合并（否则，它将被修复）。 / LI>
<强> 2。主分会
- Sprint完成后，稳定的开发人员分支（它稳定）将合并并标记为Master Branch。因此，Master Branch将触发Trunk Commit Build，它将构建解决方案，对其进行测试并打包以进行部署（该软件包现在存储有候选版本或主后缀）。
- 如果Trunk Commit Build成功完成（它应该工作），Acceptance Test Stage将针对Integration环境部署和验证验收测试。如果成功，新版本已准备好投入生产。否则，如果在Commit Build或Acceptance Test Stage出现错误，则会恢复合并。