DEV Community: Félix Legrelle

Why Your Next IDE Might Actually Be a Git Client

Félix Legrelle — Fri, 06 Nov 2026 14:03:00 +0000

A few weeks ago I wrote about why I left GitKraken and built Gitoryx. That post was about the tool I left behind. This one is about something I noticed while building the replacement: the more I used Gitoryx day to day, the less I opened my IDE for anything other than editing code.

That's not a small shift. For years, the IDE was the center of gravity. Everything else, the terminal, the Git GUI, the AI assistant, orbited around it as a separate window you alt-tabbed into. I didn't plan to change that. It just stopped making sense once the pieces lived in one place.

Key Takeaways

Keeping the terminal inside the same app as your Git client removes a whole category of alt-tabbing and lost context, especially when you're watching an AI make changes in real time.

More developers are letting AI write commit messages without reading them first, which quietly erodes the readability of Git history over time.

An AI commit feature that lives inside your Git client, not a separate tool, keeps the human in the loop: it proposes, you review and edit, you commit.

The IDE isn't going away, but its role as the single hub for a developer's day is shrinking, and the Git client is a serious candidate to take that spot.

The Alt-Tab Tax Nobody Budgets For

I used to run three windows to get anything done: an IDE, a terminal, and a Git GUI. Sometimes a fourth for a chat-based AI tool. Every time I wanted to check what a command actually did to my working tree, or verify that a build I'd just kicked off hadn't broken something, I'd switch windows, refocus, and try to remember what I was looking for in the first place.

None of that felt slow in the moment. It felt normal, the same way GitKraken's lag felt normal until I noticed it. But normal isn't the same as necessary. Gitoryx ships with an integrated terminal built on xterm.js and a real PTY, so running a command and looking at the resulting diff happen in the same window, one click apart instead of one window swap apart.

The honest reason this matters isn't that switching windows takes long. It's that switching windows breaks your attention, and attention is the thing you actually run out of during a long coding session. Fewer context switches throughout your day add up to more hours where you're actually thinking about the problem instead of hunting for the window that has the answer.

Watching AI Work Without Losing Sight of the Code

Here's where the terminal-in-the-Git-client setup earns its keep the most: when an AI coding assistant is actively working in your repo.

I run AI tools in the terminal a lot now, the same way most developers do. The problem was never running them. The problem was watching what they did. In a separate terminal app, checking the AI's progress means alt-tabbing out of my Git client, watching a wall of text scroll by, then alt-tabbing back to see what actually changed in the code. By the time I got back to the diff view, I'd usually forgotten exactly which part of the output I was trying to correlate with which file.

With the terminal built into the same app as the commit graph and diff viewer, I can run the AI session in one pane and watch the working tree update in real time in the other. If it touches a file I didn't expect, I see it the moment it happens, not five minutes later when I finally switch back. That's not a hypothetical convenience. It's the difference between catching an unwanted change immediately and finding it after three more commits have piled on top of it.

I've caught more than one AI-generated change that touched a file outside the scope of what I'd asked for, simply because the diff was sitting right next to the terminal output instead of a full window away. Nothing dramatic, usually a formatting pass that spread further than intended, but it's the kind of thing you only catch if you're actually watching, and you only watch consistently if watching is easy. It's also changed how I think about commits themselves when an agent is doing the typing: they stop being a record of what I wrote and become checkpoints I use to keep control of what something else wrote, a shift I go into in more detail in Vibe Coding With Git.

The Commit History Nobody's Reading Anymore

There's a habit spreading through teams that I think deserves more scrutiny than it's getting: letting AI write the commit message and hitting commit without reading it.

I get why it happens. Writing a good commit message takes a few seconds of thought, and when you're deep in a flow state, those seconds feel like friction. But a commit message isn't decoration. It's the thing a teammate reads six months from now to understand why a change was made, or the thing you read yourself during a git bisect session at 11 PM trying to find out which commit broke production. When that message is generated and never reviewed, you get technically accurate but generic text that describes what changed without ever explaining why, and a Git history that slowly stops being useful as a record of decisions.

Gitoryx has AI commit messages built into the commit panel, supporting Anthropic Claude, OpenAI, GitHub Models, or a custom OpenAI-compatible endpoint if you're running something local. But the feature only works the way I intended if you treat it as a first draft, not a final answer. The AI reads your staged changes and proposes a title and description. You still see it in the same panel where you'd write it by hand, and you still edit it before it goes anywhere. Nothing commits itself.

