Why Your Next IDE Might Actually Be a Git Client

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.