>>291
そんなケースざらにあるぞ
特に顧客側がサーバを用意する案件だと本番環境サーバしか用意してもらえないことがある
今までの個人的な感覚だと大学案件にそれは多くてテスト環境サーバも用意してほしいと言っても
予算だったり仮想ホストサーバのリソースの都合等でテスト環境は断られることが多い

>>300
そもそもLaravelが.envをセキュリティを理由に管理対象外にしているのは事実だし、実際のところ不用意にクレデンシャル入りの.envをpushするエンジニアが居てたまにネタになってたりする。

お前の言ってることは正論だけど、その議論が成り立つほどLaravelを使っている奴らの意識は高くないので(中央値の問題ね)、.envを管理対象外にしておくことはセキュリティ観点から妥当な対応と評価できると思う。

>>302
300だけど、ぶっちゃけクレデンシャル入りの.envを管理対象に含めても、関係者以外に非公開であればセキュリティポリシー的に問題になるケースは少ないはずなんだよなぁ＾＾；

ので、.envをバージョン管理すべきかどうかの議論はセキュリティ観点抜きで、「環境ごとに用意されるべきものだから共通管理すんなよ」で良かったんじゃないかと思う

>>300
「.envとかconfigファイルとかに機密情報は記載せず環境変数で提供する」というのはまた別の話だと思います。
それは一旦切り離して考えませんか？
今は論点が多分3つ4つくらいあって、こうだと思います。

- 論点A: .envをリポジトリで管理する是非
　- 論点A-1: 開発の利便性における観点
　- 論点A-2: セキュリティにおける観点
- 論点B: 機密情報を環境変数で提供することの是非

この論点Aと論点Bは近しい話かもしれませんが、同時に論じることってできないですよね？
論点Bを肯定するには、論点A-2が否定されている前提になると思うので。

零細勤め、個人事業主、日曜エンジニア、>>205「「.envをコミットしても問題ない環境なんて山ほどある！！」」

>>305
ナンダこの周回遅れ君。スレのみんなはステップ一つ上がってるぞｗ

お前らどーでもええことで長いこと揉めてんなあ
ちゃんと動くもの作れているのかいな

つまり話をまとめると、基本的に.envはコミットしちゃ駄目だけど、
俺みたいな小規模開発オンリーのエンジョイ勢みたいな場合はコミットしてもそんなに害は無いってことでいいか？

>>308
それで良いと思うよ
個人なら好き勝手にやればええ、責任取るのは自分なんだし
おれは個人でもコミットしないけどね

>>308
そのやり方が普通であるかのように喧伝したり、他のエンジニアを巻き込むようなことをしないのであれば、好きにしたらええんちゃう。

まぁ俺も同じく個人開発用のリポジトリであっても.envはコミットしないけど。コミットする理由が無いので。

>>57からここまで話引きずったってマジ？

>>311
俺には面白かったけどなぁ

俺主観でもう一度整理した

1 .envは環境定義用のファイルなので、実行環境ごとに異なる。ので、基本的にリモートリポジトリでの管理からは外すのが快適
2 .envをセキュリティ観点でソース管理から外すっていうのは「機密情報は環境変数で管理するべし」ってベストプラクティスを知ったうえで判断する
3 各環境の.envのテンプレは.env.exampleを使用すると良い
4 .envをバージョン管理したいのであれば各環境ごとのファイルを作って、環境変数APP_ENVで利用するファイルを切り替えると快適

4はキャッシュあたりに落とし穴ありそうなので、経験者のコメントがほしいよー

>>307
どうももよいことではない

クローンしたらすぐ動くって素敵やん

>>314
ね、頑なに.envを外したがる奴って意識高すぎだろw
細かいこと気にしすぎだし絶対童貞だろw

どうでもよくはないけど拘る所でもないよな

意識高いとか笑える
むしろ逆でコミットする方が意識高いと思うが

>>315
結論は>>308-310あたりでもう出てると思っていて、それをわざわざ掘り起こして人格否定煽りはみっともないと思います。

頑なに「頑なに.envを外したがる」というのが間違いで、
このスレを読んでいる限り、外す人は
「私のプロジェクトでは外しますが、あなたのプロジェクトなら好きにしてください。おすすめしませんけど。」
というスタンスの方が多いと思います。（僕含めて）

むしろデフォルトで外れている以上、まず外す前提があって、拘りがあって.envをリポジトリに入れる。
というあなたのスタンスの方が、あなたがいう「細かいことを気にしすぎ」に合致しませんか？


