As I use both git and hg, I really miss the feature-branching in hg (obviously, you can, if you try hard enough, use feature branching with hg too, but git makes it so easy that it became my default process whenever I can use git for development, even on solo projects):
Suppose you have a team of 3 or more people and a "central" git server that can be used for facility of share (company server, github, bitbucket, gitorious...): each person start working on a issue (let it be a bug to fix or a new feature to implement) by doing on his working copy
git checkout -b feature-nickname
than it change anything that he consider relevant, committing whenever he decides that a change can be described in a sensible way:
git commit -am 'OptimizingVisitor applies DeMorgan laws'
... a few work after...
git commit -am 'OptimizingVisitor detects constants predicates'
At any time, each developer can push the changes to the central server, to share his progresses and without the pain to merge them until the full issue has been addressed.
The next day, a different developer could continue his work if it's really required (rarely, but it happened).
When the feature has been fully implemented, the dev can merge it into the shared branch (master, or development when a human-driven test process is required before the production deployment).
We do not use rebase: we want to keep track of which code the dev was seeing while writing his changes.
At any time, we can see what features have been released, looking at which branches have been merged in the shared branch.
On medium to large projects (5 to 20 people) this process allows a fast, painless collaboration.
Still, whenever I can use git, I use it for my solo projects too, and I find it quite good to keep track of the progress of the project.
My two cents.
Giacomo