Pull Requests Good Practices

Transcript

1. Tips for Good Practices Awesome Pull Requests Jose Ignacio Honrado @Joosee
2. Understanding pull requests Collaborative code review Purposes / benefits: Bug-catching Code awareness Code uniformity Quality increase Learning
3. Pull requests tips
4. All code must be reviewed Don’t push directly to master All new code MUST be reviewed by your colleagues Even though you think the change is trivial… Shit happens! Everyone needs to be aware of new code
5. PR description Explain briefly what you did if it’s not trivial A link to the issue is not enough If testing isn’t trivial, explain what you did to test the implementation
6. Pull request commits (1) Add several commits per pull request This is what will make the difference in terms of ease of review If the PR is well separated in commits, the size of the PR can be greater
7. Pull request commits (2) Commits should: introduce just one thing guarantee consistency (compile and work) NOT change code introduced in previous commits in the same PR (use rebase + amend) add the tests along with the implementation classes NOT mix style changes or renames with actual code
8. Commit messages (1) Commit title. A general explanation of the commit. Don’t end it with “.”. Max 72 cars. The convention is to use “present-tense imperative-style”, like if they were commands: “<verb> <rest-of-commit-title>” “Add retry system to the consumer” “Fix bug #3242” instead of “Fixed bug #3242” Commit description. Optional. Just when the title is not enough. Separate with an empty line from the title. Max 80 chars.
9. Commit messages (2) Don’t use titles like “Some fixes”, “Applied PR feedback”, etc…
10. Pull request size More size, more time to be reviewed => Delays More size, less focus => More bugs or defects
12. Pull request reviewing When commenting: Distinguish between required changes and possible improvements Give examples of what you mean or even provide sample code At least two approvals required (just one if trivial)
13. Pull request TTL A PR should be reviewed as fast as possible This will: speed up the development process reduce conflicts between PRs favour continuous delivery
14. Applying PR feedback Let your reviewers know that you performed the changes and where to find them by responding with messages like: Fixed in d17c2d1 Improved in d17c2d1
15. ¿Questions?