How to write a Git commit message

Given at a company internal thundertalk.

This talk tells you how to write a Git commit message... or better a starter for a discussion about this topic.

Transcript

1. How to write a Git commit message
2. Disclaimer: This topic is very subjective! It depends on your project setup and how you and your team work!
3. General rules • Limit the (subject) line to 50 chars
4. General rules • Limit the (subject) line to 50 chars Create Signaler for easier usage of Signaler pattern Create Signaler for easier usage of Signaler pattern which reduces unexpected error for instance by using a BehaviorSubject instead of a PublishSubject
5. General rules • Limit the (subject) line to 50 chars • Capitalize the (subject) line
6. General rules • Limit the (subject) line to 50 chars • Capitalize the (subject) line Create Signaler create Signaler
7. General rules • Limit the (subject) line to 50 chars • Capitalize the (subject) line • Do not end the (subject) line with a period
8. General rules • Limit the (subject) line to 50 chars • Capitalize the (subject) line • Do not end the (subject) line with a period Create Signaler Create Signaler.
9. General rules • Limit the (subject) line to 50 chars • Capitalize the (subject) line • Do not end the (subject) line with a period • Use the imperative
10. Imperative? Follows git convention Otherwise we should write everything in the past, right? - Merge branch ‘xx’ into master - Revert ‘something’ - Fixed ‘xyz’ - Added ‘something’ - Changed ‘a’ to ‘b’
11. Imperative! Examples - Refactor subsystem X for readability - Update getting started documentation - Remove deprecated methods - Release version 1.0.0 - Fixed bug with Y - Changing behavior of X
12. Single vs Multi line commit messages
13. Single line vs Multi line Fix ride changes observable Fix ride changes observable The ride changes, which are emitted from the Firebase RTD, notify our RideChangeObserver. The observer doesn't had any onError handling for it. Because our observer hadn't implemented any error handling the app crashes if, for instance, we have a poor internet connection. Now I added the error handling in the following way: • Error raise • Catch error and unsubscribe • Subscribe again to get notified over Firebase changes again I decided to fix this in this way because .... Resolves: #123
14. Single line vs Multi line Fix ride changes observable Fix ride changes observable The ride changes, which are emitted from the Firebase RTD, notify our RideChangeObserver. The observer doesn't had any onError handling for it. Because our observer hadn't implemented any error handling the app crashes if, for instance, we have a poor internet connection. Now I added the error handling in the following way: • Error raise • Catch error and unsubscribe • Subscribe again to get notified over Firebase changes again I decided to fix this in this way because .... Resolves: #123 This is the subject line
15. Single vs Multi line commit messages There is not right/correct solution!
16. Questions $ git log $ git log --oneline $ git show [HASH] $ git bisect [start|good|bad|reset] $ git blame path/to/file
17. Questions $ git log $ git log --oneline $ git show [HASH] $ git bisect [start|good|bad|reset] $ git blame path/to/file If not: Does it make sense to use multi line commits?
18. Discussion round
19. Personal preferences • Follow the ‘general rules’ • Use single line commit messages • Multi line isn’t worth the time to investigate in the message
20. Personal preferences • Follow the ‘general rules’ • Use single line commit messages • Multi line isn’t worth the time to investigate in the message BUT! (There is always a but, right?)
21. Personal preferences • Follow the ‘general rules’ • Use single line commit messages • Multi line isn’t worth the time to investigate in the message • Does your team do/allow rebasing in feature branches? ◦ Commit message doesn’t matter. You do a new commit anyways. • Does your team squash the merge? ◦ Maybe multi line messages on the ‘merge’ commit make sense BUT!
22. But! • Depends on your (teams) commit strategy ◦ Often as possible? vs Only once if feature is finished? • Allowing of ‘Apply PR suggestions’ commits ◦ (Personal note: I really hate it!) • Do you allow multiple changes in one commit? ◦ Typo fix is part of a ‘functional implementation’ cause you just found it while doing it • … even more?!
23. How do you commit?
24. Sources https://chris.beams.io/posts/git-commit/ https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/ https://hashnode.com/post/which-commit-message-convention-do-you-use-at-work-ck3e4jbdd00zyo4s1h7mc7e0g