ちなみに「クローンしたらすぐ動く」という意見もちょっと微妙で、
実際には、
・Dockerコンテナの作成
・パッケージマネージャでプロジェクトのインストール（バックエンド、フロントエンド共に）
・DDL/DMLの反映（マイグレーション）
という作業が "最低限" まだ残っているので、.envを入れたからすぐに動くというのは違うと思います。

むしろ「他開発で使っているポート番号が競合しているけど、環境ごとに変更できないから動かない」なんて問題も起きかねないと思います。
つまり.envを入れておくとクローンしてすぐ動くわけでもないと思いました。

.envコミットしとけばクローンしてすぐ動くじゃんとか主張しているやつは、vendorディレクトリもnode_modulesディレクトリも好き勝手コミットしてそう。

>>318
それなー。Laravelがあえて外しているものをわざわざ自分流にアレンジして管理しようとするっていうね。で、理由を聞いてもまともな答え返ってこない。

>>319
正解。Laravel本体とかnodeのパッケージに手を入れてるからリポジトリに含めてる

零細って言われたのが効いたのかなぁ

>>319
メモリ1GBの鯖でcomposer動かしたら鯖が死ぬので使えないから、vendorもリポジトリに入れてデプロイに含めてる

もしかして、サーバーに入ってgit pullすることをデプロイと呼んでいる？

>>324
手でgit pullと打つわけじゃないけどデプロイスクリプトがgitのmasterを引っ張ってくるようになってるから実質そう

基本本番環境は外部ネットワーク接続禁止だから
vendorもnode_modulesもコミットしてるな

>>323
そんなことでサーバ死ぬ方がおかしくないか？
sawp切られてないとかじゃないの？

>>234
この発言全国の.envコミットチー牛にぶっ刺さりまくって草

>>327
swapも作ってるんだけどI/Oがアホみたいに遅いみたいで、物理メモリ切れると数時間鯖が死んだように瀕死になって再起動するしかなくなる
Lightsailでそうなるんだけど俺だけ？普通にCentOS7入れてるだけなんだが

うーん。デプロイサーバーまたは手元のPCでデプロイスクリプト流すとcomposer installとか一連の処理を行い、そのあと本番サーバーにrsyncみたいなやり方もある。

だから、デプロイのためにリポジトリ管理するってのは違和感あるけど、実はそのほうがメジャーなのか？

>>330
今後はそんな風にしようと思ってる。やはりrsyncがよさそうだよな。
リポジトリから引っ張ってくるのとどっちがメジャーなんだろ。Deployerってのを使ったことあるがあれは毎回git checkoutしててファイルが多いと死ぬほど遅かった。

>>323
こっちの可能性もあるかもね
http://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors

零細社畜がイキるスレはここですか？

でもお前無職じゃん

でもお前童貞じゃん

いろいろ刺さってるんだね独身さん

>>336
laravel-mix使ってそうw

たまにはまともな技術の話しようぜ。お前らもうすぐリリースされるlaravel-octane使う？使わない？

laravel-mix使ったらダメなん？
laravel-mixって何だっけ

君たちパッケージマネージャー管理下のファイルをリポジトリに突っ込んでたのか
びっくり仰天だこりゃ

Laravel-Mixは手軽でええやん
使える案件なら使えば良いと思うよ
何でもかんでも否定するのも良くないね

>>340
当たり前だろ
まず.gitignore自体が俺のとこじゃそもそも存在しねーよ
IDEの設定ファイルもみんなで共有するのが基本だぞ

そもそもGitなんて使ってねーし
.gitignoreをignoreしたったるわ

>>342
いや後者は普通にあり得るけど(.editorcofgみたいなのもあるし)、前者はおかしいだろ。てか、何のためにlockファイルがあると思ってるんだ・・・。

そもそもvendor以下はcomposer、それ以外はGitなりSVNなりで分けて管理するっておかしいだろ
ソースチェックアウトしたものが動くという保証がなくなるじゃん
実際composerはメモリバカ食いするしエラー出されたらお手上げ、イマイチ信用できない

開発環境のPHPのバージョンすらも不明な状態なのにgitからチェックアウトするだけで必ず動くと思えるのはお花畑すぎる。それにお前のやり方だと、開発のみのパッケージとかどうすんの？

composerってそんなにメモリバカ食いなの？
php.ini触れない環境とかだと苦しいのか

>>332を見ると1.5Gか無制限にしろと書いてあるな
memory exhaustedでFatal Errorは俺も出たことある

つーかそもそも普通にcomposer使えない環境もあるんちゃうの
そういう場合自分でvendor管理してアップロードするしかなくない？

>>347
引数で使用するメモリは増やせる。あとたぶんここでcomposerガーて言ってる人は、composer2使ってない人。