DEV Community

Cover image for I spent years mastering Git, then Lazygit made me faster in a week.
<devtips/>
<devtips/>

Posted on

I spent years mastering Git, then Lazygit made me faster in a week.

#webdev #github #programming #git

Why the “real devs use raw Git” mindset is quietly holding us back

I didn’t want to like Lazygit.
That’s probably the most honest way to start this.

I’ve spent years doing things “the right way.” Raw Git. Terminal only. Custom aliases. Half-remembered rebase flags burned into muscle memory. The whole identity package. You know the vibe: if it’s not painful, are you even learning?

Then lazygit showed up in my terminal feed again. Daily.dev. A couple GitHub stars screenshots. Some dev casually saying “yeah, I just use lazygit now.”
And my first reaction was basically: sure, but I’m not a beginner.

Which is funny, because that exact mindset is how we keep normalizing friction as skill.

Here’s the uncomfortable part: Git didn’t suddenly get worse. I didn’t forget how it works. But my workflow did get heavier. More branches. More rebases. More reviews. More “wait, what state is this repo in right now?” moments. And somewhere along the way, Git stopped feeling powerful and started feeling… tense.

Lazygit didn’t replace my Git knowledge.
It didn’t make decisions for me.
It just removed the constant low-grade anxiety of doing everything blind.

TL;DR:
This isn’t a “lazygit is magic” post. It’s about how visibility beats memorization, why fear-driven Git workflows slow us down, and what tools like lazygit say about where developer tooling is heading.

Git didn’t get harder our workflows did

Git didn’t suddenly wake up one morning and decide to ruin your day.

If anything, Git has been remarkably consistent. Commits are still commits. Branches still point to hashes. Rebase is still rebase, no matter how spicy the flags look. The core ideas haven’t changed much since most of us first learned them painfully from docs, blog posts, or that one coworker who seemed way too calm during merge conflicts.

What did change is everything around Git.

We ship more often. We branch more casually. We rebase instead of merge because teams want clean history. We review more code, across more repos, with more people touching the same files. Even solo projects aren’t simple anymore. One app quietly turns into an API, a worker, a frontend, and a migration folder you’re scared to open.

None of that makes Git harder in theory.
It makes Git heavier in practice.

The real tax isn’t typing commands. It’s context switching. It’s remembering what state your repo is in before you even decide which command to run. It’s staring at git status output like it’s trying to gaslight you. It’s knowing that git reflog can save you, but also knowing you’d rather not need it today.

I remember when Git felt like a cheat code. Version control without zip files? Infinite undo? Unreal. Somewhere along the way, it became something you respect, not something you enjoy. You stop experimenting. You hesitate. You double-check commands you’ve run a hundred times.

That hesitation isn’t discipline.
It’s friction.

And once you notice that most of your Git stress comes from lack of visibility not lack of knowledge you start wondering why we still treat “doing it blind” as a virtue.

Git didn’t get worse. Our workflows got denser and the tooling didn’t evolve to match how we actually work.

What lazygit actually does (and what it doesn’t)

Let’s get one thing straight before this turns into a holy war.

Lazygit is not a shortcut that hides Git from you.
It’s not doing anything “behind your back.”
And it definitely isn’t replacing Git knowledge with vibes.

Under the hood, it’s still just Git. Same commands. Same rules. Same ways to mess things up if you’re reckless. Lazygit doesn’t invent new behavior it exposes existing behavior in a way your brain can process faster.

That distinction matters.

The first thing you notice is visibility. Files. Hunks. Commits. Branches. All right there. You’re not asking Git questions one command at a time anymore. You’re looking at the state of the repo and making decisions from that picture. Stage this line. Not that one. Switch branches without losing your place. See exactly what a rebase is about to touch before you hit enter and pray.

And suddenly, concepts you already “knew” actually click.

Staging stops being this abstract, ceremonial step and starts feeling like what it always was: selecting intent. Rebases stop feeling like irreversible surgery and start feeling like controlled edits with an undo path you can actually see. Conflicts become less of a jump scare and more of a puzzle.

That was the weird part for me. I didn’t learn new Git concepts. I understood old ones better.

What lazygit doesn’t do is think for you. It won’t save you from bad branch strategy. It won’t magically fix messy commits. It won’t teach you Git fundamentals if you skipped them entirely. You still need to know why you’re rebasing instead of merging. You still need judgment.

The difference is that judgment happens with feedback instead of fear.

If raw Git is like debugging with print statements, lazygit is opening a debugger. Same program. Same logic. Less guessing.

Lazygit doesn’t remove Git complexity. It removes the mental overhead of navigating it blind.

