Write an Ideal Pull Request with Github

Guideline to help you to serve your code best when collaborating on pull requests

Write Pull Request with Github

As a software engineer in a company, you will collaborate with other engineers to create a perfect application. Of the many collaborations between engineers, there is one that every engineer does very often. Do you know that?

Yes, that’s right, pull requests. Pull requests help you tell other people about your code, whatever you did to change the application. When you change and complete a feature, indeed, you must inform stakeholders directly involved in the application must be told. Pull requests help you create a small discussion forum for every big or small code change in an application so that a good collaboration dynamic appears in it.

A culture to make the right decisions

Pull requests can be made anywhere and anytime by any engineer. Pull requests are not only popular on Github; they can be found on Gitlab, Bitbucket, Azure, and other collaboration apps. Good collaboration occurs when a pull request gets good comments from fellow engineers. Don’t forget to get approval to be released at a particular stage.

But the reality is not that easy; many of us as engineers still can’t figure out how to create an ideal pull request. There is still a lack of description of each pull request. It could even be that there are too many forums within a single pull request. Incidents like this make the application can’t be released because it doesn’t get the right decision from all engineers.

The ideal pull requests

With my experience as an engineer, I will give you tips and tricks to create the ideal pull request with Github so you will have no trouble collaborating with other engineers.

Pull new master environment before creating pull requests.
Doing this will keep you up to date with the latest code from every engineer who collaborates on the app. Every function, class, helper function, or it could be the newest documentation listed by another engineer so that you can continue to be better. There is less chance of conflict when you make a pull request, so you are ready to move on to the next stage.

Clear description
A pull request on Github looks better if it has the following sections:

1. Title: give the best title for the code changes you make; it doesn’t have to belong but is understood by other engineers
2. Link to the Ticket: if you use JIRA, Trello, or any other program management application, we recommend that you include it in your pull requests so that others can find detailed information about your changes
3. Description: include a summary of what you achieved from the changes to the application
4. Another link to related pull requests: if necessary, add some documentation links such as TRD, API Contract, or link pull requests in the previous environment
5. Don’t forget to include Reviewers, Assignees, and Labels on Github to show who you asked for a review and changes made by whom and what labels determine the category of this pull request

Small pull requests
A small pull request is easier to review and faster. It’s also easier to combine because there’s less conflict between codes. Also, it reduces the occurrence of rejections when a pull request is forwarded to someone else because there are too many changes to trace.

Add “Why” if you don’t understand
When you are a reviewer or someone who makes a pull request, you have to get information about what was changed from the application. The interaction between your code and code from others will limit the application. My advice: if you don’t understand or don’t understand, give lots of “Why” questions. For example like this:

- Why is this necessary?
- Why is it here?
- Why did you pick this approach?

You can ask any question to form a small forum from this pull request. If you ask too many questions and don’t get a definite explanation, the application will be released late because there are too many distractions in the forum.

As a pull request, provide very descriptive information as in the previous phase so that your collaboration is ideal.

Communicate between the creator and reviewer
It takes time to review the pull requests that have been made — correcting code errors, adding missing use cases, or changing specific flows. I recommend that a review be done within a maximum of 25 minutes. Above that means that the pull request made is too large and makes a reviewer less focused and unproductive. A good collaboration is when you, as a pull request maker and reviewer, respond to each other well for changes to your application.

Give thanks to all reviewers
Appreciate any information that all reviewers have provided. Appreciate and communicate the pull requests so that teamwork will form from this kind of communication! Code changes are temporary — relationships with teammates are what matters.

Little thing I can say, this way, you have built your team’s performance for the better because it has reduced the time wasted just reviewing a pull request. I hope you get good and positive things through the tips and tricks I have conveyed. Ciao!