Freigeben über

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

  • Artikel

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:
image

Step

Instructions

1 Create topic branch, commit change and publish

꙱ - Done

2 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. image
  • Doris now needs to select the Doris\BugFix branch in in the “Review Changes in” and master (default) for the “relative to” branch image
  • 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.

NOTE

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

3 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. image

GEM

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. image
  • 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. image

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

NOTE

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)

Thoughts?

Comments

  • Anonymous
    April 16, 2015
    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.
  • Anonymous
    April 16, 2015
    The comment has been removed
  • Anonymous
    April 17, 2015
    @Philippe >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.