Conduct a Git pull request on Visual Studio Online

Conduct a Git pull request on Visual Studio Online

Rate This
  • Comments 17

When you want people on your team to review code in a Git team project on Visual Studio Online, you can use a pull request to review and merge the code. Pull requests enable developers working in topic branches to get feedback on their changes from other developers prior to submitting the code into the master branch. Any developer participating in the review can see the code changes, leave comments in the code, and give a "thumbs up" approval if they're satisfied with those changes.

Create a topic branch

Before you commit your code in Visual Studio, create a topic branch.

Adding the omlette.txt file.

Commit your changes to the topic branch.

Commit your changes

When you are ready to share your work, publish the branch.

Publish the branch

For example, Jamal creates his topic branch and pushes it to the server.

Create a pull request

Open the web portal.

In your web browser, create the pull request. Select your topic branch as the source and the branch you want to merge into as the target branch.

Click New Pull Request

Specify the title, description, and assign reviewers.

Edit the title, description, and reviewers

Conduct a pull request

Reviewers make comments on specific lines of code. If you want to be specific, select a specific block of code before inserting the comment.

Reviewers add general comments to the pull request.

Tip: To add a new line to a comment, press Shift+Enter.

All conversations and other events appear on the Discussion tab.

Team conducts a pull request

Make changes on the source branch

To act on the feedback, the requestor revises the code on their dev machine and pushes the changes so that reviewers can see them. For example, Jamal takes Raisa's advice to change the color of the peppers.

Complete the pull request

Each reviewer approves or rejects the pull request.

A single approval is sufficient to approve the pull request. A single rejection overrides all approvals and causes the status to be rejected. When you approve or reject the pull request, team members are alerted if they have subscribed to alerts.

If the code in topic branch changes, your vote does not automatically change. So for example, if you approved the pull request but would want to re-check it if changes were made, you should make sure you stay notified about changes.

When the requestor and the reviewers are satisfied that the pull request is ready to merge, you can do it from the web browser.

After the merge, the target branch is updated with the changes from the topic branch.

After the merge, the topic branch (for example, jamal/breakfast) is still in the repository. To keep your repository from getting cluttered by obsolete branches, you can delete the topic branch in your web browser.

Your target branch has been updated and the topic branch has been deleted. All of the commits that were merged are still in the repo.

All the commits and comments in pull request are still available if you need to refer to them later.

Q&A

Q: How can I make sure I'm notified when a pull request is created or changed?

A: If you are in the team room, you'll see notifications there.

If you want to be notified about new pull requests, changes, approvals, and rejections, then subscribe to email alerts.

Q: How do I see the full content of the file?

A: Select the file in the left pane.

To see changes inline:

Q: Why do I see "Target branch updated, retry merge"? What should I do about it?

A: If changes are pushed to the target branch during the pull request, retry the merge to make sure there are no conflicts.

If there are no conflicts, then you are ready to merge again.

If there are conflicts, see Q: Why do I see "Merge conflicts"? What should I do about it?

Q: Can I continue working on the target branch during the pull request? Can I merge changes from the target branch to the source branch?

A: Yes. For example, changes have been made on the jamal/breakfast source branch and on the raisa/breakfast target branch.

If you want to merge the changes from the target branch, pull the changes to your dev machine.

Next, merge the changes.

Q: Why do I see "Merge conflicts"? What should I do about it?

A: Conflicts can occur when you try to merge two branches. For example, a conflict often occurs when you merge two branches in which the same file is changed.

If you are trying to merge from source to target, you see merge conflicts in the pull request.

You are also blocked by the conflict if you try to merge from target to source.

After you merge the branches in Visual Studio, use the merge tool to resolve the conflicts.

Next, commit the merge.

Finally, push the merge.

Q: Why did a comment move or disappear?

A: Comments are anchored to the line number and column of the commit on which comment was made. That's why comments can disappear or move in the discussion view.

Questions? Suggestions? Feedback?

I invite you to post:

Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post
  • When will this be implemented in TFS?

  • Hello, this should start rolling out for Visual Studio Online users starting today.

  • Is it possible to create a Pull Request from another repository inside the same Team Project? Much like forking on GitHub?

  • @Manuel - At this time, Pull Requests can only be created across branches within a single repository.  We do have forking on our backlog, and when we implement it, we will also add support for fork-to-parent-repo pull requests.

  • Is there a way to lock down a branch, so that changes can only be merged in if they've gone through a pull request?

  • Does it support emoji and animated gifs?

  • @Adam - We don't yet have distinct permissions for contributing via push and contributing via pull request, but this is a scenario that we're working on enabling in a future update.

    @PeteGoo - I'm assuming that you're talking about the commenting experience - no, we do not support either of those at this time.  It would be great if you filed a suggestion on visualstudio.uservoice.com so we can gauge the priority of this with the community.

  • A soft level at questions presents result in numbers news. My revious at page not is great hard.

  • My discount in social media player is haved in more bitcoins for on line connections at others complements a leave comment up to dates agile locale ipoint News.

  • Pleased to see this entering general availability - I've spent the last few months being taunted by Bitbucket/Github users about my lack of ability to manage pull requests! Will be briefing the team on this in the next few days; looking forward to using it.

  • Is it possible to create a merge commit instead of fast forward when hitting merge button?

  • Is it possible to create a merge commit instead of fast forward when hitting the merge button?

  • Will this be in the next release of TFS (the on-prem version?)

  • Very nice feature !

    Following your example, I've noticed that, after pushing the commit containing the revisions suggested by the feedback received, the code reviews continue to point to the same line number - meaning that if i added several lines of code at the beginning of the file, all the code reviews will point to irrelevant lines. I didn't have any merge conflict.

    I guess it would be tricky to do in case of merge conflicts, but are there any chances it would work for simples cases in the future ? or am I doing something wrong ?

  • @Carlos - Not yet, but we're considering adding a --no-ff option that can be set to require that a pull request is always merged.  We might also make this a setting at the branch or repo level.  If you added a suggestion on visualstudio.uservoice.com that would help us track the need for this.

    @Jonathan - Yes, pull request will be available in the next major TFS release.  

    @Francois - You're correct, today we anchor comments to the original line number at which they were left by the reviewer, and this is not updated when further changes are pushed.  We do have plans to improve this experience so that the comment will be able to be seen in the correct context.

Page 1 of 2 (17 items) 12