git - 强制执行代码审查并保持集成分支原始状态的工作流(git、Stash、TeamCity)

Question

我正在尝试设计一个遵循这些原则的新工作流:

• 只有通过自动验证 (CI) 的提交才能 merge 到主线中(具体来说， merge 后的状态应该通过 CI 以尽可能保持集成分支的原始状态)
• 只有通过人工代码审查的提交才能 merge 到主线
• 只有通过自动验证的提交才应该由另一个人审查(如果它甚至没有构建和通过测试，不要在上面浪费别人的时间)
• 特性分支应该被 CI 覆盖(独立的，不 merge 到集成分支——这对开发者在开发过程中有帮助)

我们正在使用 git、Stash 和 TeamCity。这是我想出的，但没有一个是完美的。我正在寻找对我的建议或新想法的调整。

工作流程 1

• 开发人员在功能/VHPC-1 上进行开发(功能分支包含在 TeamCity 中的正常 CI 中)
• 功能完成后，开发人员创建 pull 请求:feature/VHPC-1 --> mainline

• 当 pull request 被其他开发者批准后，它会自动被 Stash merge 到主线中(主线被 TeamCity 中的普通 CI 覆盖)

• 问题:如果存在 merge 冲突，Stash 将不会执行 merge ，但是在 merge 到主线之前根本不会测试 merge 状态。我们不知道主线是否会中断，直到它中断。

工作流程 2

• 开发人员在功能/VHPC-1 上进行开发(功能分支包含在 TeamCity 中的正常 CI 中)
• 开发人员从 feature/VHPC-1 推送到 feature/VHPC-1/review(我们在这里重新设置集成分支的基线，然后执行 CI(测试 merge 状态))
• 功能完成后，开发人员创建 pull 请求:feature/VHPC-1/review --> mainline

• 当 pull request 被其他开发者批准后，它会自动被 Stash merge 到主线中(主线被 TeamCity 中的普通 CI 覆盖)

• 问题:测试 merge 状态之间的时间(20 分钟 - 1 天？)，并且集成发生允许在集成分支中进行更改，这可能意味着 merge 状态不再有效。集成分支中断的可能性。

• 问题:分支数量的两倍意味着一些额外的复杂性和工作量。

工作流程 3

• 开发人员在功能/VHPC-1 上进行开发(功能分支包含在 TeamCity 中的正常 CI 中)
• 功能完成后，开发人员创建 pull 请求:feature/VHPC-1 --> feature/VHPC-1/review

• 当其他开发者批准并 merge pull request 时，feature/VHPC-1/review 将在 merge 状态下自动构建和测试，并在成功时自动 merge 到主线

• 问题:分支数量的两倍意味着一些额外的复杂性和工作。

• 问题:提交必须始终集成到主线中，并且只能经过精心挑选才能发布分支。

工作流程 4

• 开发人员在功能/VHPC-1 上进行开发(功能分支由 TeamCity 中的正常 CI)
• 功能完成后，开发人员 创建 pull 请求:feature/VHPC-1 --> mainline TeamCity 自动将自己添加为审阅者，并尝试构建和测试 pull 请求 - 处于 merge 状态(使用 Stash 的未记录的 引用文献/pull 请求/merge )

• 如果自动验证通过， TeamCity 将批准 pull 请求。然后一个人可能会回顾， 批准并 merge 到主线。

• 问题:TeamCity 监视器 refs/pull-requests/merge 在集成分支时发生变化 更改，这意味着将在所有打开的 pull 请求上触发构建 当集成分支有一个新的变化时。

Answer 1

这里是前 Stash 开发人员。只是一些一般的想法。

Stash 团队(以及我合作过和观察过的大多数团队)进行“乐观的”分支构建。也就是说，他们在假设/希望如果它干净地 merge 它可能不会破坏主线构建的情况下构建源代码分支。根据我的经验，情况几乎总是如此。

一些选项:

1. 什么都不做 - 如果/当主线最终崩溃时，请快速修复它
2. 什么都不做但是自动恢复任何产生红色构建的 merge 提交(并且可能手动开始)
3. 要求 PR merge 只能快进，开发人员需要在 merge 回来之前从主线手动 rebase /merge
4. 将自定义网守插件/按钮添加到 Stash 中，以“在集成后在绿色构建上 merge ”，在进行实际 merge 之前首先进行一次性 merge 构建。

我同意，根据您的 pull 请求打开的时间长短，通常从 Stash 的 stash “merge ”引用构建可能会导致构建过多(正如您所指出的)。

不确定这是否有帮助？