.gitignore Tidak Berfungsi? Ini Perbaikan Sebenarnya

TL;DR: jika .gitignore tidak berfungsi, hampir selalu file itu sudah terlacak. Git mengabaikan file yang belum pernah dilihatnya — file yang ada di index kebal terhadap rule apa pun yang Anda tulis. Buktikan dengan git check-ignore -v <path>: keluaran yang diam berarti path-nya terlacak dan tidak ada rule yang berlaku. Perbaiki dengan git rm --cached <path>, commit, dan rule ignore mulai bekerja dari commit itu ke depan. Urutan rule, jebakan negasi, dan dugaan keliru seputar VS Code menjelaskan sisanya.

Kenapa .gitignore tidak berfungsi?

Satu mekanisme menutup mayoritas kasus: file itu sudah di-commit sebelum rule-nya ada. .gitignore bukan penyaring yang menyembunyikan file dari git — ia adalah aturan tentang apa yang harus diambil git add dari keadaan tak terlacak. Begitu file masuk index, git melacak perubahan isinya selamanya sampai Anda melepasnya secara eksplisit. Menyunting .gitignore setelah kejadian tidak mengubah apa pun pada file terlacak — itulah kenapa rangkaian klasik “commit .env, panik, tambahkan .env ke .gitignore, commit lagi” tetap mengirim rahasia itu di setiap push.

Ini menggigit semua orang karena git hampir universal — survei Stack Overflow 2022 mencatat penggunaan Git di atas 93% pengembang profesional (survey.stackoverflow.co) — dan setiap satu dari mereka pada akhirnya menulis rule untuk file yang mereka commit minggu lalu.

Sisa tulisan ini membahas kasus minoritas: kesalahan urutan rule, jebakan negasi, edge case folder, dan pertanyaan IDE. Tetapi jalankan dulu pemeriksaan kesehatan di bagian berikut — lebih dari sembilan dari sepuluh kali, ia yang mengakhiri penyelidikan.

Bagaimana cara cek rule gitignore mana yang cocok dengan sebuah file?

git check-ignore adalah alat diagnosa, dan diamnya adalah diagnosa itu sendiri:

# Mencetak rule yang cocok + file + nomor baris saat ada rule yang berlaku
git check-ignore -v debug.log
# .gitignore:3:*.log    debug.log

# Tidak mencetak APA PUN saat tidak ada rule — file terlacak (atau memang tak ada rule)
git check-ignore -v src/.env
# (diam = .gitignore tidak mengabaikan path ini, apa pun yang Anda tulis)

# Exit code: 0 = diabaikan, 1 = tidak diabaikan — bisa dipakai di skrip
git check-ignore -q debug.log && echo "ignored" || echo "tracked or unruly"

Membaca keluaran -v: sumber ignore (.gitignore, .git/info/exclude, atau file ignore global Anda), lalu line-number:pattern, lalu path-nya. Jika rule belakangan mengejutkan Anda, ingat presedensinya: rule yang cocok terakhir yang menang, sehingga !important.log setelah *.log menyertakan kembali satu file itu.

Kenapa gitignore tidak berfungsi untuk file yang sudah di-commit?

Lepas pelacakan filenya, biarkan tetap di disk, commit penghapusannya:

# Lepas pelacakan satu file (salinan lokal selamat — --cached hanya menyentuh index)
git rm --cached .env
git commit -m "stop tracking .env"

# Verifikasi rule ignore kini berlaku
git check-ignore -v .env

Dari commit ini ke depan, .gitignore yang menguasai path-nya: suntingan terhadapnya tidak lagi tampil di git status, dan git add . tidak akan mengambilnya lagi. File itu tetap ada di history — jika itu rahasia, menghapusnya dari commit terakhir tidak cukup. Merotasi kredensial adalah perbaikan yang sesungguhnya; menulis ulang history hanya kosmetik (dan undoing the last commit hanya membantu selama commit jelek masih menjadi ujung cabang).

Untuk repo penuh sampah yang pernah di-commit — build output, sisa-sisa editor, node_modules yang menyelinap masuk di awal — untrack massal cukup dua baris:

git rm -r --cached .
git add .
git commit -m "apply .gitignore to tracked files"

Ini membangun ulang index terhadap rule terkini: path yang diabaikan keluar, sisanya ditambahkan kembali tanpa diubah. Diff-nya terlihat dramatis (ribuan penghapusan) tetapi tidak menghapus apa pun dari disk. Jika tujuan Anda benar-benar menghapus file-file itu, bukan sekadar melepas pelacakannya, itu wilayah git clean -fdx — lihat git remove untracked files, safely.

Git mengabaikan file yang belum pernah dilihatnya. File yang sudah ada di index kebal terhadap .gitignore — rule apa pun yang Anda tulis tak akan membuatnya tak terlihat.

Kenapa gitignore tidak berfungsi untuk sebuah folder?

Tiga jebakan khusus folder:

