"Committing in git with only some changes added to the staging area still results in an "atomic" revision that may never have existed as a working copy and may not work." -- that is, git (and darcs and bzr unshelve) require that the developer is careful to really test the commits he has, before pushing. Author argues that bzr is better, but there's interesting discussion in comments too.

Tutorial on how to migrate a website into github pages---github requires your website on a special branch, so here's a pointer to some magic that takes a directory, turns it into a special branch, and then "mounts" it as a submodule.

Linus on the meaning of git-fsck output, how to fix it---if necessary---and when *not* to fix it. (Now part of the git documentation.)

Junio on how to maintain topic branches, bug fixes, and a workflow to avoid missing related fixes when merging between branches.

Martin Krafft explains how to do a clean git-svn import, rebase a git history on top of it, and convert patches to branches; with commands you can copy-paste. Plus a short bonus lesson on merging. In a Debian packaging context but still useful elsewhere.

A very detailed walkthrough from Martin Krafft on how to maintain a Debian package in git, tracking a git upstream. Includes discussion of branch usage showing examples for topics and integration, with commands you can run. Also the use of tags. Useful even for non-Debian work! From 2007; some git commands may have changed.

Nice article on how to manage branches that have some changes that need to get merged back to master, and some that don't. These can be release branches or they can be branches targeted at specific customers.

How to use "git rebase" with topic branches and the relative workflows used by leaf-developers versus subsystem maintainers and core integrators. The thoughts of Linus himself.