Masalah kecil yang sering bikin PR jadi berisik: ada file lokal nyasar ke repo, lalu semua orang ikut “mewarisi” aturan ignore yang sebenernya cuma relevan buat satu laptop.

Artikel ini ngebahas tiga lapis Git ignore yang sering kelewat di tutorial: .gitignore, .git/info/exclude, dan ignore global di mesin lu. Intinya simpel: nggak semua file sampah lokal pantas masuk ke .gitignore project. Kalau lu tahu bedanya, repo tim jadi lebih bersih, PR lebih fokus, dan risiko file pribadi ikut ke-commit bisa turun.

Kenapa topik Git ignore ini penting?

Banyak developer belajar Git dari alur paling dasar: bikin file .gitignore, masukin node_modules/, .env, atau folder build, lalu beres. Itu nggak salah. Tapi Git ignore sebenernya punya beberapa level, dan masing-masing punya fungsi yang beda.

Masalah mulai muncul saat semua hal dimasukin ke .gitignore project. File catatan pribadi, cache editor tertentu, hasil eksperimen lokal, sampai output script yang cuma ada di laptop satu orang ikut masuk ke aturan tim. Lama-lama .gitignore jadi tempat sampah kolektif.

Menurut gua, ini bukan cuma soal kerapian. Ini soal hygiene kerja. Codebase yang rapi bikin developer baru lebih gampang onboarding, review PR lebih fokus, dan AI coding agent juga lebih gampang paham struktur repo tanpa distraksi file lokal yang nggak penting.

Definisi singkat: apa itu Git ignore?

Git ignore adalah mekanisme buat ngasih tahu Git agar file tertentu nggak dimasukkan ke daftar perubahan yang perlu dilacak. Biasanya ini dipakai buat file hasil build, dependency, cache, secret lokal, atau file konfigurasi mesin pribadi.

Yang penting: Git ignore hanya berlaku untuk file yang belum dilacak Git. Kalau file sudah pernah masuk commit, menambah pattern ke ignore nggak otomatis menghapus file itu dari tracking. Lu tetap perlu langkah lain seperti git rm --cached kalau memang mau berhenti melacak file yang sudah telanjur masuk repo.

Lapis 1: .gitignore untuk aturan bersama tim

.gitignore adalah file ignore yang paling umum. File ini masuk ke repo dan ikut ke-commit, jadi semua orang di tim bakal dapat aturan yang sama.

Pakai .gitignore untuk file yang memang relevan buat seluruh project, misalnya:

  • node_modules/ untuk dependency JavaScript yang bisa di-install ulang.
  • dist/, build/, atau output hasil compile.
  • .env kalau project punya file environment lokal yang nggak boleh ke-commit.
  • File cache framework yang memang selalu muncul di banyak mesin developer.

Rule of thumb gua: kalau aturan ignore ini membantu semua orang yang kerja di repo, masukin ke .gitignore. Kalau cuma membantu lu pribadi, jangan buru-buru taruh di sana.

Lapis 2: .git/info/exclude untuk aturan lokal per repo

Ini bagian yang banyak developer belum tahu. Setiap repo Git punya file lokal di .git/info/exclude. Fungsinya mirip .gitignore, tapi file ini nggak ikut ke-commit dan cuma berlaku di repo itu pada mesin lu.

Contoh kasus yang cocok:

  • Lu punya notes.txt berisi catatan debugging pribadi di repo kantor.
  • Lu generate file eksperimen lokal yang nggak relevan buat tim.
  • Lu pakai tool editor tertentu yang bikin file sementara, tapi cuma di satu repo.

Daripada nambahin notes.txt ke .gitignore project dan bikin semua orang ikut lihat aturan pribadi lu, taruh saja di .git/info/exclude.

# buka file exclude lokal repo
nano .git/info/exclude

# contoh isi
notes.txt
scratch/
local-debug-output.json

Keuntungan pendekatan ini jelas: repo tetap bersih, aturan tim tetap fokus, dan lu tetap aman dari risiko file lokal ke-commit tanpa ganggu orang lain.

Lapis 3: ignore global untuk seluruh mesin lu

Kalau ada file yang selalu muncul di hampir semua repo karena mesin atau editor lu, pakai ignore global. Ini berlaku untuk semua repo di laptop lu.

Contohnya:

  • .DS_Store di macOS.
  • File sementara dari editor tertentu.
  • Folder lokal dari tool yang selalu lu pakai, tapi nggak relevan buat project mana pun.

Menurut dokumentasi Git, konfigurasi ini bisa diatur lewat core.excludesFile. Di banyak setup modern, lokasi yang umum dipakai adalah ~/.config/git/ignore.

# bikin file ignore global
mkdir -p ~/.config/git
touch ~/.config/git/ignore

