まとめてみた

・.envは環境を定義するためのものなので環境ごとに異なる。各環境に直置きし、ソース管理に含めないのがお手軽
・定義すべき内容（テンプレート）は.env.exampleで共有すると良い（こちらはソース管理に含む）

とはいっても.envを管理対象に含めたいプロジェクトはそこそこある
以下の対応をすると良い

＊機密情報の取り扱いに関して
厳密には、.envを管理する/しないとｂﾍ関係がないが＝A以下のように瑞ｮ理すると良い
・どのような立場の人から情報を守りたいのかを定義し（セキュリティポリシー）、その対応としての実装を行う（ガイドライン）
・公式ドキュメントには、「source control repository」からの流出が一例として載っているが、その想定は一般的ではないのでポリシー設計時には自システムに対応した脅威を整理すること
・ルールで縛られることも多い。例えば「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」とか
・実装方法は、.envに記述する/環境変数を使用する/変数として管理しデプロイ時に上書き等々あるが、ポリシーとセットで語られるべき内容なので省略

＊.envファイルの管理方法
以下のような実装方法がある模様
・環境ごとのファイルを用意して、環境変数APP_ENVで切り替える（注：defining a server-level APP_ENV）
・各環境のローカルリポジトリとして管理
・共通の.envを用意して部分的に環境変数で上書き
・共通の.envが使用できるように、デプロイ先の環境をそろえる