Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to write a Git commit message

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.

Stefan M.

March 19, 2020
Tweet

More Decks by Stefan M.

Other Decks in Technology

Transcript

  1. How to write a Git commit message

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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.

    View full-size slide

  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

    View full-size slide

  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’

    View full-size slide

  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

    View full-size slide

  12. Single vs Multi line commit messages

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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?

    View full-size slide

  18. Discussion round

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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!

    View full-size slide

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

    View full-size slide

  23. How do you commit?

    View full-size slide

  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

    View full-size slide