Laravelプロジェクトが動かない？GitHubと.gitignoreでソースコードを失わないための確認ポイント

3年前に作ったLaravelプロジェクトを、久しぶりに動かしてみようと思った。

当時は普通に動いていたプロジェクトだったので、「GitHubにソースコードを置いてあるし、別の端末でもクローンすれば動くだろう」と、かなり気軽に考えていた。

ところが、実際に別の端末で確認してみると、思ったようにLaravelプロジェクトが動かない。

そこでGitHubにアップロードされているファイルを確認してみると、なんだか様子がおかしい。

「あれ？Laravelの重要なフォルダがない……」

そこで初めて、昔設定した.gitignoreを疑うことになった。

今回は、そんな自分の失敗から学んだ、Laravel開発におけるGitHubと.gitignoreの注意点についてまとめてみたい。

3年前のLaravelプロジェクトを別のPCで動かしてみた

プログラミングを長く続けていると、昔作ったプロジェクトを久しぶりに触りたくなることがある。

今回もまさにそれだった。

3年前には動いていたLaravelプロジェクト。

当時は一生懸命コードを書いて、「よし、動いた！」と喜んでいたものの、その後ほかの勉強や仕事などが忙しくなり、プロジェクトは長期間そのままになっていた。

いわゆる「塩漬けプロジェクト」だ。

久しぶりに見返してみると、当時の自分が何を考えてコードを書いていたのか分からない部分もある。

それでもGitHubにソースコードを保存していたので、

「GitHubから持ってくれば、また動かせるはず」

そう思っていた。

ところが、実際に別の端末へ持っていってみると、想像していたよりも大きな問題が発生した。

LaravelのソースコードがGitHubに全部あるとは限らない

今回の件で特に勉強になったのが、

「GitHubにリポジトリがある＝プロジェクトに必要なファイルが全部保存されている」

とは限らないということだ。

Gitでは.gitignoreというファイルを使って、Gitの管理対象から外すファイルやフォルダを指定できる。

例えばLaravelでは、通常GitHubにアップロードする必要がないファイルも存在する。

• vendor/
• node_modules/
• .env
• ログファイル
• Laravelのキャッシュ

こうしたファイルをGit管理から除外すること自体は、決して悪いことではない。

むしろLaravel開発では、適切な.gitignore設定が重要になる。

問題は、除外する範囲を広げすぎてしまった場合だ。

.gitignoreの設定を間違えるとLaravelの重要フォルダまで消える？

今回、昔のプロジェクトを確認していて気になったのが、.gitignoreの記述がかなり多かったことだった。

「これ、除外しすぎてないかな？」

以前から少し心配していたのだが、実際に確認してみると、その心配が現実になっていた可能性が高かった。

Laravelには、アプリケーションを構成する重要なディレクトリがいくつもある。

Laravelで重要になる代表的なフォルダ

• app/：アプリケーションの主要なコード
• bootstrap/：Laravelの起動処理など
• config/：設定ファイル
• database/：マイグレーションやシーダーなど
• public/：Web公開用ファイル
• resources/：Bladeテンプレートなど
• routes/：Webルートなどのルーティング設定

これらまでGit管理から外してしまうと、別のPCでリポジトリをcloneしたときに、Laravelプロジェクトとして必要な骨格が足りなくなってしまう。

ここは今回かなり反省したところだ。

「GitHubに置いたから大丈夫」ではなく、「GitHubに何が置かれているのか」を確認する必要がある。

Laravelの.gitignoreで除外するべきもの

Laravelでは、基本的にプロジェクトのソースコードと、環境ごとに変わるファイルを区別して管理する。

特に初心者が覚えておきたいのは、「フォルダそのものを除外する」のか、「フォルダの中の特定のファイルだけを除外する」のかという違いだ。

例えば、Laravelのキャッシュ関連では、フォルダ全体を消すのではなく、キャッシュなどの生成物をGit管理から除外するという考え方が重要になる。

代表的な例としては、

• vendor/
• node_modules/
• .env
• bootstrap/cache/
• storage/logs/

などがある。

一方で、app/、config/、routes/などを丸ごと.gitignoreに入れてしまうと、LaravelアプリケーションのソースコードそのものがGit管理から外れてしまう可能性がある。

.gitignoreは「何を消すか」ではなく「何をGit管理しないか」

ここも初心者のころには少し分かりにくいポイントだった。

.gitignoreに書いたファイルは、PCから削除されるわけではない。

あくまでGitの追跡対象から除外するための設定だ。

そのため、ローカル環境では普通に存在しているのに、GitHubには存在しないということが起こる。

今回のように別の端末でGitHubからプロジェクトを取得した場合、この違いが一気に表面化する。

GitHubにアップロードされているファイルを確認する

もしLaravelプロジェクトを別のPCで動かしていて、「なんかファイルが足りない」と感じたら、まずGitHub上のリポジトリを確認してみるのがおすすめだ。

ローカル環境だけを見ていると、必要なファイルが存在しているように見える。

しかし、そのファイルがGitによって管理されているとは限らない。

そこで、

1. GitHubのリポジトリを開く
2. Laravelのフォルダ構成を確認する
3. app/が存在するか確認する
4. config/が存在するか確認する
5. routes/が存在するか確認する
6. resources/が存在するか確認する
7. database/が存在するか確認する
8. .gitignoreの内容を確認する

という順番でチェックしていくと、原因を追いやすい。

Gitで.gitignoreの影響を確認する方法

「このファイルってGitから無視されているのかな？」

そんな疑問が出てきたときは、Gitのコマンドを使って確認できる。

例えば、特定のファイルがなぜ無視されているのか確認したい場合は、次のようなコマンドが役立つ。

git check-ignore -v ファイル名

