Cara Membuat .gitignore untuk Project Laravel (+ Penjelasan Lengkap)

Kebanyakan developer baru mengenal .gitignore saat pertama kali commit file yang seharusnya tidak pernah masuk repository. Di project Laravel, file yang salah commit bukan cuma sekadar mengotori repository — bisa jadi itu .env yang berisi password database dan API keys. Sekali ter-push ke repository publik, kredensial itu bocor ke internet.

Artikel ini membahas cara membuat dan memahami .gitignore untuk project Laravel: sintaks dasarnya, isi default dari template Laravel, mengapa .env di-ignore tapi .env.example justru di-track, sampai cara memperbaiki file yang sudah terlanjur ter-commit.

Contoh isi default yang dipakai di artikel ini diambil dari skeleton Laravel terbaru. Kamu perlu tahu bahwa file .gitignore bawaan antara Laravel 12 dan Laravel 13 tidak identik — skeleton 13 menambahkan beberapa entri baru. Kalau kamu baru menjalankan composer create-project belakangan ini, kemungkinan besar skeleton yang kamu dapat adalah Laravel 13. Kalau project-mu masih di Laravel 12, perbedaannya kecil dan dibahas di akhir artikel.

Apa Itu .gitignore dan Kenapa Laravel Membutuhkannya

.gitignore adalah file teks yang memberi tahu Git file dan folder mana yang tidak boleh masuk ke tracking. Isinya baris-baris pola (pattern), dan setiap baris adalah aturan untuk mengecualikan satu file, satu folder, atau satu tipe file sekaligus.

Kebanyakan project Laravel modern berisi ribuan file, dan sebagian besar di antaranya sebenarnya tidak perlu disimpan di Git. Bayangkan tiga kelompok berikut:

File yang sensitif. .env berisi kredensial — database password, mail password, dan API keys. Kalau masuk repository, orang lain bisa membacanya.
File yang besar dan bisa dibuat ulang. vendor/ bisa berbobot puluhan sampai ratusan megabyte, tapi isinya hasil composer install. Siapa pun yang clone repository bisa membuat ulang folder itu dengan satu perintah.
File hasil build. Output Vite di public/build, file log, dan cache — semua ini tidak ada gunanya di-commit karena bisa dibuat ulang kapan saja.

Tanpa .gitignore, repository Laravel cepat membengkak, dan risiko kebocoran kredensial meningkat drastis. Satu file kecil di root project bisa menyelamatkan banyak masalah.

Cara Membuat File .gitignore di Laravel

Kalau project Laravel kamu dibuat lewat composer create-project, file .gitignore sebenarnya sudah tersedia secara otomatis:

composer create-project laravel/laravel nama-project

Template default dari package laravel/laravel sudah cukup baik untuk kebanyakan project. Jadi untuk sebagian besar kasus, kamu tidak perlu membuat dari nol — cukup memahami isinya lalu menyesuaikan kalau ada kebutuhan khusus.

Kalau kamu memang ingin membuat file baru (misalnya project lama yang belum punya .gitignore), cukup buat file kosong bernama .gitignore di root project menggunakan text editor atau terminal:

touch .gitignore

Catatan kecil: perintah touch, cp, dan sejenisnya memakai sintaks shell Unix. Di Windows, jalankan lewat Git Bash atau WSL — atau lewati saja dengan membuat file lewat text editor.

Lalu isi dengan aturan yang kamu butuhkan. Sebagai titik awal, kamu bisa melihat template yang disediakan GitHub di repository github/gitignore (file Laravel.gitignore). Tapi perlu dicatat: template GitHub itu mencakup pola untuk Laravel 4 dan 5 yang sudah usang. Template bawaan laravel/laravel lebih modern dan spesifik, jadi lebih aman dipakai sebagai dasar.

Memahami Sintaks Dasar .gitignore

Sebelum bedah isi default Laravel, ada baiknya paham dulu bagaimana Git membaca pola ignore. Ini yang membedakan .gitignore yang berfungsi dengan yang cuma "jalan-jalan".

Komentar dan baris kosong. Baris yang diawali # adalah komentar, diabaikan Git. Baris kosong juga diabaikan — biasanya dipakai sebagai pemisah agar file mudah dibaca.

Wildcard. * cocok dengan semua karakter kecuali garis miring /. Jadi *.log cocok dengan semua file berakhiran .log di kedalaman mana pun. ** cocok dengan beberapa direktori sekaligus, misalnya **/foo cocok dengan foo di mana pun letaknya.

