通过 Bitbucket 云上的拉取请求重新调整工作流程

Question

我在 bitbucket 云上创建了两个分支，并为这两个分支中的每一个创建了两个拉取请求。拉取请求合并策略设置为“合并提交”。合并拉取请求后，提交树如下所示：

这些是合并策略： Bitbucket 云上如何避免这种情况？如果分支可以看起来像这样或者这是例外，那么变基有什么意义？

Answer 1

BitBucket 有自己的拉取请求合并策略，包括：

变基，快进 ( rebase+ merge --ff-only)：

从源分支提交到目标分支，为每个传入提交创建一个新的非合并提交。
使用结果提交快进目标分支。此操作不会修改 PR 分支。

和：

仅快进 ( --ff-only)：

如果源分支与目标分支已经过时，则拒绝合并请求。否则，将目标分支更新到源分支上的最新提交。

任何一种都可以避免合并提交并产生线性历史记录。

第二个假设 PR 分支在开发人员工作站本地重新建立基础，然后push --force：合并变得微不足道。

OP David在评论中问道：

因此，如果同时创建两个拉取请求，我需要在本地重新设置每个第二个拉取请求的基准？

“同时”创建两个 PR 的事实与该过程无关。

其中一个将被合并（没有问题，因为它是第一个被合并的）

第二个不会被合并（被拒绝，因为不是快速合并）

开发人员别无选择，只能：

• 拉 master 来更新它并更改桅杆（这里是第一个合并的 PR）
• 在 master 之上本地 rebase 第二个 PR（在本地解决冲突，确保它仍然有效）
• 力推
• 通过Web GUI合并第二个PR（合并是快进的，它将被接受）

涉及当地和解的过程是通常的最佳做法。