1. Trailing slash penting untuk niat, bukan pencocokan. build dan build/ sama-sama mencocokkan direktori, tetapi build/ mendokumentasikan bahwa yang Anda maksud hanya direktori — sebuah file bernama build akan selamat darinya. Simetrinya gagal, sayangnya, pada penyertaan kembali (jebakan berikut).

2. Negasi tidak bisa menyelamatkan file di dalam direktori yang dikecualikan. Dokumentasi git tegas: “It is not possible to re-include a file if a parent directory of that file is excluded” (git-scm.com/docs/gitignore). Ini keputusan performa — git melewati direktori yang dikecualikan sekaligus, bukan menelusurinya. Karena itu ini tidak bekerja:

build/
!build/keep.me        # rule mati — git tak pernah melihat ke dalam build/

Perbaikannya: kecualikan isinya, bukan direktorinya:

build/*
!build/keep.me        # bekerja — build/ sendiri tetap terbuka untuk diperiksa

3. File .gitignore bersarang menang di cakupannya. Rule di subdir/.gitignore mengesampingkan file root untuk path di bawah subdir. Ketika git check-ignore -v menyebut sumber ignore yang tidak Anda duga, biasanya ini sebabnya.

Kenapa gitignore tidak berfungsi di VS Code?

Hampir tidak pernah karena VS Code. Source Control view editor membaca index yang sama dengan git, jadi gejalanya identik: file itu sudah di-commit, dan restart IDE mana pun tidak mengubah index. Dua kenyataan seputar VS Code layak diketahui:

• Abu-abu di Explorer = diabaikan; oranye/kuning = terlacak dengan perubahan. File yang tampil sebagai dimodifikasi setelah Anda mengabaikannya adalah konfirmasi bahwa ia terlacak — jalankan perbaikan git rm --cached di atas.
• .gitignore yang tidak muncul di daftar changed Explorer justru berarti rule-nya bekerja — file itu tak pernah tampil sebagai untracked sejak awal. Orang sering melapor “VS Code mengabaikan gitignore saya” padahal git status di CLI hanya berbeda dengan SCM view yang basi; reload window-nya (Cmd/Ctrl+Shift+P → “Reload Window”) sebelum menyalahkan git.

.gitignore vs .git/info/exclude vs global: mana dipakai kapan?

File	Cakupan	Di-commit?	Dipakai untuk
.gitignore (repo)	Semua yang clone	Ya	Build output, dependensi, .env — rule bersama
.git/info/exclude	Hanya clone Anda	Tidak	Keperluan pribadi: .scratch/, sisa editor
core.excludesFile (global)	Semua repo Anda	Tidak	Sampah OS: .DS_Store, Thumbs.db, *.swp
.gitignore + negasi	Repo	Ya	Menyertakan kembali pengecualian config terlacak

File global adalah satu yang paling jarang diset pengembang dan paling seharusnya:

git config --global core.excludesFile ~/.gitignore_global
printf '.DS_Store\nThumbs.db\n*.swp\n' >> ~/.gitignore_global

Rule rumah yang layak disalin: jika sebuah rule menguntungkan seluruh tim, ia berhak masuk repo; jika hanya menguntungkan Anda, ia berhak masuk exclude atau file global. Meng-commit rule ignore personal itulah cara file .gitignore berakhir 300 baris dan tak ada yang tahu paruh mana yang masih penting.

Bagaimana cara mengabaikan perubahan pada file yang terlacak?

Kadang Anda ingin sebuah file terlacak (template config, file setelan IDE) tetapi ingin suntingan lokalnya berhenti tampil di git status. Dua flag pada git update-index, dan keduanya bukan milik workflow tim:

git update-index --skip-worktree config/local.dev   # suntingan lokal jadi diam
git update-index --no-skip-worktree config/local.dev  # ...dan kembali lagi

--skip-worktree adalah yang bisa dipertanggungjawabkan — ia berkata “versi lokal saya memang sengaja menyimpang.” Sepupunya --assume-unchanged adalah janji performa (“file ini tidak akan berubah”), bukan mekanisme abaikan, dan git bisa diam-diam melanggarnya. Kedua flag sama-sama gagal keras saat pull ketika upstream juga mengubah file itu — jawaban yang tahan lama adalah config khusus lokal lewat exclude sejak awal, atau file template (config.example) yang dilacak git dan Anda salin sendiri.

Cek kesehatan gitignore 30 detik

git check-ignore -v <path>        # rule mana? (diam = terlacak, tak ada rule)
git ls-files --error-unmatch <path>  # apakah terlacak sama sekali?
git rm --cached <path>            # lepas pelacakan, file tetap di disk
git commit -m "stop tracking <path>"
git check-ignore -v <path>        # rule kini tampil

Diagnosa, lepas pelacakan, verifikasi. Pola di balik setiap laporan “gitignore not working” adalah file yang sama memakai dua topi — terlacak di satu sisi index, diabaikan di sisi lain — dan satu flag --cached melepas topi keduanya.