That distinction matters more than it sounds like it should. A commit-message generator bolted onto a separate tool, outside your Git client, makes it easy to copy-paste and move on without a second look. One that lives inside the same panel where you're already reviewing your diff puts the proposed message right next to the actual change, so editing it before committing is the path of least resistance instead of an extra step you skip when you're tired.

Why I Think the IDE's Role Is Shrinking

I want to be careful here, because I'm not arguing the IDE is going away. Editing code, real editing with syntax awareness, refactoring tools, and language server support, still needs a dedicated environment, and nothing about a Git client replaces that.

What I am arguing is narrower and, I think, more interesting: the IDE's claim to being the single hub where a developer spends their day is weakening. A few years ago, the IDE was where you edited code, ran your terminal, checked your Git status through a thin sidebar panel, and increasingly, chatted with an AI assistant bolted on as a plugin. Each of those secondary functions was there because there wasn't a better place for it, not because the IDE was the natural home for version control or command execution.

Now that Git clients are picking up real terminals and real AI integration, that default is getting questioned. A Git client that shows you your full history, lets you run commands without leaving the window, and helps you write the record of what you did and why, starts to look less like a viewer for git log and more like a second hub competing for the center of your workflow, doing the specific job an editor's built-in Git panel was never built to do (a distinction I laid out in Why Desktop Git Clients Still Matter). I don't think it fully displaces the IDE. I think it starts splitting the day: the IDE for writing and shaping code, the Git client for everything around understanding, verifying, and recording that code's history.

If that split keeps deepening, in a few years the tool you open first each morning, the one you keep in the primary window while everything else is secondary, might not be your IDE at all. It might be your Git client.

What This Looks Like in Practice

None of this required a chat-based AI assistant living inside a Git client, and I want to be precise about that, because it's tempting to describe a bigger product than what actually exists. Gitoryx doesn't have a conversational AI or an AI code reviewer. What it has is an integrated terminal so you can run whatever AI tooling you already use without leaving the app, and an AI commit message feature that proposes text you review before it becomes permanent history. Both are modest on their own. Together, in the same window, they change how much attention switching your day requires.

That's the actual argument. Not that AI belongs everywhere, but that when it does show up in your workflow, having it inside the tool that already shows you your code's real state, instead of scattered across a separate terminal, a separate chat window, and a separate Git GUI, keeps you closer to what's actually happening and keeps you the one making the final call.

If the story in my first post was about leaving a tool that had stopped serving me, this one is about what I built to replace it starting to serve a bigger role than I expected. I didn't set out to make a case against the IDE. I just kept noticing I needed it less.

Try Gitoryx free. It's free forever for public repos, native on macOS and Windows, and the integrated terminal and AI commit messages are both available on the free plan.

Why I Stopped Using GitKraken and Built My Own Git Client Instead

Félix Legrelle — Fri, 25 Sep 2026 13:56:20 +0000

I didn't set out to build a Git client. I set out to stop using the one I had.

For a long time, GitKraken was just part of my toolchain — the thing I opened without thinking about it, the same way you don't think about your terminal emulator until it starts lagging. Then, one day, it did start lagging. And once I noticed, I couldn't stop noticing.

This is the story of why I left, what specifically pushed me over the edge, and why I ended up spending my evenings and weekends building Gitoryx instead of just switching to a competitor.

Key Takeaways

GitKraken got heavier over time — an Electron app that started stuttering on repositories with real history, not toy repos.

It shipped features I never asked for, including a bundled MCP server that quietly ate into the context window of my AI coding sessions.

Several other developers I talked to described the same frustration — creeping feature bloat and pricing that climbs for functionality they don't use.

Gitoryx is my answer: a native (non-Electron) Git GUI, ~12 MB, with git bisect and gitmoji built in as first-class citizens instead of afterthoughts.

The Slowdown I Kept Making Excuses For

GitKraken is an Electron app. That's not a secret — it's on their own marketing at times, framed as cross-platform convenience. For a while, that trade-off didn't bother me. My repos were small, my laptop was fast, and the extra RAM footprint was just background noise.

Then the repos got bigger. More branches, longer history, more collaborators. And the app that used to feel instant started to feel like it was thinking before it responded — a half-second delay opening the commit graph, a stutter switching branches, a spinner where there used to be nothing.

I want to be precise here: I'm not claiming GitKraken is unusably slow for everyone. Plenty of developers run it daily without complaint. But for me, on the repositories I actually work in, the gap between "what I need" (open a repo, see the graph, commit, done) and "what I was getting" (wait, then do those things) kept widening. And once you notice a tool making you wait, you can't un-notice it.

