I always wonder that how those top engineers write the best commits meanwhile Le me who just commit "update" after doing tons of stuff 😂
until I realized that a commit message should be satisfy :
"If someone reads this commit, will they understand the change WITHOUT opening code?"
That's it .
Congrats, you understand what is good commit message !
but when to commit ?
most people like me after doing random changes commit msg "final changes" , however the real rule is :
"if you can clearly explain what you have changed till now and it is a small change then commit otherwise don't"
Example :
- you have added feature of file validation instead of waiting to finish whole project then commit. Just commit on that step with "add file validation"
PS : Hope, this make sense . I learned this the hard way, but you are lucky to know it easily 😁
Top comments (1)
Excellent! Knowing is only half the battle though. Check out my
commitbash function which automatically fills in commit message parts like type (feat, fix, chore, docs), feature name, and ticket number. Reducing the lift on the mechanical parts of writing the message has freed up energy for me to write a better description.