this post was submitted on 07 Jun 2024
533 points (98.4% liked)
Technology
59495 readers
3041 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If you have your secret keys in your repository you've already fucked up, long before you accidentally make that repository public.
One of the first things you should do in a repo is add a .gitignore file and make sure there are rules to ignore things like
*secret*
or*private*
etc. Also, I pretty much never usegit add .
because I don't like the laziness of it and EVERY TIME one of my coworkers checked in secrets they were using that command.Better yet you can configure gitignore globally for git. I do this mostly to avoid polluting repo ignore files with my editor specific junk but *.key and similar can help prevent accidents.
https://git-scm.com/docs/gitignore
For personal projects that's definitely a good idea. For team projects I like to keep that stuff in the project still so the "experience" of working in the project is mostly consistent.
I started using git-secret 2 years ago. It's nice for making secrets part of the repo, while not being readable by anyone that isn't explicitely allowed to do so (using GPG).
I think you really need the project specific gitignore as well, to make sure any other contributor that joins by default has the same protections in place.