chantastic1. Start your message with a verb
Spelunking git history is always a chore.
You can make that chore easier with clear, strong messages.
Start with the verb.
Keep it short.
Fix e2e login spec
Add inactive person styling
Remove presence validation from age on Person model
Decrease TTI on dashboard by 10%
2. Write messages in an imperative style
- Fixed nav jitter
+ Fix nav jitter
- Added CTAButton
+ Add CTAButton
Read 'Should I use past or present tense in git commits message' on stack overflow
3. Use have/need/get to describe your PR
Break you description into 3 logical sections:
Past (have), present (need), and future (get).
Have
Describe what exists.
Demonstrate empathy for the code, team, and constraints that created it.
Don't shit on the past.
Need
Describe the human need.
This is the value that customers get.
Don't jump into technical details yet.
You can probably copy/pasting this from Trello/Jira.
Get
You can't always get what you want
Mick Jagger's right.
Describe your solution in technical terms.
Admit where it falls short.
Point out areas where you don't have enough information to make a better solution.
Bonus: Reference
Link supporting pages, documents, and verbal instructions that helped form your solution.
Give credit to co-workers that helped you.
This gives reviewers insight into your process and improves your credibility.
4. Use the --fixup flag to commit fixes
Once a review starts, useless messages like fix, oops, shit... start piling in.
Use the --fixup flag to make these commits more descriptive.
git commit --fixup a1b2c4
Github has a Confirm squash and merge option that will squash all fixup! commits into the commits they reference.
Read Auto-squashing Git Commits on thoughtbot's blog
5. Check your ego
Remember that you're making a "pull request" — not a "pull demand".
A pull request is the start of a conversation.
Don't assume you got everything right.
Be open to feedback.
You'll probably learn something you didn't know.
Have fun 🥳
Let me know what you learn 🙌
