Git-First and Loving It: What a Year of Remote Work Taught Us About Dev Tooling

Almost a year into distributed-by-default engineering, something has shifted quietly in how teams actually get code into production. It’s not a new language or framework. It’s the workflow itself. The centralized, meeting-heavy, “gather everyone in a room to review code” model has been steadily displaced by something more Git-first: branch-based development, pull-request review, and asynchronous discussion baked directly into the tools people use every day.

This isn’t a new idea. GitHub popularized the pull-request model over a decade ago, and GitLab built an entire platform around merge requests and CI pipelines. What’s changed is that these patterns have gone from “best practice for open source” to “the only practice that works when your team is scattered across six time zones.”

Why this year forced the issue

When everyone sat in the same office, a lot of code review and design discussion happened informally — a shoulder tap, a whiteboard session, a quick sync call. That option disappeared for most teams last spring. What replaced it wasn’t a like-for-like swap to video calls (though there was plenty of that too); it was a shift toward writing things down, in context, where the code lives.

A pull request becomes a durable artifact: the diff, the inline comments, the back-and-forth reasoning, all timestamped and searchable later. Nobody has to be online at the same moment for review to happen. That’s the entire pitch of async-friendly tooling, and it turns out to matter a lot more when “just grab five minutes” isn’t an option.

The tools riding this wave

GitHub and GitLab are the obvious beneficiaries here, since PR/MR review is core to both platforms. But it’s worth calling out GitKraken too — a visual Git client that’s been leaning hard into making branch and commit history legible for people who don’t want to live in the terminal. When your workflow depends entirely on branches, clear visualization of what’s diverging from what stops being a nice-to-have.

The common thread across all of these tools is that they’re optimizing for the same thing: reducing the number of moments where progress depends on two humans being awake and available simultaneously. Comment threads, review requests, suggested changes, CI status checks — it’s all designed to let contributors act independently and catch up asynchronously.

What teams seem to have learned

Talking to engineers over the past several months, a few lessons keep coming up. Smaller, more frequent pull requests review faster and generate less friction than big batched ones — which was probably always true, but is now enforced by necessity rather than aspiration. Clear commit messages and PR descriptions matter more when there’s no hallway conversation to fill in the gaps. And teams that invested early in CI/CD pipelines tied to their branching model report much less chaos than those still merging straight to a shared branch and hoping for the best.

None of this is flashy. There’s no single product launch driving it. It’s more like a slow, collective realization that the tools built around Git’s branching model happen to be exactly the tools distributed teams need. Whether remote work stays this widespread once things open back up is anybody’s guess, but I’d bet these workflow habits stick around regardless — they’re just better ways to collaborate on code, pandemic or not.