I haven't drunk the Kool-Aid, but I do admit it is brightly colored and tasty looking

For a project at work (CIDER) we're using git pretty extensively, with an adapted version of the git-flow model. For all that I'm finding myself becoming a release engineer all over again -- not a career I intended to move back towards, but what can you do? -- I'm really enjoying our development model so far.

Our model is that people do all their work on spot branches, except for ongoing subtle improvements to template toolkit files, which has been happening on a single long-lived branch. When a fix is made the developer makes a pull request. One of the other two of our three core developers -- in practice always me -- does a quick code review, and tests it in our development environment just by doing git checkout --track origin/[branch] (or, in the case of the long-lived branch, git checkout [branch];git pull and running the Web server against the new contents of the directory. When it's tested in the development environment, we just accept the pull request and do a git pull in the production directory.

It's nothing fancy or unusual -- basically git-flow without continuous integration. But over the years of using CVS, RCS, subversion, and perforce, only perforce has given me anything close to as much satisfaction in the release management, and perforce wouldn't work for our current model (where one of our developers is a remote contractor).

Of course I also like using the same environment and tools for work and for dreamwidth, because it takes away the cognitive cost of switching when I come home and decide to work on dreamwidth.