Git: Best Practices

This is a guide for writing code with Git, while maintaining efficient and effective repositories.

Ignores

Don't check in files to Git that are specific to your development environment, tools or processes.
Try not to add .gitignore lines for lots of individual files, especially when they're specific to your environment only. Try to add patterns instead.
If you see environment-specific files that have been checked in, let the person who added them know, so they can tidy it up.

Keep master production-ready.
The main branch must always production-ready, always tidy, always fully-functioning, always ready for customers, always reflecting that which is live on the production site.
Pushing to master must be treated as 'deploying code', rather than a part of any kind of staging/development process.
Perform all work in a feature branch.
This makes sure that master stays clean & tidy. Feature branches can be branched off of feature branches, so that team members can work in different sections of features. This has the benefit of minimizing any chance of merge commits. Which we'll cover in the next section.
git checkout master
git pull origin master
git checkout -b <branch-name>
Rebase for upstream changes.
This will prevent merge commits, merge conflicts, and a messy commit history. Be sure nobody else is working on the branch before rebasing, so that you don't break anybody else's history.

Minimize merge commits.
Merge commits occur when Git takes the progress of two commit histories and combines them into one history. These commits are unreadable, and unactionable. Other commits are readable and understandable.
To minimize the chance of merge commits, make sure your branch is always up to date and rebase for upstream changes frequently (check the rebasing section below for more on this).
Provide clear commit messages.
Whenever appropriate, use git commit instead of git commit -m <message>, to open up an editor for more thorough commit messages. Commit messages should be structured like this:
Git commit title message (50 chars or less)
Description of the problem this commit solves. (Wrap at ~72 chars)
Description of the changes made to solve this problem.
Remove merged branches.
Remove feature branches after they've been successfully merged. Remember to delete locally and remotely.
git branch -D branchname to remove your local version,
git push origin :branchname to remove the remote version.
Squash tidy commits. Commits such as "Fix typo" should be merged together, or merged into the commit the typo was made (in this example). Squashing takes place in the rebase interface (e.g. git rebase -i HEAD~5), and merging into previous commits takes place with amends (git commit --amend).
Be careful when altering history. You've seen Dr. Who, right?

Use Pull Requests.
Use GitHub's pull request functionality to get code reviewed by peers.
Discuss committed code.
Use our discussing code doc for more on this.
Commit changes to the same branch.
Any changes required during review should be committed into the same branch, either by the original author or the reviewer. Be sure to test everything as thoroughly as if it was your own.
Merge when ready.
When everything's good to go, go ahead and merge it right in, then delete the feature branches like we mentioned above. Only the code author should merge - reviewers should comment with their approval for merging, but never merge on behalf of the code author.

Create a 'release' after each new feature.
- If the new feature is minor addition to an existing feature, make a 'patch' release. e.g. 1.0.0 => 1.0.1.
- If the new feature is a totally new feature, make a 'minor' release. e.g. 1.0.0 => 1.1.0.
- If the new feature is a non-backwards-compatible overhaul, make a 'major' release. e.g. 1.0.0 => 2.0.0.
Don't modify releases.
When a release is out, it's out. Don't modify or alter the history of code that belongs to a 'release'. Instead, patch the release as appropriate, e.g. 2.0.1.