Question: How to handle other environments?

[MincheolC]

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?

[devskope]

logically, a .env-sample file could be committed showing the variables that should be set in real environments.

[jackson-elfers]

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.

[MincheolC]

@jackson-elfers @devskope I see. Thanks for your reply~:D