So I’m on a Rails project, we use Git for source control, and we have a team policy of good test coverage (validated by a CI server - specifically CruiseControl - running tests and alerting the team on a failed build).

Day to day we do work on feature branches which we later merge to the master branch when that sub-system (ticket) is complete.

My typical workflow is to start work on a ticket, make a number of intermediate commits, then merge back to master. However, my coworker was noting today that the intermediate commits mean that I have commits that could technically break the build - which is not an issue normally, but if we were to use git bisect to find a bug the failing tests could get in the way.

This is contrary to centralized version control systems, where you know every commit will pass tests, because you don’t want to break the build. But in Git the CI server only checks the latest commit.

I said that I saw two, potentially equally legitimate, git workflows:

• The commit is the unit of work, by which you want to commit as often as possible to get those benefits, and you publish those intermediate commits (useful for history and code review!)
• The Subsystem is the unit of work: commit as often as possible, but when you’re ready to publish git rebase -i so you don’t pollute history. (Of course, this only works if it’s just a local branch - doing a rebase -i to a remote branch is a bad idea).

I’d love to hear two cents from the various git gurus around the internets…