About six months ago, our team was using Beanstalk to manage all of our Git repositories. We can't say enough good things about Beanstalk (they offer Subversion and Mecurial, too) and what they provided us, but we finally made the switch to GitHub.

GitHub just had more features that would greatly improve our day to day workflow and let's face it, most developers have a GitHub account.

Like I said, GitHub gave us a bunch of great new features that Beanstalk just wasn't providing us. Not because Beanstalk is bad or anything, that's just the truth.++You can have a kickass Git workflow without GitHub, but we feel like GitHub adds a great deal of improvement to it. Another great part of our workflow is how we use Basecamp, and you'll see that below.

Inspired by the GitHub team themselves, on a day to day basis, this is what we do:

Pick a feature, bugfix, or tweak from Basecamp.+Our features are organized in Basecamp todo lists. These lists often translate into a pull request, focused on one particular feature (I'll talk more about pull requests later)
Cut a branch from master with a name similar to the feature.+This is important. Don't call your branch "feature-branch", "new-feature", or "derek-fixes". If you were adding a tweak which made the logo glow when the mouse hovered on it, call your branch something like this: "logo-hover-effect". You get the point.
Do your work on your branch. You own this branch. You can push as many times as you want. We use Semaphore to run our specs each time a commit is pushed to GitHub. It's helpful to know when you break something, so push and forget about running the specs on your local machine. Use the compute power of your continuous integ srver.
Open a pull request (at any time). Pull requests are cheap. Open one. It gives you a diff between master and your branch. You can discuss your code with other people on your team. You'll have a record of when the tests broke and when they passed. If you decide your code sucks, you can close the pull request. No harm done. If your code gets merged to master, you have a great record of it and can reference the pull request later.
Review the pull request. We don't have any formal code reviews (in the form of a big meeting). It's every developer's job to review code and make sure it's at least neat and appears to be functional. We also check to see if there are no tests or something looks out of whack. Two pairs of eyes are ter than o

That's our typical workflow when we work on Tula Software, our own product.

Our workflow on our client projects varies a bit, since we have a small approval stage (instead of pulling into master, we pull into a staging branch).

This workflow seems to be one that could be implemented quickly, and if you've worked on an open source project before, this probably seems familiar to you (with slight variations, of course

If you deploy everyday, this should make perfect sense to you. You want some friction (code reviews), but not too much friction (defined releases) in your day to day.

If you follow something similar, let us know. We'd love to hear from you.