Love your pull_requests


Published on

How to handle Pull Requests and things to consider when reviewing / issuing pull requests.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Love your pull_requests

  1. 1. Love your Pull Request (PRs) Nasir Jamal @_nasj We are hiring
  2. 2. What this talk is not about! 1 Git Commands / process flow 2 Technical issues around PR issue / merging
  3. 3. Before issuing PRs Take a break and go through your code once again to keep things clean and tidy or any obvious refactoring you 1 need As Uncle Bob says: *keep the ground cleaner than you found it
  4. 4. Before issuing PRs (cont..) Do not issue a PR unless you think your story is fully complete, i.e. specs, integration/cucumber tests 2 - Otherwise you are just wasting other peoples time - Dont be sloppy
  5. 5. Before issuing PR (cont..) Keep your PRs small Max 200 - 400 LOCs 3 If possible 50-100 LOCs or less - easy to review, spot errors, minimal comments, etc
  6. 6. After issuing PRs Do not merge until all the comments have been addressed 1 - if you have comments from more than one person then make sure they all have been taken care off
  7. 7. After issuing PRs (cont..) Keep your ego away, comments are 2 feedback about your code learn a trick or two
  8. 8. After issuing PRs (cont..) Seek to understand reviewers 3 perspective
  9. 9. When reviewing PRs Go at an easy pace because faster is not better 1 - if you dont have time, dont review it otherwise you will either end up pissing off the dev with your comments or you will miss obvious errors
  10. 10. When reviewing PRs (cont..) Look for code maintainability and 2 robustness
  11. 11. When reviewing PRs (cont..) Avoid sarcasm or making demands instead suggest - when suggest, give an example 3 - ask the dev what he thinks about it or if he has any objections because you dont know what was going on his mind when he wrote it
  12. 12. When reviewing PRs (cont..) Remember you are giving a feedback 4 or clarifying things that you are not sure
  13. 13. When reviewing PRs (cont..) Your purpose is to find defects and issues but never show that someone is 5 inferior or you are … - if you really want to do it, do it in private - and most probably you will have your arse kicked
  14. 14. When reviewing PRs (cont..) Communicate your ideas clearly 6 - Find ways to make code better
  15. 15. When reviewing PRs (cont..) Be humble, explicit and if required talk in person, clarify and discuss 7 - to the point & precise without sugarcoating - be careful with icons or with your WTFs (do not offend another person)
  16. 16. When cant agree Know when to continue and stop the 1 debate and accept one or the other point of view
  17. 17. When cant agree (cont..) 2 If required take the discussion offline and make a decision quickly
  18. 18. When cant agree (cont..) If you cant decide bring in some 3 mediation and just go with the majority unless you can convert the majority
  19. 19. Things to remember 1 there is no best solution, just better 2 Issuer: Be thankful for the reviewer for taking the time out
  20. 20. Things to remember (cont..) 3 Use it as a means of learning, growing, communication, team building and keeping the code sane and bug free Issuer/Reviewer: Dont take anything 4 personally, the comments are about the code and not about you