When I'm working on a project, I tend to write a lot of code. A lot of code means alot of bugs. If I commit my work early on , I have to edit that commit when I encounter a bug and fix it. This is why I have started to commit at the end of the work on the component I'm working on. This means I could do changes without the head-ache of correcting previous commit.

However, This means I have another head-ache. That is breaking down my work into smaller parts to commit them separately.

  • 2
    possible duplicate of git / other VCS - how often to commit?
    – gnat
    Commented Jun 21, 2016 at 8:56
  • 1
    @gnat No, that isn't a duplicate because I have asked in my question about whether I should commit while still working or commit at the end. The link you posted asks whether one should keep the commit size small or big. Thanks.
    – SloppyJoe
    Commented Jun 21, 2016 at 8:59
  • 6
    A good rule of thumb is: Commit when it gives you value. Personally, I commit frequently because it helps me experiment and rollback code to known working states. You may chose to commit for another reason valuable to yourself.
    – MetaFight
    Commented Jun 21, 2016 at 9:10
  • 8
    Just commit a lot of temporary garbage "Work In Progress" comments into a local branch you'll throw away, and then when you finish implementing whatever you work it on, create a squashed commit in the parent branch with a neat commit message. With Git you can do it both ways. And in a thousand other ways on top of that... Commented Jun 21, 2016 at 9:17
  • 2
    Do not be ashamed of your errors. We all make them. Commented Jun 21, 2016 at 10:58

3 Answers 3


When working locally commit when:

  • You add a new test case.
  • Your tests pass.
  • You've made any change that works, no matter how insignificant.
    • Renamed a variable? Commit it.
    • Extracted a method? Commit it.
    • Inverted a condition? Commit it.
  • Basically, anytime the code compiles.

Then, prior to pushing it to a shared repository, squash the commits into a single, working change.

The benefits here are that you have a full history of every change you made while working on whatever feature/bug fix you're working on. If you find yourself 3/4 done and realize you need to go back to where you were 1/4 along the way, that's fine because you can. Squashing before you share the code guarantees that each commit in the shared repository represents working code. Anyone could checkout any given commit and still have working code. It's nice to have a clean history when SHTF and someone needs to revert.

  • Excellent answer. I would add in a brief aside about feature branches to make it a home run.
    – Paul
    Commented Jun 21, 2016 at 11:31

One principle of Git is commit early, commit often.

You want to commit whenever you made any tangible progress you are not sure you would regret losing suddenly.

If you feel that this results in your git history to end up with too many meaningless commits with vague commit messages, you can squash these commits into one before you push them to the main branch using git rebase.

  • Yep! Normally what I do is commit every time I take a break, and then later massage the commits into something meaningful/legible with git rebase. The time spent reworking the commit serves as a kind of code-review, too!
    – jpaugh
    Commented Jun 21, 2016 at 20:42

This is why I have started to commit at the end of the work on the component I'm working on. This means I could do changes without the head-ache of correcting previous commit.

In my opinion, this can be a big mistake if you are working in a team. It's a particularly big mistake when one works part time on task A, part time on task B, part time on task C, etc. (my life), while the rest of the team is blazing away. You're likely to get conflicts galore on trying to merge your work into the overall project if you wait a few weeks or longer to ensure your code works perfectly. (Aside: Your code is never perfect.)

It's much better to commit locally extremely often and merge the larger work into your branch somewhat frequently. On a fast-moving project, I commit several times a day and merge once per day, minimum. Frequent merges mean that you can go talk to the person who wrote the code that broke your code and perhaps come to an agreement. Infrequent merges mean that those changes that broke your code are most likely locked in stone.

My first commit with regard to some task is typically pseudo code that compiles (the pseudo code is almost all comments) but that fails every test. When I leave project A to work on project B, I'll commit and merge. When I come back to project A, the first thing I do is to pull the development branch into my local repo and then merge that into my feature branch. As a result I rarely see conflicts.

A lot of code means a lot of bugs.

That's not necessarily true. What is true is that a lot of untested, unreviewed, and sloppily written code means a lot of bugs. That might be okay if what you're writing is code where errors don't have much of a cost (but that also means it doesn't have much value). If you're writing software where errors can cost millions of dollars or even worse can kill, you simply do not want to do that. There are techniques, some old, some very new, that let one write code that is mostly error-free.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.