{"slug": "the-whole-loop-one-window", "title": "The Whole Loop, One Window", "summary": "A developer has built GitDesktop, a Git client designed to keep the entire development workflow in one window, from local pull request creation to AI-assisted reviews and branch management. The tool challenges the assumption that pull requests must begin with a push, allowing users to prepare and review changes locally before publishing. It also enables updating branches without switching, addressing the disruption caused by branch switching in modern development environments.", "body_md": "I've spent years working with Git.\n\nNot just using it, but living in it. Feature branches, code reviews, releases, hotfixes, open source, side projects, client work—the rhythm becomes second nature.\n\nAnd yet, over time, I noticed something strange.\n\nThe moment I needed to do anything beyond committing code, I was expected to leave.\n\nLeave the Git client to create a pull request.\n\nLeave it to review changes.\n\nLeave it to check project traffic.\n\nLeave it to manage branches.\n\nLeave it to use AI.\n\nLeave it to enforce the kinds of guardrails that prevent simple mistakes.\n\nIt never felt intentional. It was just... accepted.\n\nBut the more I thought about it, the more one question kept coming back:\n\nWhy am I leaving?\n\nThat question became GitDesktop.\n\nWhen I first started planning the project, I wasn't trying to build a better GitHub Desktop.\n\nI wasn't trying to cram every Git feature imaginable into one application.\n\nThe original idea was much simpler.\n\nI wanted to build a calm Git client I could leave open all day.\n\nSomewhere along the way, that idea became five words that ended up guiding every feature I built:\n\nThe whole loop, one window.\n\nIt wasn't a tagline.\n\nIt was a design constraint.\n\nEvery time I wanted to add something, I asked the same question:\n\nDoes this help me stay in the flow, or does it send me somewhere else?\n\nPull Requests shouldn't begin after you push\n\nOne of the biggest workflow interruptions for me has always been creating pull requests.\n\nThe workflow looked something like this:\n\nStage changes.\n\nCommit.\n\nOpen GitHub.\n\nCreate a pull request.\n\nWrite the title.\n\nWrite the description.\n\nMaybe ask AI to help.\n\nEverything about that process felt disconnected.\n\nThe repository was already on my machine.\n\nThe diffs were already on my machine.\n\nThe commit history was already on my machine.\n\nSo why did the workflow suddenly move into a browser?\n\nWhen GitHub introduced Copilot-powered pull request generation, I actually thought it was a great feature.\n\nBut I already preferred Claude.\n\nI didn't want to switch assistants depending on where I happened to be working.\n\nI wanted the workflow—not the provider.\n\nThat eventually led to one of my favorite features in GitDesktop: Local Pull Requests.\n\nNot because they're technically interesting.\n\nBecause they challenge an assumption I don't think we've questioned enough.\n\nWe tend to think a pull request begins the moment we push.\n\nI don't.\n\nTo me, pushing is the moment a pull request graduates from private work to shared work.\n\nBefore that, I'm still thinking.\n\nI'm still iterating.\n\nI'm still rewriting descriptions.\n\nI'm still asking AI to review something.\n\nI'm still cleaning up commits.\n\nI'm still deciding whether it's ready for someone else's time.\n\nWhy should any of that require a remote repository?\n\nGitDesktop lets me prepare the entire review locally before deciding to publish it.\n\nNot because GitHub can't review code.\n\nBecause I believe the first reviewer should always be yourself.\n\nBranches are no longer just branches\n\nYears ago, switching branches was almost free.\n\nToday, a branch is an environment.\n\nSwitching branches can restart development servers.\n\nHot module replacement kicks in.\n\nDependencies change.\n\nGenerated files change.\n\nEnvironment variables change.\n\nMigrations change.\n\nI've had moments where I switched back to an old feature branch just to update it and suddenly found hundreds of files appearing as untracked because .gitignore had changed on another branch.\n\nNot because I intended to work there.\n\nSimply because Git required me to visit that branch before updating it.\n\nAnother time, I interrupted active development just to pull changes into a long-running epic.\n\nEverything restarted.\n\nThe application reloaded.\n\nThe context I was in disappeared.\n\nNone of that had anything to do with the work I was actually trying to accomplish.\n\nI just wanted to bring another branch up to date.\n\nSo GitDesktop lets me do exactly that.\n\nUpdate another branch without leaving the one I'm currently working in.\n\nNot because it's impossible otherwise.\n\nBecause switching contexts should be a choice—not a requirement.\n\nGuardrails shouldn't be a pricing tier\n\nSome of my favorite GitDesktop features exist because of incredibly ordinary mistakes.\n\nI've merge committed directly into development branches because muscle memory took over.\n\nI've deleted the wrong branch after promoting a release.\n\nNone of these were knowledge problems.\n\nThey were human problems.\n\nGitHub has branch protections.\n\nThey're great.\n\nBut many of the protections I wanted either happen remotely or are tied to higher-tier workflows.\n\nThat always felt backwards.\n\nThe best safety features shouldn't only exist after you've already pushed your code somewhere.\n\nThey shouldn't only exist for large organizations.\n\nSometimes you just want your tools to stop you from making an obvious mistake.\n\nLocal branch protection came from that belief.\n\nGood guardrails should be available wherever you're working.\n\nEspecially when you're working alone.\n\nMonitoring shouldn't require hunting\n\nAnother habit I've developed over the years is checking on my projects.\n\nNot because I enjoy dashboards.\n\nBecause I genuinely like seeing whether people are using the things I've built.\n\nHow many visitors showed up today?\n\nWhere did they come from?\n\nWhich repositories are getting attention?\n\nThat routine usually meant opening GitHub...\n\nThen another repository.\n\nThen another.\n\nThen another.\n\nEventually I had several browser tabs open just to answer one simple question:\n\nHow are my projects doing?\n\nIt felt disconnected.\n\nThe repositories I cared about were already sitting inside the Git client I had open all day.\n\nWhy wasn't that information there too?\n\nRepository Insights wasn't born out of wanting prettier graphs.\n\nIt was born out of wanting the projects I care about to stay close.\n\nBring your own workflow\n\nAI accelerated this realization.\n\nEvery company wants you inside their ecosystem.\n\nUse their assistant.\n\nUse their models.\n\nUse their workflow.\n\nBut developers don't work that way.\n\nSome people prefer Claude.\n\nSome use OpenAI.\n\nOthers run local models.\n\nTomorrow there will be something new.\n\nThe tool shouldn't force that decision.\n\nIt should adapt to it.\n\nThe same applies beyond AI.\n\nWhether it's GitHub, GitLab, Bitbucket, or something else, I don't think your development workflow should be dictated by whichever platform happens to host your repository.\n\nYour tools should work with you.\n\nNot the other way around.\n\nQuestioning assumptions\n\nAs I look back over GitDesktop, I notice something.\n\nI wasn't really building features.\n\nI was questioning assumptions.\n\nWhy does a pull request require a remote?\n\nWhy do reviews begin after pushing?\n\nWhy do I have to leave my Git client to understand my project?\n\nWhy should switching AI models change my workflow?\n\nWhy should updating another branch interrupt the one I'm actively working in?\n\nWhy are some of the best guardrails only available after code leaves my machine?\n\nEvery feature traces back to one of those questions.\n\nThe whole loop, one window\n\nIf GitHub Desktop adopted every feature I've built tomorrow, I'd be thrilled for developers.\n\nBut I don't think we'd be building the same product.\n\nBecause GitDesktop isn't defined by Local Pull Requests, branch protection, AI integration, or repository insights.\n\nIt's defined by a philosophy.\n\nI believe developer tools should adapt to developers—not ask developers to adapt to them.\n\nI believe the best workflows happen as close to the code as possible.\n\nAnd I believe every unnecessary context switch is an opportunity to ask a simple question:\n\nDo I actually need to leave?\n\nThat question has shaped every feature in GitDesktop so far.\n\nAnd I suspect it'll shape every feature I build next.\n\nBecause for me, the goal has never been to build another Git client.\n\nIt's been to build the one I never have to leave.\n\nWhat's one part of your workflow that always makes you think, \"Why do I have to leave?\"\n\nThis essay also lives on the GitDesktop blog — [https://gitdesktop.app/blog/the-whole-loop-one-window/](https://gitdesktop.app/blog/the-whole-loop-one-window/)", "url": "https://wpnews.pro/news/the-whole-loop-one-window", "canonical_source": "https://dev.to/thebguy/the-whole-loop-one-window-561g", "published_at": "2026-08-17 23:22:13+00:00", "updated_at": "2026-08-17 23:42:51.591735+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["GitDesktop", "GitHub", "Git", "Copilot", "Claude"], "alternates": {"html": "https://wpnews.pro/news/the-whole-loop-one-window", "markdown": "https://wpnews.pro/news/the-whole-loop-one-window.md", "text": "https://wpnews.pro/news/the-whole-loop-one-window.txt", "jsonld": "https://wpnews.pro/news/the-whole-loop-one-window.jsonld"}}