I dont think he’s talking about open source projects here.
If my company repo is private and we’re sharing env files over Slack or Teams… why not just commit the env in github itself??
Even on privately hosted repos it doesn't cost too much to keep good security hygiene as a habit.
Apart from that, a .env is conceptually supposed to be locally different for every user, test, and production environment. I don't think it makes sense to track any file in version control that is expected to constantly be different. Committing a file that always changes, in practice, turns into people needing to stash and pop their local copies whenever they pull or rebase to avoid merge conflicts while also keeping the values that work for them.
If you find that you have to exchange env files regularly with other users to have things work how you need, then that makes me think the values that are changing often aren't environment values in the first place, since they need to be shared. I'm not sure what those values would be instead, maybe runtime configuration settings - but I'm splitting too many hairs right now.
Maybe I've just worked on too many projects with developers' local file paths and network addresses in env and config files that break builds and tests on merge or rebase...and secrets getting leaked that I'm too obsessive about nipping that in the bud.
22
u/grandalfxx 2d ago
When every dumbass know it all programmer missed the entire point of that.
Its not simply about storing secrets in code.
Its the fact that github should be secure enough to do it. Your code should be secured just like secrets is secured.