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!
