6
edulipe
4y

Soo, how long is "to much time" to think of a commit message?

Comments
  • 3
    "f-it" is a good one.
    non detrministic ones are also good:
    "probably fixed. maybe not"
    when all else fails, you can use this xkcd for ideas:
  • 0
    "ISSUE-ISSUENUMBER fixed performance issues / implemented xy feature"
  • 0
    2.5 seconds haha
  • 1
    There is no "too much". Whatever it takes to write a comprehensible description, is the right time.

    Usually it will take just a few seconds, but sometimes it takes a minute or two.
  • 0
    Write one with the description! I add "did this. Did that. Also did this and that." Title could be as basic as "commit message" 🥴🤭
  • 0
    Depends on the load of work and policy set around it.

    If there is no policy, it can be like a second for stuff like `fixed/add/update x for issue x`

    Some policy require detailed according to fix
    `Add component x for x to support implementation of y. Removed dx to ensure meeting z and blah blah blah`
    Also avoid huge commits, they make you think alot on what to write
  • 1
    I don't know about too much, but enough time is when you can figure out what you did and why, and can clearly convey it to others.
  • 2
    Long enough that it at the very bare minimum includes the issue number, but not too long that if Vim fails to save I’d be super annoyed.

    I like to think of it was writing a message to yourself in the future that you can easily search for. So that’s I treat Git like my personal diary.

    CRAP-1837 Dear Git,

    Why does nobody like me? Also fixed that bug I introduced that broke everything lolz
  • 2
    If it’s taking too long to describe, split the commit into smaller easier-to-describe commits.
  • 3
    Just write what you have done, and why you have done it. Never commit a jira issue number and say fixed. Because some day you're gonna switch to another tool, and gone is your understanding of why something happened.

    Commit something like: "Implemented caching for X, to reduce load in peak-production hours"

    This way other developers (or yourself) can have a look I'm history why stuff has happened
Add Comment