#Create Small Pull Requests

When creating your pull requests it is important to keep them small. This makes it easier for the reviewer to understand the changes and provide feedback. It also makes it easier for you to make changes if needed. If you have a large change that you want to make, consider breaking it up into smaller changes that can be reviewed and merged independently.

Small pull requests can also increase confidence in the changes being made. If a pull request is too large, it can be difficult to understand the full impact of the changes and to ensure that they are correct. By breaking the changes up into smaller pull requests, you can more easily verify that the changes are correct and that they do not introduce any unintended side effects.

This makes it easier for the reviewer to go through your pull request. The easier your pull request is to understand the quicker your pull request is likely to be approved and merged.

Some people are intimidated by reviewing large pull requests as the confidence level in the change is smaller.

People are also busy working on their own tasks and may not have the time to review a large pull request.

You can use a technique called daisy-chaining to break up a large pull request into smaller pull requests. This involves creating a series of pull requests that build on each other. Each pull request should be small and focused on a specific change. This makes it easier to review and merge the changes. When using Github it will automatically change the base branch of the next pull request to the branch of the previous pull request.

When creating pull requests make them easy to be reviewed.

#Use Descriptive Titles

When creating a pull request, it is important to use a descriptive title that clearly explains what the pull request is about. This makes it easier for the reviewer to understand the changes being made and to provide feedback.

A good title should be concise and descriptive. It should clearly explain what the pull request is about and what changes are being made.

If you work in a team with a external ticketing system like Jira it's common practice to include the ticket number in the title. This makes it easier to track the changes being made and to link them back to the original ticket. This is handy for the reviewer to understand the context of the changes being made.

#Create A Pull Request Checklist

Each team will have different requirements on how they want pull requests to be constructed, when joining a new team I like to create a pull request checklist to ensure I have covered all the requirements.

As I learn new things about the project I will check this checklist up to date and refer back to it when creating a new pull request.

This checklist can be a private note to myself or you can turn it into a Github pull request template that can be used by the team.

#Review Your Own Pull Request

Github has a great feature where you can create a draft pull request. This allows you to create a pull request that is not ready to be merged yet. This is a great way to get feedback on your changes before they are ready to be merged.

When creating a draft pull request, you can request feedback from specific people or teams. This allows you to get feedback from the people who are most familiar with the code you are changing.

I also use this feature to review my own pull request before I bring in others to review it. This allows me to check for small errors like typos or missing variables that I may have missed.