Berkas .gitignore: cara mengecualikan file dari Git dan menghapus file yang sudah ditambahkan

git ignore adalah cara memberi tahu Git: «file-file ini jangan disentuh, jangan tampilkan di git status, dan jangan ikut dengan git add .». Aturannya ditulis di berkas teks bernama .gitignore, yang di-commit bersama proyek dan berlaku untuk seluruh tim. Hal yang perlu diperhatikan: pengabaian hanya berlaku untuk file yang belum dilacak Git.

Apa yang biasanya ditambahkan ke .gitignore

• Dependensi: node_modules/, vendor/, .venv/ — dipulihkan kembali oleh manajer paket.
• Hasil build: dist/, build/, *.class, __pycache__/.
• Log dan berkas sementara: *.log, tmp/, *.swp.
• Rahasia dan pengaturan lokal: .env, kunci, konfigurasi lokal.
• Sampah dari OS dan editor: .DS_Store, Thumbs.db, .idea/ — sebaiknya dimasukkan ke pengabaian global, lihat di bawah.

Aturannya sederhana: repositori hanya boleh berisi apa yang ditulis manusia, bukan yang dihasilkan program atau bergantung pada satu mesin tertentu.

Cara membuat .gitignore

Ini berkas teks biasa di root repositori. Buat, isi pola satu per baris, lalu commit:

cat > .gitignore <<'EOF'
# dependensi
node_modules/
# build
dist/
# log
*.log
# rahasia
.env
EOF

git add .gitignore
git commit -m "chore: tambahkan .gitignore"

Templat siap pakai untuk berbagai bahasa dan framework tersedia di repositori github/gitignore; GitHub dan GitLab juga menawarkan pemilihan templat saat membuat proyek. Gunakan sebagai dasar lalu buang bagian yang tidak perlu.

Sintaks pola .gitignore

Catatan penting: pola tanpa garis miring di tengahnya (config.json) berlaku di level mana pun, sedangkan pola yang memuat garis miring di awal atau tengah (/config.json, src/config.json) dihitung relatif terhadap folder tempat .gitignore berada.

Pengecualian dengan tanda seru

*.log
!important.log

Jebakannya: file tidak bisa «dikembalikan» jika folder induknya diabaikan. Git tidak masuk ke folder yang diabaikan, jadi cara berikut tidak akan berhasil:

logs/
!logs/keep.txt     # tidak berfungsi

Yang benar adalah mengabaikan isi folder, bukan folder itu sendiri:

