Git

I used to commit without looking. I'd stage changes, write a message, and push. Then I'd discover I'd left in a pdb breakpoint, or staged a credentials file, or bundled someone else's work into my branch. After the third time I had to force push to undo a bad commit, I started actually reading what I was about to ship. Now I run git diff --cached before every commit. It takes maybe a second per commit, and I catch the thing that will break the build or get called out in review about one commit per week. Sometimes it's a debug print I forgot. Sometimes it's a line count that's way off from what I intended, which usually means I've accidentally pulled in unrelated changes. The command is straightforward: stage what you think belongs, then git diff --cached to see the stat line and the full diff. If something looks wrong, unstage it with git reset and fix it. Only then git commit. I also use git add -p when I'm touching multiple things, which forces me to review line by line as I stage. It does not work when you're in a hurry and you skip the check anyway. And it obviously does not catch logic errors, just the obvious mechanical mistakes. But if you actually do it, you will catch stray files and oversized diffs before they land in the repository. ```bash $ git diff --cached --stat internal/handler/move.go | 18 +++++++++--- internal/handler/move_test.go | 42 ++++++++++++++++++++++ .env.local | 3 +++ 3 files changed, 60 insertions(+), 3 deletions(-) $ git restore --staged .env.local ```

I used to commit whatever was staged, which sounds efficient until you realize that efficiency in the wrong direction just means you commit faster. I'd push a branch with three test files still in there, or a package-lock.json file I never meant to touch, or worse: a five hundred line refactor when I'd sworn I was only fixing the bug. The commit would land, someone would ask why that one change was in there, and I'd have to squint at GitHub and pretend I had a reason. So now I run `git diff --stat` before every single commit. It takes about one second. I read through the stat line, check the file count, verify the numbers make sense for what I thought I was doing, and then I commit. That's it. The tool is just git. The discipline is knowing that one second now saves five minutes of explaining later. The concrete detail is the stat line itself. `git diff --stat` shows you file names and the number of added and deleted lines in a tiny ASCII chart. If I see a node_modules change or a lockfile in there, I know I'm about to make a mistake. If I see a file I don't recognize, I stop and figure out why it's there. If the numbers don't match my intent, I unstage and re-sort what I'm actually committing. The caveat is that this only works if you're committing conscious changes. If you're in the middle of a refactor where you're genuinely touching forty files at once, the stat line won't save you. You still need to have structured your work so that you know what belongs together. This is a safety rail, not a strategy. ```bash $ git diff --cached --stat internal/handler/move.go | 18 +++++++++--- internal/handler/move_test.go | 42 ++++++++++++++++++++++ .env.local | 3 +++ 3 files changed, 60 insertions(+), 3 deletions(-) $ git restore --staged .env.local ```

Before I adopted conventional commits, my git log was a graveyard of "fix stuff", "updates", and "wip". When it came time to cut a release, I'd manually sift through months of commits trying to figure out what actually changed for users. Worse, when I needed to bisect a regression, reading commit messages from six months ago felt like archaeological work because nobody had bothered to say whether a commit was a breaking change, a bug fix, or just a refactor. I started structuring every commit as type(scope): subject where type is one of feat, fix, refactor, docs, chore, or perf. The scope is optional but specific: auth, api, cli. This took maybe two weeks to internalize as muscle memory. Now when I'm in the middle of a bisect and land on a commit, I can immediately tell whether it was a behavioral change or a code cleanup without reading the body. The real payoff arrives when GitHub Actions runs after a merge to main. A simple script parses commit types, groups them, and generates release notes automatically. I've set up a workflow that counts feat commits for minor versions, fix commits for patches, and any breaking change in the commit footer for major versions. No more sitting in a release meeting trying to remember what we shipped. The caveat is that this only works if your team actually follows the convention, and if you're rebasing frequently in a chaotic codebase, you'll spend time cleaning up commit messages anyway. Squash merging can also obscure individual commits, so you lose the benefit during bisect. It's less powerful than a proper changelog file, but it beats starting from nothing. ```bash $ git log --oneline -4 9cfc5db fix(auth): reject expired refresh tokens 4c43ff2 feat(feed): cursor paginate the home feed 7fa7e00 chore(deps): bump ent to 0.14 b3bc5e2 docs(readme): document the staging runbook ```

I used to do branch-per-feature with a release branch and a hotfix process that made me want to become a park ranger. The release would fail, I'd revert, create a hotfix branch, test it separately, merge it back to develop and main, then manually coordinate what actually shipped. Every incident felt like herding cats that were also on fire. The shift was moving to trunk-based development with feature flags. Everything merges to main within 24 hours, but the code is dark behind a flag that defaults to off. When we're ready to release, we don't merge anything. We just flip the flag in LaunchDarkly and watch the metrics. If something breaks, we flip it back. If we need to iterate, we merge the fix to main under the same flag and push the config change again. The concrete part: our release process is now a two-minute config update instead of a 30-minute git dance with three environments. When we had a bad release last month, rolling back was literally one click instead of a git revert, new branch, test cycle, and a Slack apology tour. Our main branch CI is just about whether the code compiles and the tests pass, not whether it's production-ready. The caveat is that this only works if your feature flags are actually reliable and your feature work doesn't require schema migrations or other non-reversible database changes. We still have a separate deployment process for those because breaking the contract is harder to unbreak with a config flag. ```diff - if (user.isBetaTester) { + if (flags.enabled("checkout_v2", user)) { return <CheckoutV2 />; } - // TODO: remove after the beta + // flag owner: payments, review date in the flag registry ```