Best practices for managing and storing secrets like API keys and credentials

Re:Best practices for managing and storing secrets like API ... by jacoblambda on Saturday June 13, 2020 @02:19AM (#23507272)

I'm curious why people use "git add ."? I don't see the convenience over "git add -i" and quickly reading through the items to add.

Realistically if you have a reasonable git workflow any add operation should only have a handful of files that you can quickly scan through to make sure nothing fishy is present and at most interactive mode adds a few seconds to the add process for you to read through everything.

Note: This is an entirely serious question and I am hoping for an answer. I promise I'm not trying to antagonise anyone. I just see so many people reaching for "add ." instead of "add -i".

[ Parent | on HN ]

Re:Best practices for managing and storing secrets like API ... by closeparen on Saturday June 13, 2020 @05:50AM (#23508257)

Keeping a file untracked is never what I want. Either it goes in the repo or it goes in .gitignore. My gitignores are usually comprehensive, and when they're not I'll catch it in my self-review of the PR.

[ Parent | on HN ]

Re:Best practices for managing and storing secrets like API ... by jacoblambda on Saturday June 13, 2020 @01:21PM (#23510981)

That's fair but isn't it more work to go back and have to rebase your commits to remove something that accidentally got skipped in your .gitignore?

I say this because I am also a firm believer of if it shouldn't be committed it should be in the .gitignore but I've only ever been burned by that when either myself or others weren't using interactive add.

Basically, isn't it easier to fix a .gitignore at commit time than at PR time?

[ Parent | on HN ]