logs/*
!logs/keep.txt

Teknik yang sama dipakai untuk menyimpan folder kosong di repositori: Git tidak menyimpan direktori kosong, sehingga di dalamnya diletakkan berkas .gitkeep dan hanya berkas itu yang diizinkan.

Tempat lain untuk mengatur pengabaian

Sampah dari OS dan IDE sebaiknya dimasukkan ke pengabaian global agar tidak mengotori .gitignore bersama:

git config --global core.excludesFile ~/.gitignore_global
echo ".DS_Store" >> ~/.gitignore_global
echo ".idea/" >> ~/.gitignore_global

Jika core.excludesFile tidak diatur, Git membaca ~/.config/git/ignore bila berkas itu ada.

Mengapa .gitignore tidak berfungsi

Keluhan paling sering: «sudah saya tambahkan file ke .gitignore, tetapi Git tetap menampilkan perubahannya». Penyebabnya hampir selalu sama: file itu sudah dilacak. Pengabaian tidak berpengaruh pada file yang pernah masuk ke commit.

Untuk memeriksa aturan mana yang berlaku (atau mengapa tidak berlaku), gunakan git check-ignore:

git check-ignore -v logs/app.log
# .gitignore:3:*.log	logs/app.log

Keluarannya menampilkan berkas dan baris aturan yang cocok. Keluaran kosong berarti file tidak diabaikan. Penyebab lain yang sering terjadi adalah spasi di akhir baris pola atau encoding berkas yang salah, misalnya UTF-16 akibat pembuatan lewat PowerShell.

Menghapus file yang sudah ter-commit: git rm --cached

Perintah git rm menghapus file dari index dan dari disk. Dengan --cached, file hanya dihapus dari index: file tetap ada di komputer Anda, tetapi tidak lagi dilacak.

echo ".env" >> .gitignore
git rm --cached .env
git commit -m "chore: .env tidak lagi dilacak"
git push

Untuk folder diperlukan -r:

git rm -r --cached node_modules/

Jika aturan yang berubah banyak dan tidak jelas apa saja yang sudah masuk repositori, index bisa dibangun ulang sepenuhnya: git rm -r --cached ., lalu git add . dan commit. Sebelum commit, periksa git status; file yang dikeluarkan dari index akan terlihat di sana.

Perhatian: rahasia tetap ada di riwayat

git rm --cached menghapus file dari commit berikutnya, tetapi tidak dari commit lama. Jika kata sandi atau token pernah masuk ke repositori, ia tetap bisa dibaca oleh siapa pun yang punya klon. Rahasia tersebut harus dianggap bocor dan dibuat ulang. Riwayat bisa ditulis ulang dengan alat seperti git filter-repo, tetapi itu mengubah hash semua commit berikutnya dan harus disepakati dengan tim.

Akibat lain: setelah git pull, rekan tim yang file-nya dihapus dari index dengan --cached akan kehilangan file itu di disk. Untuk .env, beri tahu tim lebih dulu atau simpan templat .env.example di repositori.

git rm: menghapus file

git rm old.py              # hapus dari disk dan dari index
git rm -r legacy/          # hapus folder
git rm -n '*.tmp'          # dry run: tampilkan apa yang akan dihapus
git rm -f changed.py       # hapus file yang masih punya perubahan belum di-commit

Jika file dihapus dengan rm biasa, Git menganggapnya «deleted», dan penghapusan itu harus ditambahkan dengan git add atau git rm. git rm melakukan kedua langkah sekaligus. Tanpa -f, Git menolak menghapus file yang punya perubahan belum di-commit; ini perlindungan agar pekerjaan tidak hilang.

git mv: mengganti nama dan memindahkan

git mv utils.py helpers.py
git mv helpers.py src/helpers.py

git mv adalah singkatan dari mv + git rm untuk path lama + git add untuk path baru. Git tidak menyimpan fakta bahwa file diganti namanya: ia menyimpulkannya dari kemiripan isi ketika menampilkan git status, git log --follow, dan git diff. Karena itu, hasil git mv dan mv biasa yang disusul git add -A sama saja.

Saran praktis: ganti nama dan ubah isi file di commit yang berbeda. Jika isi file berubah banyak bersamaan dengan penggantian nama, Git mungkin tidak lagi mengenalinya sebagai file yang sama, dan riwayat dengan --follow akan terputus.

Untuk mengubah hanya huruf besar-kecil pada nama di Windows dan macOS (sistem berkas yang tidak membedakan huruf besar-kecil), gunakan git mv readme.md README.md. Penggantian nama biasa di File Explorer kadang tidak terdeteksi oleh Git.

Urutan aturan dan prioritas

Di dalam satu berkas, aturan dibaca dari atas ke bawah, dan aturan terakhir yang cocok yang berlaku. Karena itu pengecualian !keep.log harus berada di bawah aturan *.log, jika tidak ia akan tertimpa. Antar-berkas, .gitignore di folder yang lebih dalam lebih diutamakan daripada yang di root, sedangkan pengabaian global dan .git/info/exclude memiliki prioritas paling rendah.

Contoh .gitignore untuk proyek web

Berikut contoh yang bisa dipakai untuk proyek Node.js dengan backend Python. Perhatikan komentarnya: enam bulan kemudian tidak ada yang ingat mengapa sebuah aturan ditambahkan.

# --- dependensi ---
node_modules/
.venv/

# --- build dan cache ---
/dist
/build
__pycache__/
*.pyc
.pytest_cache/
coverage/

# --- log ---
*.log
npm-debug.log*

# --- lingkungan dan rahasia ---
.env
.env.*
!.env.example

# --- unggahan pengguna, tetapi folder tetap disimpan ---
uploads/*
!uploads/.gitkeep

Contoh ini memakai kedua teknik pengecualian: .env.* menyembunyikan semua varian lingkungan lokal, tetapi templat .env.example tetap ada di repositori; dan folder uploads tetap ada di klon berkat .gitkeep.

Yang sebaiknya tidak diabaikan

Pengabaian yang berlebihan juga merugikan. Berkas kunci dependensi seperti package-lock.json, poetry.lock, atau composer.lock biasanya di-commit pada aplikasi, karena menjamin semua developer dan CI memasang versi paket yang sama. Pengaturan format bersama (.editorconfig, konfigurasi linter) juga sebaiknya berada di repositori.

Kasus yang diperdebatkan adalah pengaturan IDE. Folder .vscode/ sering diabaikan seluruhnya, tetapi kadang tim memasukkan rekomendasi ekstensi dan task build: .vscode/*, lalu !.vscode/extensions.json. Keputusannya ada pada tim; yang penting jangan menyimpan jalur pribadi atau kunci di repositori bersama.

Skenario: node_modules terlanjur ter-commit

Kesalahan klasik pemula: git add . dijalankan sebelum .gitignore dibuat, sehingga puluhan ribu file ikut masuk ke commit. Perbaikannya dalam tiga langkah:

echo "node_modules/" >> .gitignore
git rm -r --cached node_modules
git commit -m "chore: node_modules dikeluarkan dari repositori"

Jika commit belum dikirim ke server, lebih baik tulis ulang commit tersebut agar file berat tidak tertinggal di riwayat: git reset --soft HEAD~1, lalu jalankan perintah di atas dan buat commit baru. Setelah push, file sudah ada di riwayat, dan ukuran klon tidak akan mengecil tanpa menulis ulang riwayat.

Agar kejadian ini tidak terulang, buat .gitignore sebelum git add pertama, dan biasakan memeriksa git status sebelum commit: daftar file baru yang terlalu panjang adalah tanda untuk berhenti.

Ringkasan

.gitignore adalah berkas pertama yang sebaiknya di-commit di proyek baru: dependensi, hasil build, log, dan rahasia tidak perlu berada di repositori. Pengabaian hanya berlaku untuk file yang belum dilacak, jadi file yang sudah terlanjur masuk dikeluarkan dengan git rm --cached, dan aturannya diperiksa dengan git check-ignore -v. Untuk menghapus dan mengganti nama, gunakan git rm dan git mv agar perubahannya langsung masuk ke index. Bekerja dengan index dan repositori pertama dibahas dengan praktik dalam kursus Git.