The game is potentially doing more harm than good.

git gud is a game that teaches you a real-world software development application: Git, which is a version control system (VCS). The software keeps track of the working history of text files in a project, which sounds simple at first if you’re working alone, but can become extremely complicated when working on a large-scale project involving lots of people: you have to deal with concurrent file edits, editing files from different versions, etc.

This complication is commonly found in software development, and that’s where Git emerged. Specifically, Git is software developed by the Linux headquarters; thus, the Unix philosophy applies:

1. Write programs that do one thing and do it well.
2. Write programs to work together.
3. Write programs to handle text streams, because that is a universal interface.

This is where the game falls short: it doesn’t cooperate with this philosophy at all.

The first thing is that the game hijacks the command-line interface (CLI) from your computer’s operating system to make the game (unlike traditional games, which run on game engines, e.g., Unity, GameMaker, Ren’Py, etc.). This is not a bad thing in itself—on the contrary, done right and it could be a great game. However, the way the game works now is that it just wraps the CLI with its own altered version of a shell, which includes a modified version of Git (with lesser and restricted set of commands.) The wrapped CLI also lacks quality-of-life tools such as autocomplete, pipelines, standard file editors (vi, nano), etc.

Lacking autocomplete alone is more than enough reason to give this game a thumbs down. You see, even veteran software developers who spend their entire lives wrestling with CLIs hate typing unnecessarily long commands. Why type every character when you can just type a few initials and press tab to complete it? This isn’t just about saving keystrokes, it also helps prevent unintended typos. Furthermore, it offloads our brains from having to remember exact filenames deep in directory structures, allowing us to focus on more important aspects.

And why even type the full command at all when you can alias a long one into a much shorter one? For example, the de facto standard command to list every file in a directory alongside their information (permissions, user, size, date modified, etc) is:

ls -l --all --classify --color=auto

But we can just type ll — double stroke of your right ring.

Git itself also comes with the ability to alias (without relying on the shell). For example, you can configure it via:

git config alias.st "status --short --branch"

Then you can just type git st instead of git status. This is even shown in the official guide.

But you cannot use this feature in the game…

Heck, that’s a huge loss. No autocomplete is one thing (older nix systems didn’t ship with it), but the lack of *alias? That just makes people hate using the command line, instead of promoting the fun of it.

It also misses an opportunity to sneak in fun facts about the history of VCS as a whole, in particular, the alias ci for “commit”. On first glance, why shorten it to “see-eye” at all when the full command is only one word (unlike co for “check out”)? Turns out, prior VCSs such as RCS/CVS used the term “check in” for this task. The successors renamed this command to “commit” but still kept the original abbreviation.

Furthermore, Git wasn’t meant to be used as a standalone tool, which aligns with the Unix philosophy. When you run git log, it should pipeline the entire development history into a program called less, allowing you to scroll and search. Or running just git commit without arguments should bring up a text editor to let you fill in a multiline commit message, which is good practice for large collaborative projects.

It seems like the root cause of this unenjoyable experience stems from the CLI wrapper the game introduces, which takes away vital commands and interactions between programs.

On the other hand, selectively filtering available commands is a reasonable security concern. You wouldn’t want players to follow a walkthrough that includes malicious commands, like:

dd if=/dev/zero of=/dev/sda bs=512 count=1

Please please PLEASE, DO NOT run the above command. I got pranked once— not by a stranger on the internet, but by a close friend actually —two decades ago, and my entire PC data was wiped out with no way to recover it. (That’s why we nicknamed the dd command as DataDestroyer™.)

This makes me strongly against the idea of doing clever things via OS-level programs to simulate a game. That’s a risky path to take. Also, if you really want a true Git experience, then go to GitHub, clone a project, and start developing with others. That’s a far more effective way to learn Git than relying on this game.

I think it’s a lot safer to use game engines. Also, many games still manage to simulate a good CLI / software developing experience. Take a look at Hackernet Evolution (2010), where autocomplete is functional; MHRD (2017), which features a “fake” boot screen that immerses you in a nostalgia programming world; or TIS-100 (2015), which was designed with a fictional programming language (instead of using a real-world tool) and still makes it fun and challenge and you actually learn some real-world programming skills!

Apart from the bad UI/UX, its Git lessons aren’t much better:

• It still uses master as the default branch, despite Git officially changing this to main in 2020.
• It clings to obsolete Git practices. For example, to unstage files, it uses git reset --, which is a dangerous command—you might accidentally use it with --soft or --hard, leading to data loss. (Now, official Git recommends git restore --staged instead.)
• It teaches “a single command to add all files and commit right away”, even though in real-world development, we use git add --patch to selectively add only the necessary lines, skipping debug code. We also review staged changes before committing, not just blindingly commit it right away.
• It doesn’t teach how to read the diff insightfully. Instead of comparing multi-line files with small changes, it compares two one-line files—so you can’t really see what changed.
• It doesn’t get serious about resolving merge conflicts—it only allows two options: take all incoming changes or discard them all. In reality, we often need to blend changes together.

Don’t get misled by its cheap price tag. You wouldn’t want to buy and drink poison, right?

(update: 2025/07/31)

Autocomplete was added around 1½ months after the initial release. Although it’s still far from ideal… a single tab after an incomplete command fills the blank space with the first match, instead of listing all available commands like a proper shell. For example,

git c<tab>

immediately returns

git checkout

instead of showing a list of all commands starting with c: checkout, commit, config, clone, etc. (Also, pressing tab multiple times doesn’t cycle through the list of suggestions.)

Originally published on: Steam

neizod

author