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