问题描述
我们有 5 名开发人员在一个团队中定期（每天）向单个存储库的主分支提交拉取请求。典型的工作流程是这样的：
- 从服务器克隆存储库
- 从主分支创建本地功能分支
- 进行更改、提交、迭代直到完成
- 变基到主分支（壁球提交）
- 推送到服务器
- 提交拉取请求
问题是如果多个开发者提交pull request，只有1个可以成功合并到master分支。一旦完成，所有其他人都会失败，因为主分支在功能分支之前。然后所有开发人员必须再次变基并推送。那么只有1个可以合并，其余的失败。迭代直到所有 PR 合并。
一定有更好的方法，对吧？
解决方法
Bitbucket 有 following merge strategies available。听起来您的团队选择了“仅快进”或“仅壁球，仅快进”。如果 PR 没有完全重新定位，这将拒绝 PR，并且正如您所注意到的，这在 PR 排列时很烦人。
如果您想保持干净的历史图表并且不有合并提交（我认为这是选择该选项开始的原因），那么您可以使用的另外两个选项是： “变基、快进”或“壁球”。这些将在完成时执行 rebase，并且如果它们已排队，则不应阻止请求。
旁注：我个人更喜欢其他一些工具所说的“半线性合并”，这相当于 BitBucket 选项“重新定位，合并”。这会强制合并提交，这很好，因此您可以查看与该 PR 关联的所有提交，并使您能够查看 --first-parent 历史记录，其中显示对 master 分支所做的实际更改。但是，在您的情况下，如果每个人都为每个 PR 压缩到一个提交中，那么您可能几乎没有价值收益。但是，如果您决定在单个 PR 中允许多次提交，那么它可能会朝这个方向倾斜。