git - 在 bitbucket 云上使用 pull 请求重新调整工作流程

Question

我在 bitbucket 云上创建了两个分支，并在两个分支中分别创建了两个 pull 请求。 pull 请求 merge 策略设置为“merge 提交”。 merge pull 请求后，提交树如下所示:



这些是 merge 策略:

如何在 bitbucket 云上避免这种 szenario？如果分支可以看到这个或者这是异常(exception)，那么重新定位有什么意义？

Answer 1

BitBucket 的 own merge strategies for pull requests 包括:

Rebase, fast-forward (rebase + merge --ff-only):

Commits from the source branch onto the target branch, creating a new non-merge commit for each incoming commit.
Fast-forwards the target branch with the resulting commits. The PR branch is not modified by this operation.

和:

Fast-forward only (--ff-only):

If the source branch is out of date with the target branch, reject the merge request. Otherwise, update the target branch to the latest commit on the source branch.

任何一个都会避免 merge 提交并产生线性历史记录。
第二个假设 PR 分支在开发人员工作站本地重新定位，然后 push --force : merge 变得微不足道。

OP David 询问 in the comments :

So I need to rebase every second pull request locally, if there are two pull requests created at the same time?

“同时”创建两个 PR 的事实与该过程无关。
其中一个将被 merge (没有问题，因为它是第一个被 merge 的)
第二个不会被 merge (被拒绝，因为不是快进 merge )
开发人员别无选择，只能:

pull master 更新它并更改了桅杆(这里是第一个 merge 的 PR)

将第二个 PR 在本地重新建立在 master 之上(在本地解决冲突，确保它仍然有效)

力推

通过 Web GUI merge 第二个 PR( merge 是快进的，它将被接受)

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