Not just using it, but living in it. Feature branches, code reviews, releases, hotfixes, open source, side projects, client work—the rhythm becomes second nature.
The moment I needed to do anything beyond committing code, I was expected to leave.
When I first started planning the project, I wasn't trying to build a better GitHub Desktop.
Somewhere along the way, that idea became five words that ended up guiding every feature I built:
Pull Requests shouldn't begin after you push One of the biggest workflow interruptions for me has always been creating pull requests.
When GitHub introduced Copilot-powered pull request generation, I actually thought it was a great feature.
That eventually led to one of my favorite features in GitDesktop: Local Pull Requests.
To me, pushing is the moment a pull request graduates from private work to shared work.
GitDesktop lets me prepare the entire review locally before deciding to publish it.
Branches are no longer just branches Years ago, switching branches was almost free.
I'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.
Another time, I interrupted active development just to pull changes into a long-running epic.
None of that had anything to do with the work I was actually trying to accomplish.
Guardrails shouldn't be a pricing tier Some of my favorite GitDesktop features exist because of incredibly ordinary mistakes.
I've merge committed directly into development branches because muscle memory took over.
But many of the protections I wanted either happen remotely or are tied to higher-tier workflows.
The best safety features shouldn't only exist after you've already pushed your code somewhere.
Monitoring shouldn't require hunting Another habit I've developed over the years is checking on my projects.