Description of the git workflow and a branch per feature, extracted from: http://railsapps.github.com/tutorial-rails-prelaunch-signup.html
When you are using git for version control, you can commit every time you save a file, even for the tiniest typo fixes. If only you will ever see your git commits, no one will care. But if you are working on a team, either commercially or as part of an open source project, you will drive your fellow programmers crazy if they try to follow your work and see such “granular” commits. Instead, get in the habit of creating a git branch each time you begin work to implement a feature. When your new feature is complete, merge the branch and “squash” the commits so your comrades see just one commit for the entire feature.
Create a new git branch for this feature:
The command creates a new branch named “new-feature” and switches to it, analogous to copying all your files to a new directory and moving to work in the new directory (though that is not really what happens with git).
Commit changes to branch e.g.
Once the new feature is complete, merge the working branch to “master” and squash the commits so you have just one commit for the entire feature:
You can delete the working branch when you’re done: