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.
When working locally commit when:
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.
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.
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.
