我正在尝试设计一个遵循以下原则的新工作流程：
- 只有通过了自动验证 (CI) 的提交才应该被合并到主线中（特别是合并状态应该通过 CI 以保持集成分支尽可能原始）
- 只有通过人工代码审查的提交才应该合并到主线中
- 只有通过自动验证的提交才应该由另一个人审查（如果它甚至没有构建和通过测试，不要浪费别人的时间）
- 特性分支应该被 CI 覆盖（独立地，不合并到集成分支中——这对开发人员在开发过程中很有帮助）
我们正在使用 git、Stash 和 TeamCity。这是我想出的，但没有一个是完美的。我正在寻找对我的建议或新想法的调整。
工作流程 1
- 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
- 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1 --> mainline
当拉取请求被其他开发者批准时，它会被 Stash 自动合并到主线中（主线被 TeamCity 中的普通 CI 覆盖）
问题：如果存在合并冲突，Stash 将不会执行合并，但是直到合并到主线之后才完全测试合并状态。我们不知道主线是否会中断，直到它发生。
工作流程 2
- 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
- 开发人员从 feature/VHPC-1 推送到 feature/VHPC-1/review（我们在这里重新设置集成分支，然后进行 CI（测试合并状态））
- 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1/review --> mainline
当拉取请求被其他开发者批准时，它会被 Stash 自动合并到主线中（主线被 TeamCity 中的普通 CI 覆盖）
问题：测试合并状态和发生集成之间的时间（20 分钟 - 1 天？）允许在集成分支中进行更改，这可能意味着合并状态不再有效。集成分支中断的机会。
- 问题：分支数量的两倍意味着一些额外的复杂性和工作。
工作流程 3
- 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
- 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1 --> feature/VHPC-1/review
当另一个开发者批准并合并拉取请求时，feature/VHPC-1/review 将在合并状态下自动构建和测试，并在成功时自动合并到主线
问题：分支数量的两倍意味着一些额外的复杂性和工作。
- 问题：提交必须始终集成到主线中，并且只能挑选出来发布分支。
工作流程 4
- 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
- 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1 --> 主线 TeamCity 自动为自己添加一个审阅者，并尝试构建和测试拉取请求 - 处于合并状态（使用 Stash 的未记录的 refs/pull -请求/合并）
如果自动验证通过，TeamCity 将批准拉取请求。然后，人类可以审查、批准并将其合并到主线中。
问题：TeamCity 监控 refs/pull-requests/merge 在集成分支更改时会更改，这意味着当集成分支获得一个新更改时，所有打开的拉取请求都会触发构建。