December 6, 2018

Developers, what's your commit message style?

I often write somewhat descriptive commit messages even when there's no other collaborators.

Here are some of them:

  • didn't consider the exception of empty list when querying stats

  • the consumed status missing a filter

  • added store_id in reward tbl for easier query; and stat api returns real data

  • added id converter

  • added sms notification fucntion

I was wondering what's your commit message style? Do you mind share a few?

  1. 6

    “Changed shit”

    “Fixed that thing that was fucked”



    “Fucking fuck fuck fuck”

    1. 1

      Lmao exactly this. When it’s a major commit I try to be descriptive but always eventually reverts to “stuff” and “more stuff”

    2. 1

      LOL between you, me, and indiehackers community, I do this too.

      But I always end up rebasing them into one commit.

      Actually, I'm quite surprised it took this long for someone to reply these types of commit messages.

  2. 5

    I was taught to always commit in present tense and keep it short, commit in chunks instead of 10 files at once.

    "Refactor conditional with switch statements"

  3. 3

    I usually start with an action like "Add" or "Delete"

    Instead of the past I use the imperative, so that when I merge I know what I am about to do

    Really love that ref ;

    1. 1

      Thanks for the link.

      Btw, I just realized I always used past tense while seems most others use present tense of the "action word".

      To me, when I'm writing commit message, it's usually after I finished some work; so I think using past tense is more intuitive to me.

      Is it common practice to use present tense?

  4. 2
    • I usually start with an action word - add, remove, fix etc. and a

    • Keep it short

    • Use , or ; to separate multiple changes if there is more than one

  5. 2

    I use a combination of Git Commit Message StyleGuide and gitmoji which both use emoji. While adding emoji to your commit message might first seem cutesy, it has the added benefit of being easy to grok what types of changes were were made with the commit or feature. It works great with teams too.

    1. 2

      You and @Tiby both mentioned gitmoji! I've been meaning to do that.

      I think the "cutesy" thing would be fine with developers; it's not like the code will be taken into court for evidence or something; it's written and read by we developers anyway.

      1. 2

        I also do not think that "cutesy" is bad 😀

        It's fun to use that style with an organization for a while and then see them slowly adopt their own emoji-style commits. Some ask, but more times then not, they will create their own emoji commit styles.

  6. 2

    I start with an emoji following this guide and next I add short description about file or feature impacted

    1. 1

      Have been meaning to try out gitmoji!

      @jeff above also mentioned it. :D

  7. 2

    I usually write the commit messages as they would be for other team members - even on solo projects.

  8. 2


  9. 2

    "just read the code. there's not much"

  10. 2

    My commit messages at work are entirely different from hobby projects.

    • Work: "Adds XYZ feature" along with a detailed description in bullet points as to why the changes were made. Always includes a link to ticket/task-ID.

    • Hobby project: "Complete: abc; WIP: xyz; TODO: 123"

    I like my hobby project commit messages that way because when I return after a few days, I know what I am supposed to continue with.

  11. 2

    Create github issue, make its title outcome based, add details. Once work is done to address the issue - copy title of the issue into your commit.

    1. 1

      Wow, from this workflow, I wonder do you work in a big team?

      1. 1

        Just 2 ppl but we are remote with 10 hour time zone delta. So this approach helps

        1. 1

          10-hour time zone difference, pretty much morning vs night shift. Better leave really detailed messages for each other. :p

    1. 1

      I had this exact same idea! Did you build this?

  12. 2

    The best advice on commit messages I ever heard was to let the code speak to WHAT was done and use commit messages to tell the WHY.

    This reinforces writing expressive code (no code comments is a general rule for me as well, btw) and gives a clear distinct purpose to the commit messages.


    The best developers I know also follow their best practices even when working alone. Mostly for two reasons: 1.) It's good practice for skills that are important when working with teams, and 2.) It's surprising how often you are the other developer who doesn't understand what was done two months ago in some code that you originally committed ;)

    1. 1

      Interesting concept "let the code speak to WHAT was done and use commit messages to tell the WHY".

      I might try to practice that.

  13. 1

    git commit -m'update'

    is used a little more frequently than I probably should!

  14. 1

    This comment was deleted 2 months ago.