Pull requests provide better collaboration and code reviews

1. Git: Pull Requests
Better Collaboration and Code Reviews

2. About me
Callon Campbell
Full-stack developer / technical lead. With over 19 years of experience
developing desktop, mobile and web enterprise applications using
Microsoft .NET Framework, SQL Server and Azure technologies.
Co-founder of ReflectSoftware Inc and one the principle developers of
ReflectInsight, a real-time .NET logging/analytics framework and
Live/Log Viewer.
Email: CallonCampbell@Outlook.com Twitter: @Flying_Maverick, @DevelopAzure
Blog: TheFlyingMaverick.com LinkedIn: LinkedIn.com/in/calloncampbell
Website: ReflectInsight.com

3. Using Pull Requests
Pull Requests are living conversations that streamline the process of discussing,
reviewing, and managing changes to code
Each Pull Request takes into account not only what you would like pulled, but
also where you intend those changes to be applied. From there, your team can
discuss the changes as a whole, individual parts, or even specific lines. Later commits
addressing concerns or ideas appear as part of the conversation.
Pull Request = Code + Issue + Code Comments

4. Collaborative Development
Collaboration is an essential part of the GitHub workflow. After creating a branch and
making one or more commits, a Pull Request starts the conversation around the
proposed changes
At any time anyone can provide feedback on the proposed changes. This feedback can
take in account coding style, best practices, performance, etc
Additional commits are commonly added to the pull request based on feedback
before merging to the branch

5. Initiate Discussion
Pull Requests initiate discussion about your commits. Because they're tightly
integrated with the underlying Git repository, anyone can see exactly what changes
would be merged if they accept your request.
You can open a Pull Request at any point during the development process: when you
have little or no code but want to share some screenshots or general ideas, when
you're stuck and need help or advice, or when you're ready for someone to review
your work.
By using GitHub's @mention system in your Pull Request message, you can ask for
feedback from specific people or teams, whether they're across the room or working
remotely.

6. Discuss and Review Your Code
Once a Pull Request has been opened, the person or team reviewing your changes
may have questions or comments. Perhaps the coding style doesn't match project
guidelines, the change is missing unit tests, or maybe everything looks great and
props are in order. Pull Requests are designed to encourage and capture this type of
conversation.
You can also continue to push to your branch in light of discussion and feedback
about your commits. If someone comments that you forgot to do something or if
there is a bug in the code, you can fix it in your branch and push up the change.
GitHub will show your new commits and any additional feedback you may receive in
the unified Pull Request view.

7. Topic Branches
A “topic” branch is a separate branch that you use when working on a single “topic”
(a bug fix, a new feature, or an experimental idea). Working on a topic branch instead
of directly on top of “master” is recommended because:
- work on multiple, separate topics simultaneously
- can be easily updated
- feedback and related changed are group together
- easier to refactor a patch
Topic branches are meant to be short lived. Once done and their merged into the
parent or you want to discard your changes…just delete the topic branch – both
locally and on the remote.

8. Topic Branch Workflow
CI
B
B CI CI
CI CI RI
CI RI
Pull request
Pull request
CI CI CI CI
Topic branches
R
R
Symbo
l
Name
B Branch
CI Checkin
R Rebase
RI Reverse Integration

9. Advanced Topic Branch Workflow
If your topic branch is long lived then you can use “git rebase” to keep it up to
date.

10. Rebase
There is no merge, so your patches are guaranteed to apply without merge conflicts.
If there are any merge conflicts you will have already resolved them when you ran “git
rebase”
This appropriately shifts the burden of resolving merge conflicts away from the
central integrator onto the contributor; in this way the project can scale to have many
contributors without the integrator becoming a bottleneck

11. Merge vs Rebase
With a merge, you create a new merge commit.
With rebase there is no merge, so you don’t create a merge commit

12. Demo
Creating a Topic Branch
1. In Team Explorer pane, go to Branches and right click on the
branch you want to work off and select New Local Branch
From…

13. Creating a Pull Request
Once you’re happy with your commits, you create a pull request to propose and
collaborate on your proposed changes to a repository. These changes are proposed in
a branch, which ensures that the master (parent) branch is kept clean and tidy.
Pull requests let you tell others about the changes you’ve pushed to a repository.
Once a pull request is sent, interested parties can review the set of changes, discuss
potential modifications and even pull follow-up commits if necessary.

