You can just add it in a user-level gitignore instead of ignoring it in every repo. See: ~/.config/git/ignore

> Now, I could extend my user-global ignore

I'd add .nvmrc and .npmrc if you work with NodeJS.

The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.

> Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.

Keys that are deleted are not gone from the git history. They’re still in the repo.

Same with giant blobs and binaries.

Secrets shouldn't be plain text in project directory >:[

> Most of the colleagues I've worked with only use "git add ." without checking first.

I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.

The repo should define rules for the repo, no? You have to hope other contributors have a similar local gitignore?

I'm not convinced people acting on muscle memory would remember to unignore the files either. They're going to lose work or have giant "oops, I forgot to commit these files" commits.

I do that for my personal projects.

Doing that on projects where I collaborate I would equate to pissing in public.

That is also why pull requests are such a great idea in general, because GIT allows one to piss in his own garden as much as they want.

Even if I could piss in my own branch I never do so when working on a project with other people.

I don't piss around my home obviously in case someone didn't get the metaphor.

Now walk through exactly what would happen when those lazy people follow this approach…

You see the issue right?

So the better alternative is for them to leave out files that should be committed?

  > people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.

> You clearly haven't seen the people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.

I’ve worked with and managed plenty of people like that and those are the people I least want doing something like this. Seeing the flotsam and jetsam of .DS_Store etc. are an early warning sign they aren’t paying any attention to what they push and the sooner that gets caught and addressed the better.

I do this. What's wrong with this approach and how should it be done correctly?

It depends. I've lost hours of work after wiping and recreating a repo that had accidentally gitignored a file I was working on, and I didn't notice until too late.

I usually have *secret in .gitignore and append .secret to any files with secrets.