I see no point in the general advice, not to commit a .env-file per se: I do it frequently and wondered what this post is about.
It is not about committing a standard configuration in your repo, which could be overriden e.g. by a .env.local. It is about not storing secrets in your repository. That's another topic and indeed best practice.
So my usage of .env seems to differ: providing a sane default configuration, which can and should be overridden and does not contain any secrets whatsoever.
For managing secrets in a repo there is an interesting approach by stackoverflow: github.com/StackExchange/blackbox
which unfortunately I had not the time trying, but looks interesting.
Yes, it's definitely okay to commit the .env file if and only if they contain general and not-so-sensitive information. Otherwise, the point of this article is to remind people that they should think twice before they commit .env files because of the serious ramifications that come with it.
The only thing I don't like about doing this is that when I change the defaults, they now show up as a diff. On some of my smaller projects I SSH onto the server and just pull the latest changes, so if I've made a change to my default .env file I have to worry about conflicts. I can avoid this problem in production by having the defaults be my production settings, but then I constantly have a dirty file in development.
The best solution to this in my opinion is to not commit .env and instead commit a .env.example. Then all you have to do is cp .env.example .env and you have the exact same things as before but without a dirty file when you change settings.
Hmmm. Interesting. I came into first contact with .env files via vuejs. It seems there, that you have a .env file which acts like your ".env.example" and could have a .env.local which contains overrides.
But doing some research that seems an uncommon practice 🤔
Mostly there is one .env and it isn't committed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I see no point in the general advice, not to commit a
.env-file per se: I do it frequently and wondered what this post is about.It is not about committing a standard configuration in your repo, which could be overriden e.g. by a
.env.local. It is about not storing secrets in your repository. That's another topic and indeed best practice.So my usage of
.envseems to differ: providing a sane default configuration, which can and should be overridden and does not contain any secrets whatsoever.For managing secrets in a repo there is an interesting approach by stackoverflow: github.com/StackExchange/blackbox
which unfortunately I had not the time trying, but looks interesting.
Yes, it's definitely okay to commit the
.envfile if and only if they contain general and not-so-sensitive information. Otherwise, the point of this article is to remind people that they should think twice before they commit.envfiles because of the serious ramifications that come with it.The only thing I don't like about doing this is that when I change the defaults, they now show up as a diff. On some of my smaller projects I SSH onto the server and just pull the latest changes, so if I've made a change to my default
.envfile I have to worry about conflicts. I can avoid this problem in production by having the defaults be my production settings, but then I constantly have a dirty file in development.The best solution to this in my opinion is to not commit
.envand instead commit a.env.example. Then all you have to do iscp .env.example .envand you have the exact same things as before but without a dirty file when you change settings.Hmmm. Interesting. I came into first contact with .env files via vuejs. It seems there, that you have a .env file which acts like your ".env.example" and could have a .env.local which contains overrides.
But doing some research that seems an uncommon practice 🤔
Mostly there is one .env and it isn't committed.