I think the growing consensus on using a dvcs is that you should work on easily separated chunks of functionality in their own branch. Commit whenever you feel

I think the growing consensus on using a dvcs is that you should work on easily separated chunks of functionality in their own branch. Commit whenever you feel like it throughout the lifecycle of working on that feature, then go back and squash all those random commits into a few easy to understand chunks, and then merge that back into master. For example, I'm working on a simple landing page and form. Some logical points for doing a commit may be something like: 1 basic responsive layout complete for mobile 2 progress on desktop responsive layout (going home) 3 completed desktop responsive layout 4 wired up forms 5 added validation to forms 6 cleaned up duplicate css 7 adjusted css for other, crappy, browsers 8 bug fixes 9 fixed a typo 10 bug fixes & final layout issues Now I'm done and I want to merge that to master. But what I want the commit history to look like is a group of logical steps, excluding things that will be meaningless/useless to other people when they look back at the project history. So I would squash 2 and 3, 4 and 5, and probably 6 thru 10 so that I ended up with 4 total commits 1, 2/3, 4/5, 6/7/8/9/10 that get put onto master. So, you definitely want to try to remember to commit over the course of a feature, but the actual times you commit are a little bit less important because you should clean up your history before you move it to master. In general I try to commit discrete pieces of functionality (like a working form, or a working layout, or a tested class/method).