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 ● 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! 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 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
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?
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?!
stefma
miyake
yumayabe
line_developers
mii3king
.jpg){kind=avatar}
hiro_torii
yoyoyopg
soracom
optim
hosimesi11
asei
alexanderbyndyu
rponte
notwaldorf
dougneiner
garrettdimon
revolveconf
gr2m
jakevdp
brad_frost
destraynor
reverentgeek
tanoku
geoffreycrofte
searls