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%
- 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
Break you description into 3 logical sections:
Past (have), present (need), and future (get).
Describe what exists.
Demonstrate empathy for the code, team, and constraints that created it.
Don't shit on the past.
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.
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.
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.
Once a review starts, useless messages like
shit... start piling in.
--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
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 🙌