Posisi garis miring menentukan cakupan. Ini bagian yang sering bikin bingung:

# Anchored ke root — hanya cocok dengan vendor/ di root project
/vendor

# Tidak anchored — cocok dengan semua folder bernama node_modules di kedalaman mana pun
node_modules

Pola yang diawali garis miring / hanya cocok relatif terhadap lokasi file .gitignore (biasanya root project). Pola tanpa garis miring di awal cocok di mana saja dalam tree. .env tanpa garis miring, misalnya, cocok dengan /.env, /subdir/.env, dan seterusnya.

Catatan: contoh node_modules di atas sengaja tanpa garis miring supaya terlihat perbedaannya dengan /vendor. Template default Laravel sendiri memakai bentuk anchored (/node_modules), karena dependency JavaScript selalu ada di root project — kamu bisa bandingkan dengan isi default di bagian bedah detail.

Garis miring di akhir berarti direktori. vendor/ hanya cocok dengan direktori bernama vendor, bukan file dengan nama yang sama.

Negation (tanda seru !). Baris diawali ! membatalkan aturan ignore sebelumnya untuk file tertentu. Misalnya:

*
!.gitignore

Artinya: ignore semua isi folder ini, kecuali file .gitignore itu sendiri. Pola ini yang dipakai Laravel di dalam folder storage (dibahas nanti). Satu catatan penting: ! tidak bisa memaksa file ikut ter-track jika direktori induknya sudah di-exclude terlebih dahulu.

Satu hal yang wajib diingat: .gitignore hanya bekerja pada file yang belum di-track (untracked). File yang sudah pernah masuk repository tidak terpengaruh — kamu perlu git rm --cached untuk mengeluarkannya. Detail ini dibahas lebih lanjut di bagian troubleshooting.

Bedah Detail File .gitignore Default Laravel

Saat menulis artikel ini, versi stabil Laravel adalah Laravel 13 (dirilis 17 Maret 2026). File .gitignore bawaan di skeleton Laravel 13 berisi 27 entri — sedikit lebih banyak dari Laravel 12 (24 entri). Blok berikut adalah isi default dari skeleton Laravel 13:

