追記

コメントにて補足頂きました。
Laravel5からは.env.{APP_ENV}に環境ごとの設定を記載する形になっていたようです。

当該ソースはこの辺。

流儀に沿うなら、環境ごとの.envを用意するのが正しいかも。

本編

Laravel4のときは、config以下にenvironment名ごとのconfigファイルを置いておけば環境変数によってconfigを切り替える機能があったようだが、（参考： http://www.1x1.jp/blog/2014/09/laravel-environment-config.html ）Laravel5ではこのような機能はなくなっていた。

なぜ5でなくなってしまったのか（と言うか本当になくなってしまったのか）、
思想的な部分がわからないので若干不安はあるが、プロジェクトであったほうがよいという話になったので作成した。

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class ConfigServiceProvider extends ServiceProvider
{
    public function register()
    {
        $env = \App::environment();
        $env_config = \Config::get($env);
        if($env_config && is_array($env_config)) {
            \Config::set(array_replace_recursive(\Config::all(), $env_config));
        }
    }
}

こんな感じでServiceProviderを作って、app.phpのprovidesで読み込むだけ。

ディレクトリ構成は以下のようにする。

config/
- local/
  - .gitkeep
  - database.php
- development/
- testing/
- staging/
- production/
- app.php
- database.php
- ...etc

localだけ中のPHPファイルを.gitignoreしておいて、config直下には、基本となる設定を記載する。
それぞれのディレクトリ内には、上書きしたいconfigと同じ名称のphpファイルを置き、中には変更したい内容のみを記載していく。

現在のプロジェクトでは、

local: 各開発者のローカルマシン環境
development: 共通サーバー上での動作環境
testing: PHPUnit実行時の環境
staging: ステージングサーバー用
production: 本番サーバー用

という切り分けにしている。

改善が考えられる点

この書き方だと…config cacheした場合に、productionでも毎回マージ処理入るのでcacheの恩恵が減るかもしれない。
そういう意味では、productionではconfig直下の設定にはproductionの値を書いておいて、
productionの場合にはConfigServiceProciderを読まないような仕組みにしておいた方が動作は軽くなる、かもしれない。

というか、config cacheってサブディレクトリも対象になるんだろうか。
その辺を考慮してまだ改良の余地はあるかも？
（但し、config cache自体どれくらい恩恵のあるものなのかも試さないとわからないけどな）
（サブディレクトリも含めて1ファイルになるんなら、array_replace_recursiveのコストが無視できるものなのかどうか）

Laravel5における環境毎のconfigの上書き

追記

本編

改善が考えられる点