The real change: git without fear

This was the part I didn’t expect.

Lazygit didn’t just make Git faster. It made it calmer.

Before, a lot of my Git behavior was driven by low-level anxiety. Rebases were postponed. Branch cleanups waited. Experimental commits stayed local longer than they should have. Not because I didn’t know what to do but because fixing a mistake felt expensive, even when I knew it wasn’t.

That changes when you can actually see what’s happening.

When the branch graph is right there. When the commit you’re about to rewrite is highlighted. When the undo path is obvious. Git stops feeling like a trust fall and starts feeling like a controlled system.

It’s like game save systems. Manual saves make you cautious. Autosave doesn’t make the game easier it makes you braver. You explore more because the penalty for failure is visible and manageable.

That’s what happened to my Git workflow. I rebased earlier. I cleaned up commits without the internal debate. I experimented more, because I wasn’t mentally mapping out disaster recovery every time.

The commands didn’t change.
My behavior did.

Lazygit doesn’t remove risk from Git. It removes the fear that keeps you from using Git properly.

Where lazygit shines and where it absolutely doesn’t

Lazygit isn’t a silver bullet. And pretending it is would immediately kill its credibility.

Where it really shines is anywhere humans are in the loop. Solo projects. Indie apps. Side hustles. Teams that care about clean history but don’t want every Git operation to feel like a ritual. If you’re constantly switching branches, staging selectively, rebasing to keep things readable, lazygit pays for itself fast.

It’s especially good for review-heavy workflows. When you’re bouncing between feature branches, fixes, and “wait, why is this commit here?” moments, having everything visible reduces mental friction in ways aliases never quite do.

But there are real limits.

Lazygit is not how I’d teach Git from zero. If someone doesn’t understand what a commit is, a visual tool can mask fundamentals instead of reinforcing them. And in highly automated or heavily customized enterprise workflows think scripts, hooks, or very opinionated branching strategies raw Git still wins by default.

There’s also a quiet truth most seniors won’t say out loud: plenty of experienced devs use visual tools… they just don’t advertise it. We act like suffering is proof of mastery, even though the same people will happily use an IDE, a debugger, or autocomplete without guilt.

So the real question isn’t whether lazygit is “cheating.”
It’s whether mastery means memorization or leverage.

Lazygit works best when judgment matters. It fails when understanding is missing or automation takes over.

This isn’t about lazygit it’s about where dev tools are heading

Once you zoom out a bit, lazygit stops looking like a special case.

It fits a pattern.

Look at the tools a lot of us quietly adopted over the last few years: fzf for fuzzy finding, ripgrep instead of grep, bat instead of cat, zoxide instead of memorizing paths. None of these tools made us worse engineers. They reduced friction in places where our brains were doing pointless work.

Lazygit is doing the same thing for version control.

For a long time, dev culture equated difficulty with depth. If something was awkward, verbose, or hostile, it must be powerful. And yes, there’s truth there abstraction can hide important details. But there’s a difference between abstraction and visibility. Modern tools aren’t hiding systems. They’re surfacing them better.

That’s why this doesn’t feel like GitHub Desktop, or a big IDE panel trying to be everything at once. Lazygit stays close to the metal. It just gives you a HUD.

Think about how game interfaces evolved. Early games dumped raw numbers on the screen. Modern games still expose complex systems they just present them in a way that supports flow instead of interrupting it. You still need skill. You’re just not fighting the interface at the same time.

The same shift is happening in dev tooling. Less ceremony. Less memorization. More feedback. More confidence. Tools that assume you’re competent, but human.

So no, this isn’t really about lazygit.
It’s about the quiet realization that productivity isn’t about proving toughness it’s about staying in motion.

And the tools that win tend to respect that.

Easier tools don’t make you a worse developer

There’s a strange guilt that creeps in after you’ve been doing this for a while.

Using “easy” tools can feel like cheating. Like you’re supposed to earn your stripes forever terminal-only, no shortcuts, pain as proof of competence.

But that logic doesn’t hold up anywhere else.

We don’t write assembly for daily work. We don’t avoid debuggers, IDEs, or autocomplete just to prove a point. We use leverage constantly. Git is one of the last places where suffering still gets mistaken for mastery.

Lazygit didn’t make me forget Git. It made it easier to apply what I already knew without friction getting in the way. And that’s the difference. Understanding isn’t about memorization. It’s about clarity and judgment.

Git is still Git. Knowing it deeply still matters. Better tools don’t replace that knowledge they reward it.

If dev tooling keeps moving toward opinionated, transparent interfaces that respect flow, that’s not a downgrade. It’s progress.

Helpful resources

Top comments (0)