How Gitoryx avoids the Electron tax

The MCP Server I Didn't Ask For

Here's the moment that actually made me start looking for alternatives, not just grumbling about them.

I use AI coding assistants throughout my day — that's not unusual anymore. What is unusual, and unwelcome, is when a tool I open for one job (visualizing my Git history) decides to insert itself into a completely different part of my workflow. GitKraken started shipping its own MCP server, wired in by default, and that server started occupying context space in my AI coding sessions. Not because I asked for it. Not because I opted in for a specific task. It was just there, taking up room that I would rather have spent on the actual problem I was working on.

If you've never run into this, here's the short version: your AI assistant has a finite context window, and every tool or server that gets automatically wired into a session competes for space in it. When a Git client — a tool whose entire job is showing you commits and branches — starts consuming that budget for a feature you never requested, it stops feeling like a convenience and starts feeling like a tax you didn't agree to pay.

I don't think this was malicious. I think it's what happens when a company chases every emerging trend at once and ships it to everyone by default instead of letting people who actually want it turn it on. But intent doesn't matter much when you're the one losing context mid-task.

Paying More for Things I Never Use

The MCP situation was the spark, but the pricing pattern is what convinced me this wasn't just my problem.

Over time, I watched the price of tools I relied on creep upward — not because the core thing I used got better, but because a bundle of new features got added on top, features I had no interest in and never touched. I paid more for the same workflow I'd always had, subsidizing capabilities aimed at a different kind of user than me.

When I mentioned this to other developers — not as a pitch, just as a complaint over a coffee or in a Slack DM — I kept getting the same reaction back: yeah, same here. Different tools, same shape of frustration. Nobody I talked to wanted a bigger bundle. Everybody wanted to pay for what they actually used.

That's the part that turned a personal annoyance into something I thought was worth building around: the right price for the right tool, not a subscription that grows every year regardless of whether your own usage does.

Gitoryx pricing

What I Actually Built Instead

Once I decided to build my own Git client, I had a short, very specific list of things I wanted to get right — mostly because they were the exact things that had pushed me away from what I was using before.

Native, not Electron. Gitoryx is a native app for macOS and Windows. No bundled Chromium, no hundreds of megabytes of RAM just to render a commit graph. It's about 12 MB and starts instantly, because a Git client's job is to get out of your way, not to announce itself.

Git bisect that's actually visual. I didn't want to remember git bisect start, good, bad, and the mental bookkeeping that goes with it. Gitoryx turns bisect into a guided binary search: you mark commits good or bad with a click, and it narrows down to the culprit commit for you, visually, without dropping back to the terminal.

Gitmoji, built into the commit panel. If you use gitmoji in your commit messages — and after years of 🐛 fix parser edge case and ✨ add search endpoint, I do — it should be a first-class part of writing a commit, not a browser tab you alt-tab to. The picker in Gitoryx is searchable, remembers the emoji you use most, and plays fine with conventional commits if you use both.

Nothing running in the background that you didn't ask for. No forced integrations. No server-side account requirement to use it on your public and open-source repos. It runs locally, and it stays out of tools it has no business touching — including your AI assistant's context window.

Pricing that matches what you get. Free forever for public repos and up to your last 30 commits on private ones, two Git identity profiles included. If you need more, Pro is €6/month, €50/year, or €130 once, for life — unlimited history, unlimited profiles, self-hosted integrations, and every future feature, no re-bundling required.

Why This Matters Beyond Me

I'm not writing this to tell you GitKraken is bad software — it clearly works for a lot of people, and it's the reason there's even a [/compare/gitoryx-vs-gitkraken](http://www.gitoryx.com/compare/gitoryx-vs-gitkraken) page on my site, because comparison is the honest way to let you decide, not a reason to trash-talk a competitor.

What I do think is worth saying out loud: developer tools that quietly expand their footprint — in RAM, in your AI context window, in your monthly bill — are asking for a kind of trust they haven't necessarily earned. You didn't sign up for a platform. You signed up for a Git client. When the two get blurred, it's fair to ask whether the tool is still serving you, or whether you're now serving the tool's roadmap.

Gitoryx is my attempt to draw that line clearly: do one job — showing you what Git is actually doing — do it fast, and charge you for exactly that, nothing more.

If any part of this sounded familiar — the slowdown you keep excusing, the feature you never wanted eating your AI context, the subscription creeping up for capabilities you'll never touch — that's the exact list of problems I built Gitoryx to solve. Try Gitoryx free. It runs on macOS and Windows, and public and open-source repos stay free forever.