Rohan Kartik All build notes

#engineering patterns #process

Branch per feature, named for the moment

I work alone on the portfolio repo. There is no team to coordinate with, no required PR review, no CODEOWNERS file. I still cut a branch for every feature.

The about-page work moved through three branches: feat/about-page-photo-scrub (the cursor-driven cross-fade), feat/about-page-transparent (the swap to background-removed photos with the card stripped), and feat/about-photo-bottom-bleed (the in-progress crop adjustment). Each one started with git checkout -b at the top of a ship script and ended with git push -u origin .

The reasons line up even for a solo repo:

Vercel auto-deploys branch pushes as preview URLs. Each branch gets its own URL. I can see the photo-scrub version and the transparent version side by side without juggling local builds. That’s the practical reason.

The branch name is a sentence. feat/about-page-photo-scrub tells me, three months later, what this branch was for. The commit messages inside it elaborate. Without a branch, the only navigation aid is commit messages, and they aren’t grouped.

Merging to master is deliberate. After the preview looks right, I run git checkout master and git merge —no-ff . The —no-ff preserves the branch’s existence in the history. The merge commit message restates what shipped. Anyone reading git log months later sees a clean linear story of master with branch tributaries.

The branch I abandoned (feat/about-page-photo-scrub, superseded by feat/about-page-transparent) is still in the history. It didn’t ship, but its commits exist, and I can recover any choice from it if I change my mind. Branches are cheap. Lost work isn’t.

The principle: branches are the unit of “what was I trying to do.” Use them even when nobody is watching.