Good practices for git

Commits

Write great commit messages. Your commit messages should start with a short description on one line, capitalized and in the present tense.
Like your software, your commits should be cohesive. Try to keep the contents of a commit related, unless you need to generate/edit a lot of files for a good, specific reason. If you suddenly realize that you want to commit something unrelated to your original uncommited changes, you should probably use git stash to save away unrelated changes before you commit.
Commit early. Commit often. If you wait too long to commit, the scope of your commits may be harder for others to understand, and you will run into merge conflicts more frequently.
Be careful with --patch. It can be very useful, though it also makes it easier to commit portions of your changes that you haven't tested without the rest of your changes.
Avoid committing binary files and large files. Git isn't mean for storing big files, and big files can be hard to remove once they're in your repository.
If you want to undo a pushed commit, use git revert instead of git rebase.
Never store sensitive data in a git repository. If you accidentally do this, check out this article.
Write your readme first.

Pull and merge often. Your commits will be easier to merge and share with others if you keep your working directory and local repository up to date. Likewise, it's easier to merge a feature branch into master when you are regularly merging master into it.
Avoid non-fast-forward changes. git rebase is awesome, but you should avoid using it unless you are modifying unpushed commits or it's absolutely necessary and your team members are informed of the change.
Use a global gitignore. In my opinion, it's best to keep OS-specific and editor-specific files out of your repository's gitignore and in your global gitignore instead. This means your repo's gitignore is focused on the technologies and setup your repo uses, instead of being coupled with the environments of different developers, which often produce unrelated files.

Mention GitHub issues when appropriate. For example, if you fix issue 5 in one commit, you probably want to have a commit message like "Fix #5" or "Actually free memory this time (fix #5)".