14. Setting Guidelines - Pull Request
Templates
GitHub has added support for defining Issue and Pull Request templates for a project,
helping contributors add the right details at the start of a thread…
As a group we can define “our”
template which could look like this:
- Coding guidelines
- Unit Tests
- Performance considerations
- Best practices

15. Demo
Creating a Pull Request
1. On GitHub, navigate to the main page of the repository
2. In the “Branch” menu, choose the branch that contains your
commits
3. To the right of the Branch menu, click New pull request
4. The Compare page will automatically select the base and
compare branches; to change these click Edit
5. On the Compare page, click Create pull request
6. Type a title and description for your pull request
7. Click Create pull request

16. Merging Pull Requests
You can merge pull requests by either retaining all
the commits in a feature branch or by squashing all
commits into a single commit.
When confirming the merge, there are two options
for the merge:
1. Create a merge commit
- All commits from this branch will be added to
the base branch via a merge commit
2. Squash and merge
- The x number of commits from this branch will
be combined into one commit in the base branch

17. Merge Squashing
When you merge a pull request, you can squash all commits into a single commit.
Merge squashing retains all your pull request changes, but omits the individual
commits from the Git history.
When you merge a pull request and squash commits, you gain a more streamlined
history that doesn’t include individual commits.
Individual commits create a detailed log of your feature branch but can be
unnecessary when viewing the history of your base branch.

18. Closing Pull Requests
After a pull request is successfully merged and closed, your branch can safely be
deleted.

19. Reverting a Pull Request
You can revert a pull request after it's been merged to the upstream branch.
Reverting a pull request on GitHub creates a new pull request that contains one
revert of the merge commit from the original merged pull request.

20. Demo
Merging a Pull Request
1. On GitHub, navigate to the main page of the repository

21. Typical Pull Request Workflow
When dealing with pull requests you typically have two
choices:
1. Merge and pray
2. Pull to local branch, build, run tests and merge if all OK
What do you do?
I know what I’d like to do, and GitHub makes it so tempting:
But unfortunately I go with the second option, which is a
pain.

22. Is a better way?
YES

23. TeamCity: Automatically Building Pull
Requests
There is a plugin for TeamCity can automatically build GitHub pull requests and
provide build status notifications.
This works by TeamCity monitoring all branches including pull requests. It will then
checkout the pull request and do a “merge” against the parent branch.
The change status is then reported back to GitHub for the given branch.

24. Pull Request Notification
Pull request notifications makes the code
review process easier by letting the
reviewer know that if this code is merged,
all tests will pass.
Now the reviewer can focus on reviewing
the code and not worry about checking out,
building and running tests.

25. GitHub Branch Status Checks
With branch protection enabled, certain status checks must pass before branches
can be merged.

26. Wrap Up
A Pull Request starts the conversation around the proposed changes
A “topic” branch is a separate branch that you use when working on a single “topic”
(a bug fix, a new feature, or an experimental idea) and is meant for short duration
Use git rebase to keep your branch up to date and with rebase, there is no merge, so
your patches are guaranteed to apply without merge conflicts
When merging a pull request, use squash commits so that you gain a more
streamlined history that doesn’t include individual commits
Finally, leverage TeamCity Pull Request Notification to help you with reviewing and
merging pull requests – knowing that the pull request has been built and all tests
have passed based on the merge

27. Homework - Blog Posts
Add Reactions to Pull Requests, Issues, and Comments
Issue and Pull Request templates
Improved commenting with Markdown
Add Reactions to Pull Requests, Issues, and Comments
More code review tools
Protected Branches Improvements
Squash your commits

28. References
https://help.github.com/articles/using-pull-requests/
https://help.github.com/articles/merging-a-pull-request/
https://help.github.com/articles/about-pull-request-merge-squashing/
https://help.github.com/articles/closing-issues-via-commit-messages/
https://help.github.com/articles/creating-a-pull-request-template-for-your-
repository/
https://github.com/dchelimsky/rspec/wiki/Topic-Branches
https://git-scm.com/docs/git-revert.html

29. Questions