Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Pull request code reviews when you don't have a target branch ready

echolocation
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 16, 2019

I'm using BitBucket 5.15, and want to know what a good way to achieve a code review on a pull request where I'm not yet certain which branch I want to merge it in to.

I need to review some code in a branch, and I would like to use the nice features of BitBucket pull requests to do that. We don't merge to master, instead we merge feature branches into a release branch. We do code reviews before testing, and any bugs found in test are also subsequently reviewed. We don't merge code into a release until it has been both tested and reviewed.

Sometimes the features are ready a month or more before we're prepared to test & release them, and during that time priorities can change from management, which might see a feature be pushed back to a later release. So I can't just open a pull request into say v2.1 when it might end up landing in v2.5. But I need a way to review the developers code now rather than a month down the track when they've moved on to their next project and it's no longer fresh in their mind.

 

What are my options?

1) Can I create a bitbucket pull request against a release branch but never have it merged? I would only do this if we could definitely prevent accidental merges to the release branch, I don't want to pollute it with accidental commits - mistakes happen.

2) Should I create a separate review branch based off what release I think it might end up in? i.e.

git checkout release-v2.1

git checkout - review-feature-a

then create a pull request from feature-a --> review-feature-a branch?

So even if it is accidentially merged, it only goes into the review-feature-a branch and not release-xyz branch.

This approach requires a final merge/pull request into the actual release branch once we've decided what release the feature will go in.

3) Something else?

1 answer

1 vote
Jimmy Seddon
Community Champion
April 16, 2019

Hi @echolocation,

We struggled with that as well, what we ended up doing was deciding that once we have committed to doing the work on a feature of bug fix we are going to make sure that work goes all the way to production.  Because of this we started following this branching strategy for Git, I hope this helps you.

https://nvie.com/posts/a-successful-git-branching-model/

-James

echolocation
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 16, 2019

Interesting, I'll take a look, thanks!

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events