Keep pull request open after merge?

Bitbucket Development
1

The current behavior of a pull request is that it is closed after the branch is merged.

However, we don’t have the resources to review PRs in a timely fashion. We need to be able to merge branches into the dev branch and continue development, while retaining the PR to provide a code review before the next release. The default behavior of Bitbucket prevents this.

Is there a setting so that the Merge button merges the branch without closing the PR and adds a Close command to close the PR manually? Or closes the PR automatically after one or more reviewers have approved or all have declined? Or provides Merge Only and Merge & Close buttons?

Or is this a feature request?

Our current strategy is to create a temporary branch from dev and use that as the destination of our feature branch. That way we can merge the feature branch to dev manually. Later, when the code review is complete, we merge the feature branch into the temporary branch and then merge the temporary branch into the dev branch. This is a lot more work than it needs to be.

Can you recommend a better strategy?

We are using Bitbucket Server if it matters.

1 Like
2

Hi Bill,

I understand that you need to merge to a branch intermittently and then perform a final merge including code review at the end of a development cycle. Keeping a PR open after merging it is not common practice.
I think your team is adopting a git-flow like like process, even if you’re using different branch names.

Do you use a ‘release’ branch at all?

The idea is to keep the ‘dev’ branch moving fast by frequently merging ‘feature’ branches and then create a pull request from ‘dev’ to ‘release’ and review the pull request thoroughly and once it is approve merge from ‘dev’ to ‘release’. You can perform verification tests either on ‘dev’ and/or on ‘release’ after the merge.

Let me know your thoughts and if you need any help.
Workzone for Bitbucket server/DC can help you to automate a lot of the process by adding reviewers and checking merge-conditions automatically so your team can focus on delivering great code!

Kind regards, Ulrich
Izymes
=Remove boring from your work=

3

Hi Ulrich,

Yes, we use the Atlassian git-flow, which seems to be based upon the Git branching model, but I happen to prefer dev over develop :-).

To clarify, you say to create a pull request from dev to release, but you really meant something like release/0.1.0, right?

The git-flow document mentions that the code review should be performed on the entire release when a pull request from release/0.1.0 to master is created. I think it would be difficult to review multiple conceptually different features in a single review. However, instead of merging dev into release/0.1.0 just once as the git-flow document suggests, creating a pull request from dev to release/0.1.0 every time a feature branch is merged as you suggest would keep the reviews more granular. Does the git-flow document need an update?

Thanks for that great suggestion!

4

I spoke too soon.

If you create a pull request from dev to release/0.1.0, that pull request will grow without bound as others merge their feature branches.

To keep the reviews focused on a single feature, would a good strategy be to merge feature branches into dev and then create pull requests from the feature branch to release/0.1.0?

5

Hi Bill,

in your original post you mentioned:

… so to achieve that the approach to ‘accumulate’ changes from feature branches in dev branch for a comprehensive review seemed like a good idea.

You are quite correct with

… and to “keep the reviews focused on a single feature”, smaller incremental pull requests and reviews are the way to go.
In fact you can have it all - the incremental pull requests and focussed reviews when you merge features into develop AND the big all-in-one pull request when you merge dev into release.

How you name your release branches is a matter of taste. Here at Izymes we try to keep it as simple as possible and maintain a single release branch. For each release we git-tag (with 0.1.0, for example) the merge commit that was created when dev was merged into release.

Let me know if that approach would work for you.

Kind regards, Ulrich
Izymes
= Remove boring from your work =

6

Thanks again, Ulrich.

I’ve discussed this with my team, and it is important for us to keep the review associated with the Jira issue rather than the release as a whole.

Until Bitbucket supports this use case, we’ll keep the pull requests on the feature branches against a temporary branch so that the review doesn’t get closed when we merge to dev.

1 Like