The great thing about git is branching is so cheap it can replace what would be committing under other VCSes. Developing a new feature necessarily involves stages where the code is unsuitable for release, if you're doing it right - you should have tests or, better, language support that will prevent you from releasing something nonfunctional, and the feature will go through nonfunctional stages (even accepting that you can and should implement it as piecemeal as possible). You should of course be merging as often as possible, as often as you can deploy - which might be hourly or better, if you have a good continuous deployment setup - but it's still valuable to be able to make commits at a finer granularity than that. So you use branches for that grouping (and I think 1 branch = 1 "feature" = 1 deployment is a good model), and commits for finer-grained history.
