To Pull Request Or Not To Pull Request?

Editor's Notes

• #2: To Pull Request, or Not To Pull Request? [pause] How many folks in the room regularly use PRs? Raise your hands. [comment about how many members of the audience responsed yes] Today I want to share why I feel Pull Requests are super useful, including some reasons you may haven’t considered before. I hope you find at least one new idea to try.
• #3: But while those are the features that most of us know about Pull Requests, thers are lots of other benefits. Pull Requests can help you be a better engineer, a better team member, and a better team.
• #4: So what is a PR? For those folks in the room who haven’t tried Pull Requests before (or Merge Requests if you’re a GitLab er), Pull Requests are a way to review all your changes in once place and collaborate with your team members to review and merge the change. Some highlights: View all commits in one place Compare before and after code changes Comment on specific lines or blocks of code Squash and merge changes
• #5: [continue from previous slide]
• #6: Pull Requests are a great way to collaborate with teammates. It’s an opportunity to learn about the code base if you’re getting started, get feedback to improve the quality of the code from fellow developers. As one of my teammates recently shared “I also like PRs for personal growth, even when your code works - having another dev review sometimes reveals simpler ways you could have written your code or a better solution to the problem.” Pull requests are also great for distributed teams. In this example, Mary is in North Carolina while Jacob is in Colorado.
• #7: Pull Requests are a great way to collaborate with teammates. It’s an opportunity to learn about the code base if you’re getting started, get feedback to improve the quality of the code from fellow developers. As one of my teammates recently shared “I also like PRs for personal growth, even when your code works - having another dev review sometimes reveals simpler ways you could have written your code or a better solution to the problem.” Pull requests are also great for distributed teams. In this example, Mary is in North Carolina while Jacob is in Colorado.
• #8: Pull Requests also support Status Checks, which have a ton of possabilities. A common use case is to integrate CI jobs where are auto triggered when opening a Pull Request or when pushing a commit, providing fast feedback to you about the impacts of your changes. However, there are also lots of interesting use cases. Highlights: Checking License Compliance Deploying a Test Environment Linting for Working Agrrements (ex. I intentionally broke the backwards compatability of DB migrations)
• #9: Pull Requests also support Status Checks, which have a ton of possabilities. A common use case is to integrate CI jobs where are auto triggered when opening a Pull Request or when pushing a commit, providing fast feedback to you about the impacts of your changes. However, there are also lots of interesting use cases. Highlights: Checking License Compliance Deploying a Test Environment Linting for Working Agrrements (ex. I intentionally broke the backwards compatability of DB migrations)
• #10: Pull Requests also support templates which are a great way to remember things that are easy to forget. In this examplep, the Pull Request contains a checklist which the submitter can easily check off to make sure they’ve remembered everything. Highlights: Remembering to add support for multi language support. Remembering to test in multiple browsers. Remembering to add instrumentation for metrics.
• #11: A newer feature, the CODEOWNERS file provies the ability to add recommended or required reviewers to a Pull Request based on which code was changed. For example, code reviewers can be set for all *.js files, files in the /docs/ directory, any many other patterns. This is also a way to remember who is a good person to ask questions about a specific area of the code.
• #12: A newer feature, the CODEOWNERS file provies the ability to add recommended or required reviewers to a Pull Request based on which code was changed. For example, code reviewers can be set for all *.js files, files in the /docs/ directory, any many other patterns. This is also a way to remember who is a good person to ask questions about a specific area of the code.
• #13: Some companies in regulated industries such as financial services and healthcare must comply with industry specific compliance controls. Using Protected Branches with Pull Requests, you can require at least one other person to review a change before merging it. Combined with Code Owners, you can also require certain people to approve changs based on what was changed. While this take a little extra time and effort, it’s much better than a traditional change control process.
• #14: Some companies in regulated industries such as financial services and healthcare must comply with industry specific compliance controls. Using Protected Branches with Pull Requests, you can require at least one other person to review a change before merging it. Combined with Code Owners, you can also require certain people to approve changs based on what was changed. While this take a little extra time and effort, it’s much better than a traditional change control process.
• #15: One of the more interesting things I’ve been in a Pull Request Template is a “how does this PR make you feel question”. The typical response is an animated GIF. This is not only fun but also a great way to understand if the change wasn’t awesome for your teammate. It’s a great prompt to have a conversation with your teammate to understand what could be improved next time.
• #18: Using Pull Requests also makes it possible to automate much of your project management and project status reporting work. No one wants to have to remember to drag cards across a board. Tools like Waffle.io provide the ability to automatically update the staus of Issues based on activity within branches, pull requests, and status checks.
• #19: And while not all of us are working in teams, Pull Requests can even be helpful if you’re working as a team of one. If you have a public repo, you can still ask a Collaborator to review and comment on your Pull Request. Perhaps you can return the favor for another team of 1. Also, I once had a teammate who was the only person working on an iOS app. He would still Pull Request his work, often letting it sit for a half day, and then come back to it with fresh eyes, conducting a Pull Request review before merging.