Change Pull Request Target Branch
It would be great to be able to change the target branch of a pull request. Sometimes a pull request is simply opened against the wrong branch. Other times, the comments and discussion resolve in wishing to integrate with a different branch prior to promoting to the original target.
We’ve seen this climbing in recent months, and we recently revisited the priority of this on the backlog. It’s currently on our list of items we want to tackle in the next few months. I’ll update when it’s officially part of our 3-sprint plan.
MAYSAM GAMINI commented
Please Give high priority on this.
Albert Stimson commented
This is part of our basic workflow, not just needed when a dev makes a mistake. When a pull request misses a deadline for a code freeze, it generally needs to target a different branch. Redoing all of the documentation, comments, and attached work items after abandoning the pull request is not ideal.
Joydeep Tapadar commented
I am also facing the issue often. Please give priority on this task and give update
Benjamin Gare commented
Can we get a target date for this? I have to change the target branch OFTEN in my daily work since some Pull Requests have a longer review process.
James Chorlton commented
Any news on this Microsoft? Found my way here whilst googling how to do it in VSTS, not a great thing that the top google result tells you that you cant do it.
Lee Richardson commented
Wait, so if I have stacked PR's I have to delete and resubmit downstream PR's when an upstream one gets merged?! All the comments and dialog gets deleted?! I just moved from github and assumed this was a standard feature. And this has been a feature request for 2 years?! Poorly done VSTS.
Brian Kelley commented
This is an especially useful feature for stacked Pull Requests. PR 2 depends on PR 1. Both are created and PR 2 is targeted to PR 1's branch for diffing purposes. PR 1 is completed and merged to master, then PR 2 is updated to target to master and completed.
Bert Cotton commented
This is a feature that GitHub has that our developers often comment on VSTS not having.
Eric Ralhan commented
This is a basic feature in contemporary git source control tools. And as this was raised back in 2015, I don't think it's in backlogs items. This is why I prefer open source over MS.
Josh Brown commented
Chiming in to this thread to request this feature as well. We've run into this exact issue several times already. Would love to be able to change the target branch instead of abandoning the PR and losing the comment history in the process.
Any official word on this being implemented? I am actually debating moving to GitHub because this happens so frequently.
Trinh Pham commented
The scenario I met is: We have a release[Ver] branch where all Developers target their pull requests to it.
When the release[Ver] is locked for releasing, new release[Ver2] is created for next release. All uncompleted PRs need to re-target to the new branch.
Abandon & re-create causes loosing all the comments.
So, implement this feature like Github is really good and solve our problem.
Official branch locked for the foreseeable feature. 40+ developers asked to move all their PRs to a different branch, identical (i.e. same commit) as the official.
Now everybody needs to abandon their PRs and recreate them, losing comments, etc.. Please implement this. Thanks.
Similar issue to Peter here. Very difficult to have multiple PR's out simultaneously when some of those PR's build off of previous PR's. Either you target them all to master and they include each other in the diff, or you target them at each other and have to recreate the PR later in a very nasty fashion.
Root issue is dependent PR, so anything that can fix that works for me.
+1 This just happened to me as well...
This would be so much easier and cleaner than having to abandon and make a new one since that loses all the code review history as well. I find this happening multiple times a month.
Agreed. This would greatly simplify my workflow when changes need to be promoted from "scheduled for next release" to "critical release." Currently that requires abandoning the existing pull request and creating a new one just to skip our prerelease branch. If we could directly move pull requests between the two branches, it would be much better.
Peter Kurlak commented
Not having this feature prevents taking advantage of the true power of the Git workflow: being able to work on and receive reviews for multiple things at once. Before I knew of this limitation, I created a PR against a branch other than master. It was awesome! My coworkers were able to provide feedback on code that depended on another branch not yet in master. After some dialog, they approved my changes. When I had received all my approvals and the owner was ready to review, I suddenly discovered this problem. Now I had to "throw" away a perfectly good PR and create a new one against master. The comments and approvals obviously did not transfer. Thus, I had to ping everyone that had previously approved the code to do so AGAIN (developers hate repetition), and then the code's owner had to reference the previous PR. And what if he wanted to add comments? Should they go on the previous PR or the new PR? What a mess. This needs to be fixed ASAP!
Thomas Piart commented
We also do have the same scenario as @Vivek
Vivek A Maharajh commented
My use case involves working on a new pull request that depends on the commits of an existing pull request.
I create a pull request from branch A into master.
While it is being reviewed, I start working on a change that depends on the commits in A, so I create a new branch B based on A. I now create a pull request from branch B into branch A. I never intend to merge into branch A — I intend on merging into master **after** the initial pull request is merged into master.
After the initial pull request completes, I'd like to change the target branch for the second pull request to be master.