Git repositories should be named after the domain name of the project. If that's not possible, get as close as you reasonably can. The best name for www.masusushi.com repository is probably masusushi.
The master branch should always contain production-ready code. It should be ready to deploy to the server at any time. If someone else wants to deploy, all they should need to do is run it through a preprocessor that supports Compass (like CodeKit).
If we have a staging server in use, also use a dev branch which corresponds to that server. If we just have a staging server that will sort of become the actual server, don't worry about it. In that case, just using master is a-ok.
When you deploy, tag that commit. If you're deploying to production, deploy from the master branch. If you're deploying to staging, deploy from dev branch. When you merge to master (and dev), you should deploy right away. A very good time to tag and deploy an active project is at the end of the day, when tagging it something like 2013-07-18 helps make it obvious that you pushed your code then.
Branch when starting work on any finite task. If it's a feature, name it descriptively, like adding-blog-index-page. Keep things as small and granular as possible, so rolling back or seeing where the code is at at any point is easy.
If your branch is working on a bug fix, name it like bug/23 where the number indicates the issue in GitHub it resolves. Your last commit on that branch should include a comment like "Fixes #23" which will link it to that issue and close it.
Keep your branches pushed to GitHub, as this helps others see what you're working on. This also makes it easier to use pull requests to show your code to others and ask questions. You can always pull in changes from master if your feature/fix is taking a long time.
Use Pull Requests frequently to discuss your work. Feel free to start this early. It doesn't always mean you want to merge a branch, it can just mean that you want help, ideas, or feedback. Pull requests are a good way to keep an eye on how far your branch is diverging from the master (or dev) branches.
Keep notes that might be helpful in the future in a README file. Markdown format is great. Probably the top-level folder is fine. On larger projects, we might want to make use of the wiki feature in GitHub for this.
A folder in the theme like /backup is a good place to keep particularly useful assets that ought to be in the project, such as source files, templates, style guides, and so forth. At major checkpoints--perhaps when tagging or finishing a bunch of work--save a copy of the database in there as well.
- http://scottchacon.com/2011/08/31/github-flow.html
- https://help.github.com/articles/using-pull-requests (internally, we use the Fork & Pull Model here)
- http://www.lynda.com/Git-tutorials/Git-Essential-Training/100222-2.html good video training