>>241
いやいや.env.example以外はコミットしちゃだめだろｗｗ
.env.dev(コミットしない）
.env.prod(コミットしない）
.env.example(コミットする)
.env(コミットしない）
が正解だろ

そもそも.env.devや.env.prodって必要ある？それらを同じサーバーに置かないだろ意味ないから
開発用のサーバーには開発用の.env
本番用のサーバーには本番用の.envがあるだけだろ

>>252
.envを履歴管理したいって要件が出てくれば、普通に >>241 みたいなやり方になると思うぞ
デメリットも特にないし

ならねーよ

>>254
他にどんな管理方法がある？
視野狭窄じゃない？

>>252
自動デプロイ回すのに
環境変数を設定する量は少なくしたいから
環境毎にenv分けて用意しとくのはよくあると思うんだが。
要らないenvが気になるならデプロイするときに除外すれば良いだけじゃない？

もう.envスレを立ててそこでやれよ

>>250
.envをリポジトリにコミットすることに関しては、合理的な理由なんてまったく無いよ。ここでの一連の会話読んでるか？

あと>>247の言い方からすると、お前は趣味でコード書いてるやつってことでOK？

バカの考え休むに似たりってことわざもあるんだから、まずマニュアル通りにやったほうが良いぞ。

今、Laravel教えているやつも、経験値ゼロなのにマニュアル通りやってくれなくて、無茶苦茶なコード書くんでスゲー苦労してる。

>>258
普通にバージョン管理の恩恵を受けると思うけど？
誰がいつどんな目的で変更を加えたのかわかるのは重要でしょ
監査とかで必要なケースもあるし

ってか、今話してるのはそういう流れなんだけど。。。

>>260
お前はGitHub使わないとバージョン管理できないのか？ローカルリポジトリて知ってる？

>>261
監査って知ってる？

>>258
.env.exampleを使えってことなんだろうけど、そこまでちゃんとする必要なければ.env直の方が手間が減って合理的
あと趣味か仕事かは関係ない、開発者が1人かどうか、環境が1つかどうか等が関係してくるだろう
1人でLaravel開発する仕事しょっちゅうある

>>261
これは思う
みんなGitHubをデフォルトと考えすぎだろ、それしか知らないニワカプログラマなのかと勘ぐってしまう

>>262
はぁ？監査のためにGitHubのリモートリポジトリにコミットする合理的な理由が何か説明してみてよ。あとお前は>>247と同一人物？

公式マニュアルや自分の知る方法だけが正しいと信じて守らない新人をバカにする
そういう輩が将来真っ先に老害になるから気を付けろよ

>>263
関係あるだろ。趣味じゃないなら、新しくジョインするエンジニアのことや、そのコードを引き継ぐことも考えて標準に寄せるべきでは？オレオレ実装やオレオレ管理なんて、他人から見たらゴミだぞ。後生大事に思ってるのは本人のみだ。

まぁ、上のやつはそもそもマニュアル読んだ上で自分のやり方を選択したわけではないと思うけどね(笑)

>>265
別にGitHubに限らんけど、チーム開発で変更履歴を証跡で残そうとするとごく普通の発想だろ
むしろ、ローカルリポジトリの履歴でどうやって監査対応するつもりなんだ？

セキュリティだのマニュアル以前に、純粋に不便だと思うんだが
.envコミットする人って、他の誰かがコミットした.envをマージする時どうしてるの？
マージするたびにローカルの変更をstashしているのだろうか。

>>266
守破離て言葉分かるか？自分のやり方で進める資格があるのはマニュアル通りやったことある人間だけだぞ。初めから好き勝手自分のやり方でやろうとするのは、ただのアホ。

>>269
>>241 読め。環境変数で読み込むファイルを指定する

>>268
本番サーバーやデプロイサーバーにローカルリポジトリ作ってシェル書いてexportすりゃ良いでしょ。そもそも.envが監査対象になるときってあるの？どういう理由？

俺以外も、.env直接使わないやり方の話してると思うんだけど、なぜ.envによる管理が合理的て未だに思い込んでるんだろ？

>>273
ローカルリポジトリ作っててソース管理するんじゃんｗ
何が言いたいんだよ

ローカルにGitLab立てるとかでもええやん
俺は管理面倒だからやらないけど

荒れてるからスレの勢いが板でダントツ1位だｗ
いいぞもっとやれ

誰か僕の>>269の疑問解決してくれませんか？

>>273
それ、自動デプロイと相性悪いだろ

>>275
お前マジで言ってる？馬鹿すぎない？

>>278
他の誰かなんていない

>>278
それ解決できるのは、頑なに.env使ったほうが合理的とか言ってるヤツだけだからなぁ。実質不可能じゃね？ここで袋叩きにあってるせいか、適当な理由つけて自分を正当化するのに必死みたいだし。

>>281
じゃあやっぱり零細、個人事業主、日曜エンジニアの人がそう言ってるだけなんですかね？

>>283
その約1名は、監査監査言ってるからなぁ。そこまで監査にこだわるわけだから、それなりの規模のある会社の末端プログラマの可能性はある。

>>280
おまえ、大丈夫か？オシリ真っ赤だぞｗ

普通に考えて>>269みたいなことになる環境ではコミットしないのでは？

うちは中小未満零細以上って感じの会社だけど、Laravelのプロジェクトは1人でやらされる

>>286
開発者が一人しか居ない以外のケースでそれってあるんですかね？
それ以外だと例えばどんな環境なんだろう…

開発者が複数いても実行環境が1つしかないってケースがあり得るぞ
うちも以前やってた
共通の開発鯖上で各人のディレクトリ分けて、DBは共通

ここまでをオレ主観でまとめると
・.envは環境定義用のファイルなので、実行環境ごとに異なる。基本的にリモートリポジトリでの管理からは外すのが快適
・.envをセキュリティ観点でソース管理から外すっていってるのはセキュリティ分かってない証拠。その観点で見たときには環境変数使う
・.envをバージョン管理したいのであれば各環境ごとのファイルを作って、環境変数APP_ENVで利用するファイルを切り替える
異論は受け付けるｗ

>>289
> 実行環境が1つしかない
えっ、そんなケースもあるんですか！
1つしかないってことは、本番、ステージング、開発、すべてを兼ねてるんですか？
めちゃ効率的だし画期的じゃないですか！
まぁちょっと危ない気もしますが笑笑
マイグレーションとかどうしてるのか気になります笑笑

>>290
.env.exampleが抜けてるぞ
テンプレ管理目的でこれをバージョン管理する
俺は今まで.envをコミットしていたが今後そうするつもり

>>291
開発中にちょっと構文ミスっただけで、本番はデバッグ用のスタックトレース出てくる状態を想像したら草

>>291
さすがに本番鯖は別にあります
開発鯖の中でディレクトリを分けて、
https://開発鯖ドメイン/開発者1
https://開発鯖ドメイン/開発者2
https://開発鯖ドメイン/masterの動作確認用
みたいにアクセスしてた

>>292
いいね。お前みたいなのが居てくれると、ここでしつこく言った甲斐があるなぁ。

>>292 さんきゅ

まとめ直した
1 ..envは環境定義用のファイルなので、実行環境ごとに異なる。基本的にリモートリポジトリでの管理からは外すのが快適
2 .envをセキュリティ観点でソース管理から外すっていってるのはセキュリティ分かってない証拠。その観点で見たときには環境変数使う
3 各環境の..envのテンプレは.env.exampleを使用すると良い
4. .envをバージョン管理したいのであれば各環境ごとのファイルを作って、環境変数APP_ENVで利用するファイルを切り替える

4はもうちょっと突っ込む必要があるかなぁ。他のフレームワークでもよく見る方法だけど、Laravelでデメリットはないのか、実際に使っている人のコメントがほしい

>>296
セキュリティの観点でいうと、やはりリポジトリに置かないほうが安全だと思ってしまったんですが、これやっぱり浅いですかね？
僕のところだと.envはignoreされてるので、ここで言うところの「コミットしない派」に含まれるんですよ。
だから新人の僕は本番のDBやRedisの接続情報、外部サービスの秘密鍵なんかは当然知らなくて、リリース担当者とマネジャーの人だけが知ってます。
その人たちは接続情報などは別のツールで管理してるっぽいです。
でも僕含めた他の多くメンバーは各自がDockerで用意すればいいだけなので困ることもないですね。
（もちろん.env.exampleは用意されてますよ）

で、それをignoreしてる理由は、正直ほかの皆のように深く考えたことなかったです笑

でも、その全員が本番のDBやRedis、その他にアクセスできると責任の所在が明確では無くなるのが問題だから除外されてるのかなって漠然と思ってました。
これはみんなの感覚で言うとずれてるんですかね？

>>297
個人的には浅くないと思うけどな
それぞれいろんな理屈はあるにせよ、セキュリティの観点は看過できないとは思う

.envをコミットする人たちってもしかして.idea等IDEが自動生成するフォルダも
コミットしているのか？

>>297
セキュリティ観点で考えるなら、ちゃんと「何を何からまもるか」って検討しないと意味がない

Laravel以外も含む一般論としては、「.envとかconfigファイルとかに機密情報は記載せず環境変数で提供する」ってことになると思うけど、これはミドルウェアの管理者が接続情報を管理すべきって発想が根底にあるので、そこに乗れない環境であるなら自前のポリシーとガイドラインを設計する必要がある

昔は環境変数が主流だったけど、今はインフラやミドルウェアの仕様がかなりトリッキーなシステムもあるので、よりインフラ別な管理手法になって行くんじゃないかなぁ