【发布时间】：2020-08-16 16:08:22
【问题描述】：
我在 bitbucket 云上创建了两个分支，并为这两个分支中的每一个创建了两个拉取请求。拉取请求合并策略设置为“合并提交”。合并拉取请求后的提交树如下所示：
这些是合并策略： 如何在 bitbucket 云上避免这种情况？如果分支可以看起来这样或者这是例外，那么 rebase 有什么意义？
【问题讨论】：
-
在你的情况下，我会选择快进。
【发布时间】：2020-08-16 16:08:22
【问题描述】：
BitBucket 的own merge strategies for pull requests 包括：
变基，快进 (
rebase+merge --ff-only)：从源分支提交到目标分支，为每个传入的提交创建一个新的非合并提交。
使用结果提交快进目标分支。此操作不会修改 PR 分支。
还有：
仅快进 (
--ff-only)：如果源分支与目标分支过期，则拒绝合并请求。否则，将目标分支更新为源分支上的最新提交。
两者都可以避免合并提交并产生线性历史记录。
第二个假设 PR 分支在开发人员工作站本地重新设置，然后push --force：合并变得微不足道。
所以如果同时创建了两个拉取请求，我需要在本地每隔一个拉取请求重新定位一次？
“同时”创建两个 PR 的事实与该过程无关。
其中一个将被合并（没有问题，因为它是第一个被合并的）
第二个不会被合并（被拒绝，因为不是快进合并）
开发者别无选择，只能：
- pull master 更新它，mast 改变了（这里是第一个合并的 PR）
- 将第二个 PR 在本地重新设置在 master 之上（在本地解决冲突，确保它仍然有效）
- 强制推送
- 通过 Web GUI 合并第二个 PR（合并是快进的，将被接受）
涉及本地和解的过程是通常的最佳实践。
【讨论】：
-
云中只有一种快进策略
-
@David OK：第二个是：快进。
-
@David Rebase 在本地然后强制推送。应该避免什么？ diea 是在本地解决任何冲突，并检查第二个 PR 在应用于第一个（第一次合并）之上时是否仍然有效
-
@David 这就是你在本地变基的原因：一旦第一个被合并，你更新 master（这将包括第一个），变基第二个，强制推送和合并。
-
@David 这些 PR 是同时创建的这一事实并不重要：一旦将两者之一合并，然后（并且只有这样）你才变基master 之上的第二个（因为 master 现在包括合并的 PR）