6

How much work should a git commit include?

Comments
  • 3
    If you dig functional programming then I like to commit every time I start working with a new function. It's basically a good move if you want clean code
  • 8
    As much as you can easily describe in a commit message.
  • 1
    Depends if its rework lol 😂
  • 2
    Recently I ported a framework from Java to c++. Let's just say I did it all in one commit... no point in struggling to fix errors when half of them are related to the rest of the code not being done. Otherwise, I make a commit either small fixes and polishing or a feature, but never mix. Also don't commit broken code until you fix it.
  • 2
    Commit code that is related to itself. Kind of like how a good paragraph reflects a central point.
    Commit before you refactor.
    Commit after testing the refactor.
    You don't have to commit working code if you just need to bookmark your work, but I personally like to get it functional at least before pushing.
    Don't punch in your commits on a timer. Punch in your commits when you've accomplished something. Doesn't have to be a big accomplishment, doesn't have to be small either.
  • 2
    Depends on the commit for me.
    initial commits are usually huge and bulky, like the first git push of a repository for a service/monolithic component. Then i categories my branches according to 'git flow' for new features/bugs/hotfixes so eventually each commit is related to its own bug/feature branch.

    I try not to do more than 5 different files per commit, but like @waqas-ibrahim said, its really about the description of the change you did in the commit message.
Add Comment