I'm not sure what you mean by "we maintain extra repositories on a staging server for deployment". What exactly are you doing, why is that necessary, and what

I'm not sure what you mean by "we maintain extra repositories on a staging server for deployment". What exactly are you doing, why is that necessary, and what extra steps does it involve? The "extra steps" (the index, remote branches, etc.) are there for a reason, and that reason is to give you the tools to be careful with your codebase. I always use `git fetch`, for example, because unless I've been doing something reeeeally weird, `git fetch` will never touch my local work. At all. The index allows me to make sure I know exactly what I'm committing, and the extra step gives me the chance to look over it once again before I commit. (`git add -p` and `git commit -v` help a ton here, even though it feels like they "slow things down"). I never have "Oops, I didn't mean to commit that" moments anymore. And the merging model (yes, with those opaque commit-hashes and mutable history and 3 kinds of branches) allows me to fix things when I screw up (or one of my coworkers does). Which still happens all the time, because we're human. I think you could get a lot more out of git if you were willing to invest the time to learn more about its branching model (which really is elegant once you understand it), and to configure it properly. Otherwise, you may have a look at Mercurial, which has a more svn-like experience.