Why I Built Git Dojo Instead of Another Git GUI
- Git Dojo teaches git through real terminal commands instead of button clicks
- Three commands trip up almost everyone: rebase, cherry-pick, and reset
- A GUI can hide the exact mental model you need once things go wrong
- Building a teaching tool meant relearning git from first principles myself
Why a GUI Never Actually Teaches You Git
I used a git GUI for years before I admitted it was holding me back. It made commits look safe. It made branching look like drag and drop. Then one day I hit a merge conflict on a real project, the GUI showed me three panes of colored text, and I had no idea what to do because I had never once typed the words "git merge" myself. I had learned the buttons, not the tool.
That gap is the whole reason Git Dojo exists. Most people do not fail at git because the commands are hard. They fail because they learned a shortcut around the commands, and shortcuts do not transfer when the shortcut is not there. A button that says "sync" hides whether that is a fetch, a pull, a merge, or a rebase happening underneath. When something breaks, and something always eventually breaks, you are left guessing at a system you never actually touched.
I see the same pattern with people who are strong developers everywhere else. They can reason about a distributed system, they can debug a race condition, and they still open a GUI just to move a branch pointer because git commands feel like a foreign language they never got fluent in. That is not a skill gap. That is a practice gap. Nobody gets fluent in a language by watching someone else speak it through a translated interface. You get fluent by using it, badly at first, until it stops feeling foreign.
Git Dojo is built on that idea directly. It runs you through real git commands in a real terminal context, one exercise at a time, so the thing you practice is the thing you will actually use under pressure later. There is no simplified version of git happening behind the scenes. When you type a command in Git Dojo, you are typing the same command you would type in production, against the same rules git has always followed. The only difference is the stakes are zero, so you can get it wrong ten times before you ever need to get it right once.
That distinction between practicing the real thing and practicing a simplified stand-in for the real thing is, in my opinion, the single biggest reason so many git tutorials fail to stick. A tutorial that shows you a diagram of branches is teaching you to recognize a diagram. A tool that makes you actually create the branch, break it, and fix it is teaching you git. I wanted to build the second kind, because it is the kind that was missing when I needed it most.
Building Git Dojo: Teaching Through the Terminal, Not Around It
Once I decided the terminal itself had to be the classroom, the design constraints mostly wrote themselves, the same kind of constraints I ran into when I wrote about structuring a monorepo for multiple products: the structure has to match the real thing, not a simplified stand-in for it. Every exercise needed a real, isolated git repository under the hood, not a fake one that only pretends to respond to commands. If a lesson tells you to stage a file and commit it, the underlying repo has to actually gain that commit, with a real hash, a real log entry, and a real state you can inspect afterward with plain git commands if you want to double check your own work.
That constraint mattered more than I expected while building it. It meant I could not fake a single lesson. Every exercise had to be tested by actually running the commands a learner would run, watching what git actually does, and writing the lesson around that real behavior rather than around what I assumed git would do. More than once I caught myself explaining a git behavior slightly wrong in a draft lesson because I was working from memory instead of from the terminal. Building a teaching tool for git turned out to be one of the fastest ways to find the gaps in my own understanding of git.
The other constraint was pacing. Git has a lot of surface area, and dumping all of it on someone in exercise one is a fast way to make them close the tab. So Git Dojo starts with the commands people actually use daily, status, add, commit, log, and only opens the door to branching and history rewriting once those first reflexes are solid. Difficulty scales the way a real skill should scale, not the way a reference manual is organized alphabetically.
I also made a deliberate choice to keep the tool itself out of the way. No accounts to create before you can try it, no walls between you and the first exercise. If the entire pitch of Git Dojo is "learn by doing the real thing," then the tool has to get out of your way as fast as possible so the doing can start. Every extra step between opening the page and typing your first real git command is a step working against the actual goal. It is the same philosophy behind my pick of the best terminal tools for developers: the terminal wins when it stays out of the way and lets the real tool do the work.
The Commands That Actually Trip People Up
Across every conversation I have had with developers about where their git understanding breaks down, three commands come up again and again: rebase, cherry-pick, and reset. Not because they are obscure. Because they are the three commands where the mental model of git as a simple save-and-sync tool stops working, and the real mental model, a graph of commits you are actively rearranging, has to take over.
Rebase is the big one. Most people learn merge first, because merge is forgiving. It takes two histories and stitches them together without asking you to understand much about what a commit actually is. Rebase asks more of you. It takes commits and replays them one at a time onto a new base, which means you have to understand that a commit is not a fixed, permanent object, it is closer to a recorded change that can be reapplied elsewhere. The first time someone hits a rebase conflict, they are usually staring at the same three-pane view a merge conflict would show them, except now they also have to know whether to continue, skip, or abort, and each of those does something different to history.
Cherry-pick trips people up for a related reason. It looks like copy and paste for commits, and mechanically it kind of is, but it forces you to confront the fact that a commit is tied to a specific parent context. Pick the same commit into a very different history and you can end up resolving a conflict against code that looks nothing like what the original commit was written against. Understanding why that happens requires the same graph-based mental model rebase requires.
Reset is the quiet troublemaker. It is one command with three very different levels of consequence depending on a single flag, and the difference between them is the difference between safely uncommitting a change and permanently discarding work. Git Dojo spends real exercise time just on the gap between soft, mixed, and hard reset, because that single flag has probably caused more panicked searches than any other part of git.
None of these three are actually complicated once the underlying model clicks. They are complicated when you only ever interact with them through a GUI button labeled with a friendlier word, because the button never explains which of the three behaviors it is actually invoking on your behalf.
What Shipping a Teaching Tool Taught Me About My Own Workflow
I did not expect building a git teaching tool to change how I personally use git, but it did. Writing exercises that explain rebase clearly enough for a beginner meant I had to be able to explain it clearly enough to myself first, out loud, without hand waving. That is a much higher bar than "I use it correctly most of the time," and hitting that bar exposed a few habits I had picked up on autopilot without fully understanding why they worked.
The clearest example was interactive rebase. I had used it for years to clean up commit history before opening a pull request, mostly by trial and error, undoing and retrying until the log looked right. Writing a lesson that had to explain, step by step, why squashing two commits produces a specific new hash, and why editing an earlier commit message rewrites every commit after it, forced me to actually trace through what git is doing instead of relying on pattern matching from experience. I came out the other side using interactive rebase more deliberately and, honestly, more confidently, because guessing had turned into understanding.
That is the part of running a one-person studio that keeps surprising me. Building a product that teaches something forces a kind of accountability that using the thing yourself never quite does. You can get away with a fuzzy mental model as long as you are only answering to your own results. You cannot get away with it when the exercise has to be right for someone who has never seen a terminal prompt before. Every lesson in Git Dojo is, in a small way, the result of me being forced to stop approximating and start actually knowing, the same lesson I wrote about after fixing terminal flickering in Claude Code taught me about respecting the tools I use every day instead of just tolerating their rough edges.
It also reshaped how I think about teaching tools generally, for every product decision after this one. The instinct to simplify, to hide the real mechanism behind a friendlier layer, is almost always well meant and almost always the wrong call if the goal is real understanding rather than surface familiarity. Friendlier is not the same as clearer. Sometimes the clearest thing you can do for someone is hand them the real tool, in a safe enough context that getting it wrong costs nothing, and let them build the muscle memory that actually transfers.
Bottom Line
Git Dojo exists because I kept watching capable developers avoid git commands they had every ability to learn, simply because they had never practiced the real thing in a setting where mistakes were free. A GUI that hides the mechanism does not remove the need to understand the mechanism, it just delays the moment you find out you never learned it, usually during a conflict that actually matters.
Building the tool taught me as much as I hope it teaches anyone who uses it. Writing lessons for rebase, cherry-pick, and reset meant relearning all three well enough to explain them without hedging, which is a different and harder bar than just using them correctly most of the time. That is the trade I would make again. A teaching tool only earns its name if building it also teaches the person who built it, and this one did exactly that.
If you have been meaning to get properly comfortable with git instead of just getting by, the terminal is not the obstacle. It is the actual shortcut.
Back to all articles
