Git koans
Git Koans don’t really exist. I can’t be arsed to make it, though. There are some anecdotes called Git Koans, but as far as I can tell there is nothing similar to Clojure/Ruby Koans where you get hands-on experience fixing things incrementally, from tiny mistakes all the way up the ladder.
Basically: “Here’s broken shit. Fix it.” “Yay, you fixed it. Here’s more broken shit. Fix it.” Turn on continuous integration and use post-commit hooks as the koan runner. Eventually, you fix all the problems in the broken repo.
It actually wouldn’t be very hard. You can pretty much use any kind of make system to build a repo then fuck it up per order. The result would be hands-on experience fixing fuckups in git, from small to huge. Hell: a joker shell script that takes all the commands used to evolve a repo, and randomly inserts typos and wrong commands to fuck it up (Maybe just swap the entered command with one which is often accidentally typed instead). “Here’s a fork of Foo that’s been utterly fucked. Walk through its history and unfuck it.”
You could also do local/remote fuckups pretty easily too. Have a shell script that purposely messes up upstream/downstream relations, purposely screws up a merge, etc. Nightmare mode: multiple remotes are created, each randomly screwed up to simulate others trying, unsuccessfully, to fix their own messed up repos.
As far as I can tell, this doesn’t exist. The only time you’re ever fixing a fuckup is in actual goddamn repos during your job. The only time you will ever unfuck an arbitrarily broken repo is when your ass depends on it.
This means that for most people, git is a cargo cult. You don’t know how to unfuck things, you’re doing shit like cp -R repo repo.old. Imagine if you wrote code this way: the only time you ever fix bugs is in production code. The only time you ever fix a bug is when your ass is on the line. You’d also do cargo cult bullshit. You’d be that happy asshole sloppily commenting out lines of code to see what’s wrong. In $Lang the Hard Way style tutorials, it’s heavily emphasized that you should break stuff in order to learn what happens, and how to fix it when you do inevitably do it by accident. Yet, I would put money on the bet that the vast majority of git users have never purposely broken a repo in order to learn how to fix it. How many purposely messed up a commit or 3 in order to get hands-on experience with git reflog? How many intentionally committed to the wrong branch so they could learn how to stash pop. How many purposely introduced a painful merge conflict in order to learn the right (painless) way to resolve it? Purposely broke the build in order to learn how to use bisect?
In code, it’s unthinkable that you would have no experience of fixing bugs outside of “we need this fixed yesterday” situations. Yet with git, that’s the case. No experience, at all, of unfucking repos that you don’t depend on for rent or whatever. The average git user has no idea how to fix mistakes they make, and every mistake they do have to fix is only ever on a real repo.
Look at Oh Shit Git. It lists very common mistakes, in plain English, and explains how to fix them. I guarantee that the vast majority of git users have never purposely made those mistakes in order to see how to fix them. For many, the first time they have to fix a mistake, that mistake is new to them and they end up on ohshitgit or stackoverflow typing commands that may as well be mystic incantations.