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.

That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens.

It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.

In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.

One problem I see all the time is that people are not using proper tools.

Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs.

Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging.

People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer.

I recommend looking here: https://git-scm.com/tools/guis

(it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience)

You’re not wrong. I’ve used tig, a git TUI that renders very nice views of the diffs, for many years: https://jonas.github.io/tig/

Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!

If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore

Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?

But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.

> 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.

That's the horror..

Genuinely curious - do you all not have a code review process, or do the reviewers just not care?

Pull requests in github are against branches, so keys and binaries are in the repo even if removed during review.

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.

Git becomes a lot easier to understand once you learn its "hidden" interactive flags

Like git rebase -i as well