Are .env files meant to be source-controlled or not?

[TWolversonReply]

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.

[christiannagel]

With a .NET Aspire project, using azd init, a .gitignore file is created to exclude the .azure directory.

[vhvb1989]

.env is not expected to be ever committed.
As @christiannagel mentioned, azd is adding the .azure folder (containing all azd-environments) to the .gitignore.
In the future, azd should be adding a .gitignore inside the .azure folder. See: #2755

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?

A classic approach for using azd within a team is:
a) Every developer in the team would have their own azd-environment.
b) Then, the repo would have a CI/CD configuration to produce a staging version for the project.
C) Finally, there might be a few alternatives for publishing the code to production.

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.