Are .env files meant to be source-controlled or not? #3168
Replies: 2 comments
-
With a .NET Aspire project, using |
Beta Was this translation helpful? Give feedback.
-
.env is not expected to be ever committed.
A classic approach for using The use case you mentioned sounds like you would want to re-use an azd-environment from within your team. That would allow you to use the same infrastructure, but it would require some synchronization in the team, as you might be testing your changes while someone else publishes their changes to the same infrastructure (using the same azd-env) and changes what you were expecting on the running application. |
Beta Was this translation helpful? Give feedback.
-
It would seem that if .env files can contain any configuration, that might include secret values, and that's a bad thing to be in source control. Most of the documentation is oriented around explaining a workflow where the developer creates the solution structure with the .env file their environment requires, so it's assumed to always be there. What if I clone my colleague's Azd-compatible solution from a remote repo; should I expect .env to be there, or is the expected workflow that I have to run
azd env get-values
to initialise my copy with the same config that they have? Dotnet developers for example may not be familiar with the .env file convention and won't know that they have to exclude it from their git commits, if that's the case. It would be helpful if the documentation would spell out very clearly the expectation of how .env is supposed to be used.Beta Was this translation helpful? Give feedback.
All reactions