How can we improve Visual Studio Team Services (VSTS)?

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.

343 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Maxwell Bloch shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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.

    22 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Albert Stimson commented  ·   ·  Flag as inappropriate

        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.

      • Benjamin Gare commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Eric Ralhan commented  ·   ·  Flag as inappropriate

        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.
        Cheers.

      • Josh Brown commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Any official word on this being implemented? I am actually debating moving to GitHub because this happens so frequently.

      • Trinh Pham commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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!

      • Vivek A Maharajh commented  ·   ·  Flag as inappropriate

        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.

      ← Previous 1

      Feedback and Knowledge Base