时间戳

首页 > 解决方案 > 在 bitbucket 云上使用拉取请求重新设置工作流程

git - 在 bitbucket 云上使用拉取请求重新设置工作流程

问题描述

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

在此处输入图像描述

这些是合并策略： 在此处输入图像描述 如何在 bitbucket 云上避免这种情况？如果分支可以这样看，或者这是例外，那么 rebase 有什么意义？

标签： gitbitbucket

解决方案

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

变基，快进（rebase+ merge --ff-only）：

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

和：

仅快进 ( --ff-only)：

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

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

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

OP David在评论中问道：

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

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

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

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

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

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

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

推荐阅读