Title Text

Git Etiquette

How to make your reviewers happy

and your code better?


Change Log

πŸ“– Semantic Commits

  • Should reflect the scope, type & intention of the change
  • If trying to cover too much, might be worth splitting it into atomic commits (next...)


Title [max ~50 chars]

πŸ“– Semantic Commits

  • Explain further details if needed (what, why, how)
  • Reference to sources
    • External: Articles, StackOverflow,
    • Internal: Github issues/PRs

Message Body [optional]

βš›οΈ Atomic Commits

  • Cover one and only one thing
  • Commit frequently, even when...
    • Code is draft, not perfect nor complete
    • Tests are failing
    • You are fixing/refactoring a previous commit
    • (more on Refactoring & TDD later)
  • Reflect you mental model & problem solving process


βš›οΈ Atomic Commits

  • Tell a story!
  • Communication for your PR reviewer(s)
  • Self-doc for team / future-self (6mo)
  • Dig history & debug regressions


Pull Requests

πŸŽ‹Branch Naming

πŸ“„ PR Template

Description Message

Concise descriptive message that serves as a summary of the branch. This helps identify the content of the Pull Request at a glance

  • What / Why?
  • How
  • Checklist / Steps
  • Demo (code snippet, GIF, Video, you name it!)
  • DevOps notes (migrations, env vars, ...)

βš–οΈ Good Balance

From Reviewer's PoV

  • Semantic & atomic change log
  • Explain yourself, but no need for a Bible description
  • Include demos & instructions
  • Keep it digestible & understandable
    • Tip: After submit, make self-Review!
  • Avoid building a Cathedral

🧐 Peer Review

  • Be thoughtful
  • Win-win chance: Learn & mentor!
  • Comment but don't block
    • Tip: use a linter/styleguides instead
  • Request changes when strictly necessary
  • Ask questions instead of pointing for errors
    • Ex. This is wrong, we should always use a RegExp here!
    • Vs. Do you think a RegExp would improve performance?


Better & Faster

πŸ‘©β€πŸ’» Better Programmer

  • Planning before throwing LoC's
  • Problem solving skills
  • Use common sense
  • Small steps: Practice Refactoring
  • Clear Specs: Practice TDD (Test-driven development)

🎳 Better Team

  • Constructive discussion
  • Sync & async collaboration
  • Beat Ideas (code), not individuals
  • Reach common knowledge & understanding
  • High-level design & architecture
  • Avoid:
    • Analysis paralysis
    • Getting stalled (one draft away)
    • Inherent Biases
    • Impostor syndrome

πŸ’» Better Software Products

  • MVP: Quick iteration & learning feedback loop
  • Expose to end-users: Ship early, ship often
  • Better quality, less bugs into Production



By Benjamin Orozco (benoror)



  • 1,011