I Knew Git. I Just Never Had a Reason to Branch.
I learned version control back in the Subversion days, but I never learned how to work like a team. Here's how a protected main, a PR-only workflow, and Cursor holding the discipline finally closed the gap.
By Michael Lynn • 7/4/2026
Share:
I need to be honest about what I actually didn't know, because "I never learned git" would be the wrong confession. I learned version control before git existed. Subversion first, then PVCS at an early job. The concept was never foreign. I know my way around a terminal. For most of my career, though, my workflow looked like this, unedited:
bash code-highlightgit clone <project>
cd <project>
# ...modify...
git add .
git commit -m "description of change"
git push origin main
Clone it, change it, commit it, push it to
main. That was the whole thing. It worked because for most of that time I wasn't on a team large enough to need anything else. Nobody else's branch to collide with. No review gate. No reason to learn what a feature branch was actually for. The discipline never had a reason to show up.So when I started building inside a codebase where
main is genuinely protected, where you can't push to it even if you wanted to, where every change has to go through a pull request, I felt like an impostor. Not because I didn't know git. Because I didn't know how to work like a team, and it looked like everyone else already did.If most of your git history reads "push to
main and move on," because you've spent your career solo, in a small shop, or as the only technical person in the room, you're probably in the same boat. Here's what actually closed the gap for me. It wasn't a refresher course. It was Cursor doing the branch-and-PR steps by default while I figured out why they mattered.What I had to learn by breaking things
None of this is exotic. It's just the kind of knowledge you only pick up when you're working alongside other people's branches, which I mostly hadn't.
main is protected. A ruleset requires a PR, green CI, and review before anything lands. No force-push, no admin-merge. Every PR builds a preview first, so breakage shows up before it ships, not after.The PR is the unit of work. Push to a branch and you get a preview deploy. Merge the PR and production updates. Nobody runs a deploy command by hand.
And once a PR merges, its branch is gone. Merges squash and auto-delete the head branch. Anything you push after that goes nowhere. It isn't on
main, and the PR won't reopen.
I didn't need a course to follow this. Cursor follows it by default. I just had to stop overriding it: branch off the latest
main, do the work, push, open a PR with a preview deploy, get through Bugbot and CI and review, merge, production.One PR, one logical change
My solo-dev instinct was always to just keep going. One sitting, one commit, whatever piled up during that session went in together. "Scope" wasn't a word I used. Splitting work into one logical change per PR felt like busywork at first.
Then I watched a PR with three unrelated changes sit in review for a week while I kept bolting fixes onto it. Small PRs merge faster. Each one gets its own preview URL, so you can actually see what you're about to ship. And you're not tempted to add "one more fix" to a branch that's already in flight, or already dead.
The stranded-commit trap
This is the one that got me. Not because it's complicated. It's four steps. But it's exactly the reflex you build when it's just you and
main for years.Something just merged. You're still sitting in the file. You spot one more thing. You fix it. You push. That reflex worked fine for years. It does not work here.
You open a PR from
feature-x. It gets squash-merged, sometimes within minutes. You, or an agent, push "just one more fix" to feature-x. That fix goes nowhere. The branch is deleted, the PR is closed, and the bug you thought you fixed is still live.I found this out watching a layout bug I was sure I'd patched sit there, still broken, because my commit had nowhere to land. It felt like the tool failed me. It hadn't. I just didn't know the rule yet.
If it already happened, cut a fresh branch off the current
main, cherry-pick the stranded commit, run your checks, push, and open a new PR.bash code-highlightgit checkout main && git pull
git checkout -b fix-stranded-change
git cherry-pick <stranded-commit-sha>
# run tests / checks
git push -u origin fix-stranded-change
# open a new PR
The commands were never the hard part
I could always run
git branch and git checkout. What I didn't have was a reason to, or a feel for when to split work, how to keep a PR reviewable, or what to do when Bugbot leaves a comment. That's where Cursor actually helped.| Feature | What it does for the workflow |
|---|---|
| Tab | In-flow multi-line edits. Keeps small PRs small. |
| Composer / Agent mode | Multi-file changes scoped to one PR. Lands a complete, reviewable change in one pass. |
| Background / Cloud Agents | Offload a well-scoped task. They branch and open a PR for you, one change per run. |
.cursor/rules/*.mdc | Encode repo conventions so the agent doesn't touch managed files or push to main. |
MCP (mcp.json) | Connect the agent to real tools and data so changes are right the first time. |
| Cursor CLI | Scripted, headless agent runs with the same branch → PR discipline. |
| Bugbot / Security Bugbot | Automated review on every PR. Respond on the same open branch before merge, not after. |
Habits that mattered more than any git command
Scope the ask to one PR. "Add X, refactor Y, and fix Z" produces an un-mergeable mega-diff.
Tell the agent the constraints. Point it at the repo's rules so it doesn't try to deploy directly or edit managed files.
Ask for tests as part of the change, not as a follow-up request after the fact.
Let the agent open the PR, then review the preview URL yourself and merge.
You don't owe anyone a git history that reads like you led a ten-person team
If you've spent your career solo, in a small shop, as a consultant, or as the only technical person in the room, knowing git and knowing how to work like a team are two different skills. I was sure everyone else had already internalized the second one. Most of us are patching the same gap, at different speeds.
What changed for me wasn't a refresher on commands I already knew. A protected
main and a PR-only workflow forced the habits I'd never needed. Cursor handled the branching and PR steps while I learned what they were for. The workflow catches mistakes before they ship instead of waiting for me to have already built team hygiene from scratch.If most of your career has been solo, or in a shop too small to force branch discipline on you, what's the workflow gap nobody ever made you close? I'd guess you're not the only one who has one.