The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums Other Is there such a thing as too man git commits?

  • This topic is empty.
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #158320

    I’m working on a REALLY simple project. It’s just a few page site with some custom widgets. That’s it.

    Chalk it up to my anal nature… I have like a million commits. And by a million, I mean 23. But I only created the repo yesterday and I’ve changed literally nothing important. Only trivial stuff like colors, transitions, etc.

    Is there such a thing as too many commits?


    Any state worth saving is a commit. More commits is great. As long as they get finer-grained and have good messages, they’re useful.

    In the middle of a line? no. Nothing important, but you cleaned up some formatting and that’s all you’re doing today? sure. Just finished a function def? absolutely.


    If you’re working with other people, there’s definitely a chance that you can have too many commits that make the history difficult to read. For example:

    * Fix typo 'Dorp' to 'Drop'
    * Fix typo 'fucntion' to 'function'
    * Update marketing copy 'buy now' to 'install now'
    * Update marketing copy to 'Now only $59!' to 'Now only $49!'
    * Fix typo 'featrues' to 'features'

    Now let’s say all of those commits happening on a single page, say, marketing.html. I would much rather see this after you push:

    * Update marketing copy and fix typos

    Locally, you can have as many commits as you want, but it’s much better when working in teams to figure out a great way to squash related commits together. git rebase is super powerful, though can be really intimidating at first:


    Making a branch is like …a branch

    Normally, when you commit, your project history keeps going in a straight line:

    init ----- commit1 ----- commit2 ----- commit3 ...

    Making a new branch is a lot like forking, except you stay on the same repo instead of creating a new one:

    commit3 -
              branchA ----- commitA1 ...

    If you switch back to the master branch, everything is still like you left it (in this case, commit3). You can even keep working on master (or create/work on other branches):

    commit3 ----- commit4 ...
              branchA ----- commitA1 ...

    When you’re done working on whatever you branched for, you can merge it back in. If master has changed in the meantime, you might have to fix things if there are conflicts. If it’s only you, however, you can keep branches task-specific (i.e., don’t work on the same features/files on different branches) and it won’t be an issue.

    I think this is the git talk I’m thinking of. It’s broad, and long, but it explains things nicely. (About 45min in he talks about branching, but I’d recommend watching the whole thing.) I’ll post if I find another one.

Viewing 4 posts - 1 through 4 (of 4 total)
  • The forum ‘Other’ is closed to new topics and replies.