You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi~. You said that "Put a .env file, that must never be committed" in your article.
Then how do you handle other environments like production, test, etc??
If each branch has different .env and not committed, then how do other members know .env info? and how do you deploy them?
The text was updated successfully, but these errors were encountered:
There should be a list of required .env keys (without values) as a courtesy. When we're making changes to the .env we should be aware to document which keys we've added or subtracted whether it be on the readme or a .env-sample as @devskope suggests. For deployment, it depends upon the hosting, usually it's a matter of supplying our production .env for our application to use. Keep your dev/prod .env in a secure place at all times and far away from github.
Hi~. You said that "Put a .env file, that must never be committed" in your article.
Then how do you handle other environments like production, test, etc??
If each branch has different
.env
and not committed, then how do other members know.env
info? and how do you deploy them?The text was updated successfully, but these errors were encountered: