Git for the TFVC User – Workflow Investigations Part 2: Reviewing Changes (No Conflicts)

image_thumb2 … co-authored with Dan Hellem, complementing the Version Control (ex Branching and Merging) Guide.

Continued from Part 1 – Making Changes, we would like to share our notes, NOT guidance, and invite you to give us candid feedback on our proposed walkthroughs that are related to the high-level workflow steps mentioned above:

walkthrough 2.1 – reviewing changes using a Pull Request

We walk through the centralized workflow without creating merge conflicts to keep this workflow simple.

See Conduct a Git pull request on Visual Studio Online blog post for a detailed walkthrough.

We cover this portion of the Git Workflow quick reference poster:



Create topic branch, commit change and publish

꙱ - Done

Create Pull Request

꙱ - Done

Now that Doris has made her changes and published them to the repo, she will probably want someone on her team to review those changes. To do this, Doris will need to create a pull request.

  • From Team Explorer – Home, Doris will click on the Web Portal link. This will open the web browser and take you to your project.
  • In her web browser, Doris goes to Code > Pull Requests. She then clicks on the New Pull Request link.
  • Doris now needs to select the Doris\BugFix branch in in the “Review Changes in” and master (default) for the “relative to” branch
  • Doris will then enter the title, description and assign 1 or more reviews. In this case Dan will be our reviewer. She will then click the Create Pull Request button.


You cannot create or conduct a pull request through Visual Studio IDE. You must go into the Web Portal.

View Pull Request

꙱ - Done

Doris has completed the pull request and now Dan (or other teammates) need to review the changes Doris has introduced.

  • Dan will now login to TFS via the web portal > Open the project > Code > Pull Requests
  • The left navigation gives shows several options to view the available pull requests.


Viewing and Sorting

In this simple example, Dave only sees one pull request. He can use the navigation to sort by branch, status (active, completed, abandoned), and assignment.

  • Dan sees the pull request from Doris and clicks on the pull request to view all the details.
  • From this details screen Dan can participate in a discussion or review the code. The discussion is a history of notes and activities that have taken place during the lifetime of the pull request.
  • The Code tab displays Dan a list of files that have been changed, the number of commits, and the actual lines of code that have been changed. In this instance we see that 3 new lines have been added to our roster file.

Comment and Respond

꙱ - Done

  • During the process of reviewing the changes, Dan can place comments as general feedback or at the code line level.
  • Now Dan can provide an approved or rejected response to the changes that Doris has made. Dan can see his approval status and the status of his teammates from the Reviews list.


Pay attention to the Active status.

If the target branch has changed since the pull request was made, you will need to update it before the merge can be completed. Use the re-evaluate button to merge the changes into the top branch.

  • Once the team has approved the change, Doris is ready to complete the merge.

… to be continued in PART 3 - Reviewing Changes (With Conflicts)


Comments (3)
  1. David Bevin says:

    Nice article.

    Since the 2013 Update 4 release of TFS, I now thinks it's possible to use TFS and Git in a "nice" manner. However, I really think the Git client in Visual Studio needs work. I've been using Git (and other VCSes) for a number of years and I'm working with a small tram of experienced devs who have primarily used the "old" TFSVC through Visual Studio where the majority of the workflow has been well automated. When the team started using Git, they ran into problems with conflict resolution. The IDE didn't help so I moved them over to SourceTree by Atlassian and it made life a bit easier.

    I guess the key scenarios that it would be great if you could cover (happy to help if you want) are when:

    1. Origin master has moved on since user created their local topic branch (before push/pull request)

    2. Origin master moves on during the pull review process (I.e. just accept merge commit and dodgy looking history, or local rebase + force push to topic branch to fixup my code review)

    3. Rework for issues found during review (I.e. append commit, or local squash + force push)

    I know that force push is an advanced topic but I always try to do fast-foward merges to keep my history linear.

  2. Philippe says:


    As the developer of git-tfs, I will be very interested by the Part 4. I have already migrated the history of a company but it was a simple one (with few branches) but the one of the new company where I am is much more complicate! I can't wait to see if you will learn me something interesting ( or just fall behind…/ )


    >However, I really think the Git client in Visual Studio needs work.

    I really think so, too! Some needed things are missing ( rebase, stash, stage chunks, view DAG, not already stage all the files by default, not messy GUI, submodules,…)

    >I know that force push is an advanced topic but I always try to do fast-foward merges to keep my history linear.

    Not very good choice! Using the "github flow" (…/git_workflow_github_flow.jpg ) is much more interesting because you so more clearly where features are added (at the merge commit!) and you are much less polluted by commits when you must find a bug in your history (a lot less commit to try).

    You could also improve this workflow (…/tumblr_inline_nflo1khSyE1sv6muh.png ), just by rebasing before merging and the history will be a little more readable…

  3. David Bevin says:


    >Not very good choice!

    A very opinionated statement there but I assume you meant no offence (I didn't take any).

    The method I described is no more "wrong" or "better" than yours. It all comes down to personal preference and the whole merge/debase issue is perhaps the most debated issue between Git users. There are advantages to my approach, just as there are to yours. I made it clear my method was a personal opinion.

    I'm not responding to your post to insight a "flame war". I am only doing so to ensure that readers of this article, who are probably new to Git, understand that there are multiple options available to them and that they should consider what is best for their situation. I respect your very passionate opinion.

Comments are closed.

Skip to main content