これを使うと、そのファイルがどの.gitignoreのルールによって除外されているのかを確認できる。

.gitignoreを見ても原因が分からないときには、かなり便利なコマンドだ。

Gitは一見すると難しそうに感じるけれど、こういう調査用コマンドを少しずつ覚えていくと、トラブルが起きたときに自分で原因を追えるようになる。

一度もGitにコミットしていないファイルは復元できるのか

ここは今回の経験で特に重要だと思ったところ。

もしファイルが一度もGitにコミットされていなかった場合、GitHubやgit logを確認しても、そのファイルの中身を復元することはできない。

例えば、

app/Http/Controllers/
app/Models/
resources/views/

などに自分で書いたコードが入っていたとしても、それらが一度もコミットされていなければ、Gitにはその履歴が存在しない。

つまり、

「GitHubにないコードをGitの履歴から復活させる」

ということは基本的にできない。

この事実を知っておくことは、LaravelだけでなくGitを使う開発全般で重要だと思う。

Laravelプロジェクトが残っているなら、まず元のPCを探す

では、必要なソースコードがGitHubに存在しない場合はどうすればいいのか。

一番現実的なのは、元のプロジェクトが残っている場所を探すことだ。

例えば、

• 以前使っていたPC
• 別の作業フォルダ
• 外付けSSD
• バックアップ
• クラウドストレージ
• 古いPCの開発環境

などだ。

今回のように「3年前のプロジェクト」というケースでは、古いPCの中に残っている可能性もある。

GitHubだけを見て諦める前に、昔使っていた開発環境を探してみる価値はある。

Laravelのプロジェクト構成だけなら新しく作り直せる

もし元のLaravelプロジェクトが完全に見つからなかった場合でも、Laravelそのものの骨格を作り直すことはできる。

例えば、新しいLaravelプロジェクトを作成して、そこから必要なディレクトリ構成を参考にする方法がある。

composer create-project laravel/laravel temp-laravel

これによって新しいLaravelプロジェクトを作成できる。

そこから、

• app/
• bootstrap/
• config/
• database/
• public/
• resources/
• routes/

などの構成を確認できる。

ただし、ここで注意したい。

Laravelの骨組みを作り直すことと、自分が書いたプログラムを復元することは別の話だ。

新しくLaravelをインストールしても、3年前に自分が書いたコントローラーやモデル、Bladeファイルなどが自動的に戻ってくるわけではない。

ここは勘違いしないようにしたい。

Laravelの再構築で失わないために確認したいもの

昔のLaravelプロジェクトを復旧するときには、単純にLaravelをインストールするだけではなく、プロジェクト固有のコードを確認する必要がある。

確認したいLaravelファイル

• app/Http/Controllers/
• app/Models/
• resources/views/
• routes/web.php
• routes/api.php
• database/migrations/
• database/seeders/
• config/
• composer.json
• package.json

特にcomposer.jsonは重要だ。

プロジェクトで使用していたPHPパッケージなどの情報が記録されているため、Laravelプロジェクトを再構築するときの手掛かりになる。

3年前のLaravelプロジェクトを触って分かったこと

今回、一番勉強になったのはLaravelのコマンドそのものではなかった。

むしろ、

「ソースコードをどう管理しておくか」

という開発環境の基本だった。

3年前の自分は、「GitHubに置いておけば安心」と考えていた。

でも実際には、GitHubにリポジトリが存在していても、その中に必要なソースコードが全部入っているとは限らない。

.gitignoreの設定によって、重要なファイルがGit管理から外れていることもある。

今回の経験は、昔の自分から現在の自分へのメッセージみたいなものだった。

旅行でもそうだけど、出発するときは「まあ何とかなるだろう」と思っていても、現地に着いてから忘れ物に気づくことがある。

プログラミングも少し似ている。

「動いているから大丈夫」ではなく、「別の環境でも再現できる状態なのか」

ここまで考えておくことが大切なんだと実感した。

LaravelとGitHubを使うなら定期的に確認したいチェックリスト

今回の経験を今後に活かすため、最後にチェック項目をまとめておく。

• .gitignoreで必要以上にフォルダを除外していないか
• app/がGit管理されているか
• config/がGit管理されているか
• routes/がGit管理されているか
• resources/がGit管理されているか
• database/がGit管理されているか
• composer.jsonが保存されているか
• package.jsonが必要なら保存されているか
• .envなどの機密情報をGitHubに公開していないか
• 別の環境でcloneして動作確認できるか

まとめ｜Laravel開発では.gitignoreとGit管理を定期的に見直そう

3年前には問題なく動いていたLaravelプロジェクト。

久しぶりに別の端末で動かそうとしたことで、当時は気づかなかった.gitignoreの問題が見えてきた。

今回の経験から学んだことはシンプルだ。

• GitHubにあるからといって、必要なファイルが全部あるとは限らない
• .gitignoreは除外範囲を広げすぎない
• app、config、routesなどLaravelの重要フォルダを確認する
• git check-ignoreで除外理由を調べられる
• 一度もコミットしていないコードはGitから復元できない
• 元のPCやバックアップにプロジェクトが残っていないか確認する
• Laravelの骨格は新規プロジェクトから作り直せる
• 別の端末でcloneして動くか確認することも重要

プログラミングを始めたばかりのころは、どうしても「コードを書くこと」に意識が集中する。

でも、プロジェクトが大きくなってくると、Git、バックアップ、環境構築、依存パッケージなど、コード以外の部分も重要になってくる。

今回の「塩漬けLaravelプロジェクト事件」は、まさにそれを実感する出来事だった。

昔の自分が残したコードを、数年後の自分がもう一度動かせる。

そのためには、「今動いている」だけではなく「未来の自分が復元できる状態にしておく」ことが大切なのだと思う。