How to write a Git commit message 

Disclaimer: This topic is very subjective! It depends on your project setup and how you and your team work! 

General rules ● Limit the (subject) line to 50 chars 

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 

General rules ● Limit the (subject) line to 50 chars ● Capitalize the (subject) line 

General rules ● Limit the (subject) line to 50 chars ● Capitalize the (subject) line Create Signaler create Signaler 

General rules ● Limit the (subject) line to 50 chars ● Capitalize the (subject) line ● Do not end the (subject) line with a period 

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. 

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 

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’ 

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 

Single vs Multi line commit messages 

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 

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 

Single vs Multi line commit messages There is not right/correct solution! 

Questions $ git log $ git log --oneline $ git show [HASH] $ git bisect [start|good|bad|reset] $ git blame path/to/file 

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? 

Discussion round 

Personal preferences ● Follow the ‘general rules’ ● Use single line commit messages ● Multi line isn’t worth the time to investigate in the message 

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?) 

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! 

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?! 

How do you commit? 

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