I hear you. But nothing goes directly into main. The working branch is not sacrosanct you know what I mean? I'd rather clean up anything that leaks in before merging and a good .gitignore can protect against most noise.

Sure but it goes in the repo. Forgot to add .env to the .gitignore? You probably just committed a secret. Sure you can force push to get rid of it but if you're using Github it's still saved so it needs to be rotated now.

What’s “the repo” here? What I commit goes into my copy of the repo. Only what I push goes into any repo anyone else sees. Before pushing I always go through what’s in the branch and clean up/rebase etc. Sure it’s easier to accidentally push a file you shouldn’t have if you have added it locally but committing alone doesn’t necessarily mean you need to rotate a secret.

That is a case where (as you note) you'd need to do some sort of destructive fix to eliminate the file from your local repo. Whether it's a rebase or something else, a person then needs to know "the advanced parts" that the blog post is advocating aren't really needed if "git is done correctly". Better to just not commit files/hunks accidentally in the first place - I know, it's not a perfect world, yada yada - just trying to provide the counter point to the counter point.

Yeah I’d say interactive rebase and soft resets is part of my “limited toolbox” for git that I wouldn’t go without. (I don’t stage hunks, don’t merge in either direction etc, so I leave some other parts of the larger toolbox alone).

> But nothing goes directly into main.

That's not a reasonable argument. The problem is pushing confidential info into a repository. It matters nothing what the branch you push it is called.

FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches.

> FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches.

Irrelevant. You're describing a failsafe. It's like claiming that you don't need to care about speed limits because a road has guardrails. The whole process is broken if it fails to address the main reason confidential info can be pushed into repositories.

nah, I always git add --all && git commit -m "issu-12 my short message"

if something leaks and I need to add to gitignore I'll amend.

there's definitely cases for staging more complicated edits but not in my daily work.

combined with the authors disdain of commit messages or documentation I can't figure out where they've chosen to document why changes are made.

commit messages != documentation