How to Pull Request

In this article we explain, how to Pull Request.

1. Keep them small

  When you prepare the changes in code try only change or add what is necessary without send additional files not related to the major change.

  If you believe that some fragment of application needs refactoring, please do it separately. Don’t try to invent excuses for why it’s easier just to shove it all into a single PR – that’s being lazy.

  Try always inventing ways to make smaller PRs – that’s being creative.

2. Before create PR do Self-Review

  Create a draft PR and do a full review yourself – complete with comments and tasks.

  You can also use this “self-review” to point things out to your reviewers – “I’m not sure about this name? Can you think of a better one?”, “Should this really be nullable??”.

  In other words, this process of self-review makes you a better developer.

3. Go back and remove noise

  Try to avoid changes in other files related to the:

  • white space changes,
  • formatting changes,
  • optimized imports,

and other text change that has no impact related to the intention of the PR.

  If formatting is important, create a separate PR, introduce a linter, make it a part of your CI, and format the entire app in one big nasty PR.
But keep noise away from the important changes – respect your reviewers’ time and energy.

4. Create a meaningful title

  Please try to name the pull request as the ticket from the Jira eg. IN-4000 Verification fixes during the tests the application.

  Pull Requests are the new Documentation, making Pull Request history easy to browse makes searching for past decisions and thought processes much easier.

5. Write a helpful description

  Start thinking about description in the pull request as the basic documentation that you would actually read because it is useful.

  Add few words about your intention and making process.

  This is very important to add some information about how to:

Test/demonstrate. This is handy for QA – user/pwd combinations that you might want to use in the staging environment, configuration/preparation/setup instructions… anything that will help the reviewer test the changes.

Attachments: Screenshots, Videos. A picture is worth a thousand words, a video is worth a million. There’s no substitute for seeing the changes in action – creating proof of completion is also a handy artifact to have when Demo day comes and you have forgotten to prepare!