How to write very bad commit messages?
Warning: satire ahead.
What are commit messages? those are the messages that every developer have to add if he push some code to a code repository. You can find commits messages everywhere - from public open source projects on GitHub to private on premise SVN servers on legacy enterprise software.
Who should need commit messages? The answer is: No one and especially those people:
- Fellow programmers that does code review – because code reviews are bad and if someone is doing those, it is best to let him guess what the code is about.
- Team leaders – they doesn’t do anything, and making them guess about what the code is about is good for them.
- QA – Shouldn’t look at the code at all. Explaining to them about the code can help them find some bugs… not good for any developer.
- Me – because try to guess about what I did in the commit before two months is fun!
If you really really want to attach commit message, you should really write a BAD commit message. How do you do it? quite easy!
Rule #1 – Do not associate any bugs\user story to the commit message!
The commit message should not contain the User story\Bug ID or information on it!
Bad:
#ISSUENUMBER – The user story title
Better:
Some userstory.
Best:
Making it work.
Rule #2 – Do not write anything about the problem
Why should anyone know what this code solves? never give away ANY information!
Bad:
The problem was caused because someFunction did not return false in bad input.
Better:
Bad someFunction.
Best:
Problem.
Rule #3 – Do not write anything about the Fix
If anyone will know how you fixed the issue, They might have some remarks on the way and then you will need to work harder. not good!
Bad:
Insert validation for input. The validation test the input for number and range. On error the function return false and writes error to the log.
Better:
Insert some validating stuff.
Best:
Fixing stuff.
Rule #4 – Do not Atomize
Bigger is better! If you will commit a lot of code at once, you won't need to write a lot of commit messages!
Bad:
Commit often. The commit should be dedicated to only one issue at a time. Even for small issues like documentation or indentation.
Better:
Commit once a day. Make sure that you mixing several issues and user stories!
Best:
Commit only once in every release! Do that three times and You will get a medal.
Rule #5 - Do not tell anyone about side affects
Make the QA guys sweat over it!
Bad:
Can affect all regions related to user administration.
Better:
This is good for user admin.
Best:
Admin fix.
Rule #6 - Fewer words
Bad habit is code commit message that exceed the code change.
Rule #7 - Make it hard to read
Do NOT separate subject from body by one line.
Do NOT make the subject informative as possible.
Do NOT make the subject up to 50 characters.
Do NOT Capitalize the first letter in the subject.
ADD dot in the subject line.
Tools for bad commit messages
Why innovate when you can automate?
- Use: http://whatthecommit.com/
- Use it in the commit!
git commit -am "`curl -s http://whatthecommit.com/index.txt `"‘ - Use it along with push!
git add -A; git commit -m “$(curlhttp://whatthecommit.com/index.txt”; git push –all –f - Make an alias for it!
alias YOLO=‘git add -A; git commit -m “$(curlhttp://whatthecommit.com/index.txt”; git push –all -f’
And after all that, please remember the words of wisdom from xkcd:
Got here via Google search result, shared with my team.
Like. Thank's for sharing.
Thanks! :)