Starting today your pull requests will always have the most recent and relevant code, and your reviews will be more efficient. With automatic updates, pushing to a branch with an open pull request will automatically include those commits in the open pull request. This way your reviewers will always see the most recent changes to the branch in the pull request.

The most important thing about a pull request is the discussion that it generates: As you get feedback from other developers about changes or improvements that should be made, you’ll be generating new commits which should be part of your review. Now you’ll automatically see those commits in the pull request with no extra steps.

More best practices for your team

Everywhere, teams are making the switch from Subversion to Git. If you’re new to Git and want to learn more, check out Atlassian Git Essentials, our solution to implementing best practices with Git for your development team.

Now if we can just get the Pull Requests to show up in the Jira issues again…

Andrew

This should really be a checkbox that is checked by default when we make a pull request, but have the option to uncheck it as necessary. I understand the merits of having auto-update, but there are also merits to the way it previously worked as well.

Robert Bartlett

Auto-updating a pull request can make it very difficult for reviewers. Let us say, that a reviewer has approved a pull request. A new commit is then automatically added to that pull request. Is it assumed that that reviewer approved that commit? Context is extremely important, and mutating the contents of a pull request certainly has value for particular scenarios, but I do not approve of making this mandatory. I do not want to constantly be reviewing a moving target. This does not sit well with the notion of trunk-based development…

Jon Langevin

I haven’t tested the new auto-update functionality, but based on how Github behaves, my assumption would be that once a PR has been approved, updates to a branch do not affect the original PR. You would have to submit a new PR to capture the new changes on the same branch.

Robert Bartlett

Not quite correct. It is not until a pull request has been merged that commits are no longer added to it.

Let’s step through an example. Assume a team of six developers: A through F, that operate using a trunk-based development pattern. There is a “review” branch, where code is merged from master, via a pull request, after having been reviewed.

Assume that master is up to commit 23, and review is up to commit 18. Dev A opens a pull request from master to review. There are currently 5 commits in that pull request. All the developers start reviewing the pull request.

Dev B then pushes a commit to master. Commit 24 is automatically added to the pull request.

Dev C, now appears to have approved the pull request despite not having reviewed commit 24.

This leads to three problems:
– reviews end up missing things, as commits are made after an approval.
– teams feel “blocked” whilst there is an open pull request.
– pull requests are open for a longer time period, as more changes keep getting added.

The way that it used to work, commit 24 would not be automatically added to the pull requests. Devs were able to review a set of commits, and proceed with confidence that the set of commits was not going to change during the life of the pull request.

Please consider changing this. Pull requests just lost a lot of value.

Ian Thomas

I agree. I’d expect a new commit to invalidate the previous approval.

qraynaud

Yeah, I would also like to be able to disable this behaviour to stick with the old way.

Thomas Maloney

This isn’t working for me and my team, please see issue #9356 in site/master, thanks!

fedeaf

This is a real issue for us.
A PR could come from a branch that can not be freeze during the PR review and needs to keep including new features. Suddenly the PR about feature A includes 2 other features.
I can’t understand how a change like this can be consider an improvement when we already had the option to update the PR but when needed, not automatically.
This has to be seen as missing a feature and not the other way around.

Jon Langevin

With that workflow, how do you apply a correction to a PR, if the branch wasn’t frozen and other “features” were integrated already?

Seems like a flawed process. Branches are cheap, simply dedicate a branch per feature so you can ensure a frozen view, which then allows for corrections to occur as well.

Powerlord

Great… and this justifies breaking the principle of least astonishment why?

Jon Langevin

Depends on what your experience is. If you’re someone switching from Github to Bitbucket, then Bitbucket’s new approach best conforms to POLA for that user’s perspective.

I agree that forcing this change on everyone is excessive though, rather it should be a per-repo feature.

Great. How do I disable this behavior? I made a pull request to fix one bug and continued doing research to try to fix another bug, only to have my HIGHLY UNSTABLE test code automatically merged into the pull request.

Jamie

If an update was made to a pull request then let me know when I look at the pull request, and offer me a button to update (and maybe letting me optionally choose the commit I want to merge in). But please stop the madness of creating moving targets for pull requests!