git commit frequency

Question

Since i switched to git from svn i started make more commits every time i recompile and my tests pass i commit my work. In the end i end up committing function by function.<

Answer 1

I commit after I add or change functionality and have a successful test. Or when I'm going to be switching from my desktop to laptop and want to pull down the code, I'll commit and push.

Answer 2

It really depends.

What I do is I commit locally often, as it sounds like you're doing, but I only push my changes when I've accrued several influential ones.

This ensures that I save my work, but it also doesn't clutter the repo for other users.

Answer 3

I commit pretty far apart. git isn't meant to "backup" your code, you should be using tarballs or dropbox or something to ensure you don't lose code.

If you don't commit very often you can better tell exactly what should go in what commit and it gives you a smoother history than 50 commits with

"oops", "damn", "forgot that file"

you can rebase, but if you never stage/commit in the first place, theres no need to undo your work

Answer 4

The more you commit the easier it is to find bugs with git bisect

Answer 5

What you are doing sounds about right to me. Any time you have a working setup that you want to be able to go back to if you mess something up is a good time to commit. If you have a nice setup where running regression tests is quick and easy, I could see that being fairly often. For me, I'd be lucky to make one a week.

Answer 6

1- Commits should be frequent; committing code to the remote repository (not just locally) should be done frequently so that the code is backed up just in case it is somehow lost; this happens more frequently than you'd expect so, pushing your changes by end of day is a must to avoid potential rework and to ensure the remote repository is always up to date.

2- Commits should be granular and therefore should not include too many changes to the code base. Commits with too many changes are harder to revert and cannot be used as a reference from a "history" perspective as commit messages would have to be too long in order to cover the full scope.

3- Commits should have a proper title; title should start with a capital letter and should not end in a period. Generally, titles should be short and to the point.

4- Commit descriptions are optional but are nice to have.