ProposedWorkflow

What it is

Basically, don't commit to master. At least not without a good reason.

It's not a hard and fast answer, but generally unless it's something like a oneline tweak to a Rakefile, it probably belongs in a branch. Partially so that you don't break master while you're playing, and partially to give it a convenient vehicle for code review before it hits master.

How it works

git checkout -b features/some_feature

# hack hack hack

git commit -m "did some work on feature"
git push -u origin features/some_feature

Once this is done, you'll have committed a new branch to the origin, github. If you know what you're doing with git and have the knowhow to clean up if it goes bad, rebase it onto master as well.

At this point, open a pull request for master and give it a few days to let people have a look over it. If a particular person is skilled in that area or has domain knowledge, mention them by @username in a comment to grab their attention.

Why it works

Collaboration is awesome.

Github lets us discuss the patch as a whole, and also add inline comments to the diff. This avoids creating broken code, and also gives us a good audit trail for 5 months in when we're finding comments like

/* Here there be dragons, don't bump $i */

Which without context are meaningless.