# kasih tahu Git lokasi file global ignore
git config --global core.excludesFile ~/.config/git/ignore

# contoh isi ~/.config/git/ignore
.DS_Store
.idea/
*.swp

Dengan ini, lu nggak perlu lagi nambahin .DS_Store ke setiap .gitignore project. Itu urusan mesin lu, bukan urusan repo tim.

Cara milih lapis yang benar

Kalau bingung, pakai checklist ini:

  • Apakah file ini muncul karena project? Taruh di .gitignore.
  • Apakah file ini cuma muncul di repo ini, tapi hanya buat workflow lu? Taruh di .git/info/exclude.
  • Apakah file ini muncul di banyak repo karena OS, editor, atau kebiasaan mesin lu? Taruh di ignore global.
  • Apakah file ini secret seperti token atau credential? Pastikan nggak ke-commit, tapi jangan cuma mengandalkan ignore. Pakai secret manager atau file env yang jelas.

Versi pendeknya:

Kebutuhan Tempat yang cocok
Aturan bersama project .gitignore
Aturan pribadi di satu repo .git/info/exclude
Aturan pribadi di semua repo ~/.config/git/ignore atau file global via core.excludesFile

Kesalahan yang sering kejadian

1. Masukin semua file lokal ke .gitignore

Ini bikin .gitignore tumbuh tanpa arah. File yang cuma relevan buat satu developer jadi aturan global untuk semua orang. Di tim kecil mungkin belum terasa. Di repo yang umurnya panjang, ini jadi noise.

2. Mengira ignore bisa menyelamatkan secret yang sudah ke-commit

Kalau credential sudah masuk commit, menambah .env ke .gitignore tidak menghapus jejaknya dari history. Lu perlu rotate secret, bersihkan history kalau perlu, dan audit aksesnya. Ignore itu pencegahan, bukan tombol undo.

3. Nggak punya ignore global sama sekali

Kalau setiap repo lu berisi pattern untuk file OS/editor yang sama, berarti ada peluang buat mindahin sebagian aturan itu ke global ignore. Ini bikin repo project lebih netral dan nggak terlalu dipenuhi preferensi mesin pribadi.

Kenapa ini relevan di era AI coding agent?

AI coding agent sering membaca struktur repo, file konfigurasi, dan daftar perubahan sebelum ngambil keputusan. Kalau repo penuh file lokal, catatan eksperimen, atau output debug yang nggak relevan, agent bisa ikut terdistraksi.

Gua nggak bilang ignore file bakal otomatis bikin AI agent jadi pintar. Tapi hygiene kecil seperti ini ngasih sinyal yang lebih bersih: mana source code, mana build output, mana file lokal, dan mana aturan project yang memang penting.

Di workflow gua, hal kecil kayak begini sering jadi pembeda. Bukan karena terlihat keren, tapi karena mengurangi friction. Satu friction hilang, review lebih cepat. Dua friction hilang, onboarding lebih enak. Lama-lama workflow terasa jauh lebih ringan.

Takeaway praktis

  • Jangan pakai .gitignore sebagai tempat buang semua file pribadi.
  • Pakai .git/info/exclude untuk ignore lokal yang cuma berlaku di satu repo.
  • Pakai ignore global untuk file OS/editor yang muncul di banyak repo.
  • Review .gitignore project lu: kalau ada aturan yang terlalu personal, pindahin ke lapis yang lebih tepat.

FAQ singkat

Apakah .git/info/exclude aman dipakai di project kantor?

Iya, karena file itu lokal di repo mesin lu dan nggak ikut ke-commit. Cocok buat catatan atau output kerja pribadi yang nggak relevan buat tim.

Apakah ignore global menggantikan .gitignore?

Nggak. Ignore global untuk preferensi mesin pribadi. .gitignore tetap dipakai untuk aturan project yang perlu dibagikan ke semua kontributor.

Kalau file sudah telanjur ke-track, cukup masukin ke ignore?

Nggak cukup. Git tetap melacak file yang sudah masuk index. Lu perlu menghapusnya dari tracking, misalnya dengan git rm --cached nama-file, lalu commit perubahan itu.

Penutup

Tips ini kelihatannya kecil, tapi efeknya lumayan besar buat kebersihan repo. Developer yang rapi bukan cuma yang bisa nulis fitur cepat, tapi juga yang bisa membedakan mana aturan tim dan mana kebiasaan pribadi.

Kalau lu kerja di banyak repo, coba cek hari ini: apa isi .gitignore project lu memang buat semua orang, atau diam-diam sudah jadi diary laptop seseorang?

Referensi / Bacaan Lanjut

Tags:
#Software Development#Git#Developer Productivity