If this is about tips around engineering productivity, why is it called the Git Haters Guide?
I have a fervent belief that Git is a fantastic system wrapped in a tool written by people that hate their users on a deep and personal basis. It’s really the only explanation that makes any sense to me. As I learned Git eventually I got used to it, and I noticed that this was a common pattern – people really have an unpleasant time with Git until the Stockholm Syndrome kicks in, then they are OK with it.
I wrote a Git Haters Guide before the Stockholm Syndrome properly took hold of me, mostly to tease my coworkers when they asked me to write up what I’d done to configure it. I am not a Git expert by any means, but I have figured out some useful things that seemed worth sharing – about Git and about a lot of other things. But we’ll start with Git. And for the title of the Git Haters Guide? Honestly , just because that still makes me laugh.
The Wonder and Joy of Life With Git
Git hates you. Git is really looking forward to destroying your code. Git is hoping you’ll let it destroy other people’s code in the process. You HAVE to keep that in mind when you work with Git. Just thinking you can use Git to casually check in code will result in you spending the rest of your day trying to figure out what happened and how to fix it. And it’s quite possible that you won’t be able to.
I can’t stress this enough. My mental model of using Git has become that of lion taming. You stand there with your chair and your whip and you pay careful attention to everything. The moment you relax, the lion jumps on you and destroys you.
The internet has many horror stories about Git. The one that stuck with me is the guy that found the command on stack overflow of “git push –mirror”. Seem innocuous, it just pushes up code, right? But it just about wiped out his central repository and did so irrevocably. There’s nothing in the command to make you THINK it’ll do something like that – but it turns out that command will wipe any branches on the central repository that you don’t have. And it does it gleefully and permanently. So … the lesson? Googling for what to do is frequently the only way to work with Git, but check what you find carefully and think about it before you take any advice. And think about where you will restore your code from if Git destroys your repository when you run the command.
Usability
Git and usability is summarized nicely with a core concept, “origin”. To me, since I wrote the code, the origin is me. To Git, the origin is the source repository – so if you write some code and push it, then the final destination of your code is “origin”. I’d say that therefore this is a TERRIBLE choice of terminology – avoiding ambivalence like this is about the very first step in usability. So let this be the first lesson – Git has not taken that very first step into usability. Get used to that.
So this first entry doesn’t help much, I’m aware. But this explains why I’m going to call this the Git Hater’s Guide, plus it was fun to write. After this – things I’ve done to make Git less terrible and all the other things I’ve learned and done that have made my life easier.