*.log
.DS_Store
.env
.env.backup
.env.production
.phpactor.json
.phpunit.result.cache
/.codex
/.cursor/
/.idea
/.nova
/.phpunit.cache
/.vscode
/.zed
/auth.json
/node_modules
/public/build
/public/fonts-manifest.dev.json
/public/hot
/public/storage
/storage/*.key
/storage/pail
/vendor
_ide_helper.php
Homestead.json
Homestead.yaml
Thumbs.db

Semua entri sudah disusun alfabetis sejak Laravel 12. Berikut penjelasan fungsi tiap kelompok.

Dependencies: /vendor dan /node_modules

/vendor
/node_modules

vendor/ berisi dependency PHP yang dipasang lewat Composer, sedangkan node_modules/ berisi dependency JavaScript dari NPM atau Yarn. Keduanya besar dan bisa dibuat ulang dengan composer install dan npm install. Tidak ada alasan untuk menyimpannya di Git.

Kedua pola ini diawali garis miring, artinya hanya cocok dengan folder di root — bukan di subfolder mana pun dalam tree. Ini tidak menjadi masalah karena dependency di project Laravel memang selalu terpasang di root.

Environment dan Secrets: .env dan Variannya

.env
.env.backup
.env.production

.env berisi konfigurasi environment yang spesifik per instalasi, termasuk password dan API keys. Ini file yang paling berbahaya kalau ter-commit, dan dibahas khusus di bagian berikutnya. .env.backup dan .env.production adalah varian yang juga disertakan agar tidak terlewat.

Runtime, Cache, dan Log

*.log
.phpunit.result.cache
/.phpunit.cache
/storage/*.key
/storage/pail

*.log mencakup semua file log — log aplikasi Laravel, npm-debug.log, yarn-error.log, dan seterusnya. Ini pengganti dari aturan spesifik di Laravel 11 yang hanya mencantumkan npm-debug.log dan yarn-error.log.

.phpunit.result.cache (untuk PHPUnit versi lama) dan /.phpunit.cache (direktori cache untuk PHPUnit 10+) adalah file hasil proses testing. /storage/*.key melindungi encryption key di dalam folder storage. /storage/pail adalah file runtime dari Laravel Pail, tool real-time log viewer.

Frontend Build Assets

/public/build
/public/fonts-manifest.dev.json
/public/hot
/public/storage

/public/build adalah output dari npm run build (Vite). File hasil build selalu dibuat ulang, jadi tidak perlu di-commit. /public/hot adalah file marker yang dibuat Vite saat menjalankan Hot Module Replacement (npm run dev) — file ini hanya ada ketika development server berjalan.

/public/fonts-manifest.dev.json adalah file manifest font yang dibuat oleh Vite saat development (terkait penanganan font di project). File ini bersifat generated dan tidak perlu di-commit.

/public/storage adalah symbolic link ke storage/app/public, yang dibuat via perintah php artisan storage:link. Karena itu file symlink, jelas tidak boleh di-commit.

IDE dan OS Files

/.codex
/.cursor/
/.idea
/.nova
/.vscode
/.zed
.phpactor.json
_ide_helper.php
.DS_Store
Thumbs.db

Group ini mencakup pengaturan editor dan file sistem operasi. /.idea milik JetBrains IDE (PhpStorm, IntelliJ), /.vscode milik Visual Studio Code, /.nova milik editor Nova, dan /.zed milik Zed. .phpactor.json adalah konfigurasi LSP Phpactor.

Dua entri yang baru ditambahkan di Laravel 13: /.codex dan /.cursor/, yang merupakan direktori konfigurasi untuk tool AI coding (Codex dan Cursor). Keduanya berisi pengaturan yang spesifik per developer, jadi tidak cocok untuk di-commit ke repository bersama. _ide_helper.php adalah file generated oleh package laravel-ide-helper — file ini sering otomatis dibuat ulang dan biasanya tidak perlu di-commit.

Di sisi OS, .DS_Store adalah metadata folder macOS dan Thumbs.db adalah cache thumbnail Windows. Keduanya baru muncul di Laravel 12 — versi 11 tidak menyertakan keduanya secara default.

Legacy dan Auth

/auth.json
Homestead.json
Homestead.yaml

/auth.json berisi kredensial autentikasi Composer untuk repository privat — termasuk data sensitif. Homestead.json dan Homestead.yaml adalah konfigurasi Laravel Homestead yang sifatnya spesifik per developer.

Mengapa .env Di-ignore tetapi .env.example Di-track

Ini pertanyaan yang paling sering muncul. Jawabannya ada di perbedaan fungsi keduanya.

.env adalah file konfigurasi nyata yang berisi nilai sensitif: database password, mail password, APP_KEY, dan API keys. Setiap environment — lokal, staging, production — punya .env yang berbeda. Kalau file ini masuk repository, semua orang yang punya akses ke repository bisa membaca kredensialmu. Kalau repository-nya publik, kredensial itu terekspos ke seluruh internet.

.env.example kebalikannya. Ini bukan konfigurasi nyata, melainkan cetak biru yang menunjukkan environment variables apa saja yang dibutuhkan project. Isinya cuma placeholder dan nilai default — tidak ada yang sensitif. Fungsi utamanya membantu developer baru memahami konfigurasi apa yang harus dibuat saat pertama kali setup project.

Karena itulah .env.example tidak tercantum di .gitignore Laravel. Dia sengaja di-track. Periksa sendiri file .gitignore Laravel 11, 12, maupun 13 — .env.example memang tidak ada di sana.

Alur kerja standarnya setelah clone project kira-kira begini:

# Salin contoh konfigurasi jadi .env
cp .env.example .env

# Generate APP_KEY yang unik untuk environment kamu
php artisan key:generate

Sama seperti sebelumnya, cp adalah perintah shell Unix — di Windows pakai Git Bash/WSL atau salin file .env.example menjadi .env lewat editor. php artisan key:generate sendiri bekerja di semua platform.

Tanpa .env.example yang ter-track, developer baru tidak akan tahu variabel apa yang harus diisi. Ini alasan kenapa meng-ignore .env.example termasuk kesalahan yang harus dihindari.

Mengenal Nested .gitignore di Storage Directories

Ada satu detail yang jarang diperhatikan tapi penting: Laravel tidak cukup dengan satu .gitignore di root. Di dalam folder storage, ada beberapa .gitignore lagi yang tersebar di subdirektori.

Kenapa? Git tidak men-track direktori kosong. Setelah seseorang clone repository, folder kosong seperti storage/logs, storage/framework/sessions, atau storage/framework/views tidak akan muncul. Padahal Laravel butuh folder-folder itu untuk menulis file log dan session.

Solusinya adalah trik kecil: taruh file .gitignore berisi dua baris ini di dalam setiap folder yang ingin dipertahankan:

*
!.gitignore

Pola ini artinya: ignore semua isi folder, kecuali file .gitignore itu sendiri. Karena file .gitignore tetap di-track, folder itu otomatis ikut ada di repository meskipun isinya kosong.

Skeleton Laravel membawa pola ini di banyak tempat, di antaranya storage/app/private, storage/app/public, storage/framework/sessions, storage/framework/views, storage/logs, dan bootstrap/cache. Beberapa level lebih kompleks — storage/app dan storage/framework/cache menggunakan aturan yang mengecualikan beberapa subfolder lalu meng-ignore sisanya.

Ini bukan detail yang perlu kamu buat sendiri dari nol. Tapi jangan hapus file .gitignore di dalam folder storage — begitu dihapus, folder-folder itu ikut hilang dari repository, dan orang yang clone project bakal dapat error karena folder yang dibutuhkan tidak ada.

Perbedaan .gitignore Laravel 11 vs 12 vs 13

Kalau kamu migrasi project dari Laravel 11 ke 12, atau dari 12 ke 13, format .gitignore ikut berubah. Berikut perubahannya per tahap.

Laravel 11 → Laravel 12

Ada tiga perubahan utama:

Disusun alfabetis. Laravel 12 merapikan semua entri secara alfabetis. File jadi lebih mudah dipindai.
Aturan log digeneralisasi. Laravel 11 hanya mencantumkan npm-debug.log dan yarn-error.log secara spesifik. Laravel 12 menggantinya dengan satu wildcard *.log yang mencakup semua file log.
File OS ditambahkan. .DS_Store dan Thumbs.db baru muncul di Laravel 12; keduanya tidak ada di default Laravel 11.

Perubahan yang terakhir relevan kalau kamu masih pakai Laravel 11 dan kebetulan bekerja lintas OS — kamu bisa menambahkan .DS_Store dan Thumbs.db sendiri.

Laravel 12 → Laravel 13

Perubahan dari 12 ke 13 lebih kecil, tapi tetap ada 4 entri baru dan 1 yang dihapus:

Menambahkan /.codex — konfigurasi tool AI coding Codex.
Menambahkan /.cursor/ — direktori konfigurasi editor/tool AI Cursor.
Menambahkan /public/fonts-manifest.dev.json — manifest font generated saat development.
Menambahkan _ide_helper.php — file generated oleh laravel-ide-helper.
Menghapus /.fleet — konfigurasi JetBrains Fleet, yang sudah tidak disertakan.

Buat kamu yang menjalankan composer create-project dan mendapat skeleton 13, file .gitignore kamu sudah berisi 27 entri di atas. Project Laravel 12 yang sudah ada tetap memakai 24 entri — tidak berubah otomatis kecuali kamu memindahkannya sendiri. Baiknya, kalau migrasi ke versi baru, bandingkan .gitignore lama dengan template baru dan sesuaikan.

Penting: entri default menambah pola untuk tool-tool yang bisa berubah seiring versi. Tapi prinsip praktisnya — .env di-ignore, .env.example di-track, vendor/ dan node_modules/ tidak di-commit — tetap sama di semua versi tersebut.

Troubleshooting dan Common Mistakes

Bagian ini soal masalah yang paling sering bikin bingung: file yang sudah terlanjur ter-commit.

File Sudah Terlanjur Di-commit, Kenapa .gitignore Tidak Berfungsi?

Ini masalah klasik. Kamu membuat .gitignore, menambahkan aturan untuk .env, tapi Git tetap melacak perubahannya. Penyebabnya sederhana: .gitignore hanya berlaku untuk file yang belum di-track. File yang sudah pernah masuk repository tidak terpengaruh oleh aturan ignore — Git sudah "mengenal" file itu dan menganggapnya bagian dari repo.

Satu-satunya cara mengeluarkan file itu dari tracking tanpa menghapusnya dari disk adalah git rm --cached:

# Berhenti melacak .env, file tetap ada di disk
git rm --cached .env

# Commit perubahan tracking
git commit -m "Stop tracking .env file"

Setelah itu, karena .env sudah ada di .gitignore, file tidak akan ikut lagi di commit berikutnya.

Perhatikan perbedaannya: git rm --cached hanya menghapus file dari index Git, file asli di disk tetap utuh. Sedangkan git rm tanpa --cached menghapus file dari disk dan dari tracking — hati-hati, itu operasi yang berbeda.

Vendor/ dan Node_modules Sudah Terlanjur Ter-commit

Repository membengkak karena vendor/ ter-commit bisa jadi masalah besar — folder ini bisa berbobot 50 sampai 200 megabyte lebih. Solusinya sama, tapi untuk direktori:

# Hapus vendor dan node_modules dari tracking, file tetap di disk
git rm -r --cached vendor/
git rm -r --cached node_modules/

git commit -m "Remove vendor and node_modules from tracking"

Setelah commit ini, setiap developer yang pull perubahan harus menjalankan composer install (dan npm install) untuk membuat ulang dependency — karena vendor dan node_modules tidak lagi ada di repository.

Ada baiknya juga melihat apa yang akan dihapus sebelum benar-benar menjalankannya, menggunakan dry run:

git rm -r --cached --dry-run vendor/

Ini menampilkan daftar file yang akan dikeluarkan tanpa benar-benar mengubah apa pun. Berguna untuk memastikan perintahnya mengenai target yang tepat.

Kredensial Bocor ke Repository Publik

Ini skenario terburuk. Kamu sudah terlanjur commit .env yang berisi password dan API keys, lalu men-push ke repository publik di GitHub. Menjalankan git rm --cached .env dan commit memang mengeluarkan file dari tracking — tetapi file itu tetap ada di Git history. Siapa pun bisa membuka riwayat commit dan membaca kredensialnya.

Menghapus commit-nya pun tidak cukup. Jika data sensitif sudah pernah masuk ke repository yang bisa diakses orang lain, satu-satunya cara yang benar adalah mengganti (rotate) semua kredensial tersebut: ganti password database, rotate semua API keys, ganti APP_KEY, dan ubah semua rahasia lain yang ada di dalam file itu. Asumsikan semuanya sudah terekspos.

Inilah alasan mengapa .env wajib di-ignore sejak awal — jauh lebih mudah mencegah kebocoran daripada menanggulangi akibatnya setelah terjadi.

.env.example Ikut Di-ignore

Karena menganggap semua file .env* harus di-ignore, sebagian developer tanpa sengaja menambahkan .env.example ke aturan ignore. Masalahnya, developer baru yang clone project jadi tidak tahu environment variables apa yang harus disiapkan. Pastikan .env.example tidak tercantum di .gitignore — file itu harus tetap ter-track.

Menambahkan Custom Rules untuk Kebutuhan Spesifik

Default Laravel sudah bagus, tapi hampir semua project butuh beberapa aturan tambahan sesuai tools yang dipakai. Beberapa yang umum:

# Docker local override
docker-compose.override.yml

# Database SQLite lokal
/database/*.sqlite
/database/*.sqlite-journal

# Laporan coverage test
/coverage

# Backup dan file sementara editor
*.swp
*.swo
*~

Beberapa catatan dari contoh di atas:

docker-compose.override.yml biasanya berisi konfigurasi yang spesifik untuk machine seorang developer — tidak cocok di-share ke tim.
File SQLite lokal seperti /database/*.sqlite berisi data lokal. Kalau kamu memakainya sebagai database, ada baiknya di-ignore. Pola ini juga mencakup file -journal yang dibuat SQLite saat operasi write.
Folder /coverage adalah output dari menjalankan test dengan code coverage — bisa dibuat ulang kapan saja.

Pola *.log mencakup file log di level mana pun; kalau kamu butuh pola lebih luas, kamu bisa menyesuaikan sendiri.

Ada satu hal menggiurkan yang perlu disikapi hati-hati: vendor/ dan public/build kadang sengaja di-commit oleh sebagian tim agar tidak perlu menjalankan composer install atau build di server saat deployment. Ini biasanya bukan best practice — server seharusnya bisa membangun dependency dari composer.json. Tapi ini keputusan yang bergantung kebutuhan tiap project, jadi setidaknya kamu tahu trade-off-nya: repository mengecil vs proses build di server.

Kesimpulan

.gitignore adalah salah satu file kecil yang dampaknya besar di project Laravel. Dengan konfigurasi yang benar, kamu mencegah kredensial bocor, menjaga repository tetap ringan, dan memastikan siapa pun bisa clone project tanpa masalah.

Hal paling penting yang perlu diingat: .env harus di-ignore tapi .env.example harus di-track, .gitignore hanya berlaku untuk file yang belum di-track (kalau sudah terlanjur masuk, gulir ke atas untuk git rm --cached), dan jangan sampai menghapus file .gitignore di dalam folder storage.

Mulailah dari default template Laravel yang sudah disediakan. Pahami setiap barisnya, tambahkan aturan yang sesuai kebutuhan projectmu, dan commit dengan bijak.