Dari tiga area kerja Git, satu area paling sering kita lihat tanpa menyadarinya: working tree. Setiap kali kita membuka editor, menyimpan berkas, dan menjalankan aplikasi, kita sedang berada di dalam working tree. Pertanyaannya, apa sebenarnya area ini — sekadar “folder proyek”, atau ada hubungan formalnya dengan riwayat? Chapter ini mendefinisikan working tree secara presisi, menelusuri rantai yang menghubungkannya dengan commit terakhir, lalu membedakan keadaan-keadaan berkas yang muncul di dalamnya — fondasi bagi seluruh pembacaan git status pada chapter berikutnya.

Definisi Working Tree #

Working tree adalah salinan berkas dari satu commit yang sedang kita sunting. Git mengambil snapshot yang ditunjuk posisi saat ini, “membongkarnya” menjadi berkas-berkas biasa di folder proyek, dan menyerahkannya kepada kita untuk diubah bebas. Karena berbentuk berkas biasa, semua alat tetap bekerja seperti biasa: editor menyuntingnya, compiler membacanya, dan Git tidak mengunci apa pun.

Kata kunci pada definisi tersebut adalah salinan. Commit di dalam .git tidak berubah saat kita menyunting berkas — snapshot yang tersimpan tetap utuh, sementara working tree bergerak bebas menjauh atau mendekat keadaannya. Git baru membandingkan keduanya pada saat kita bertanya lewat git status atau git diff.

Rantai HEAD → Commit → Tree #

Dari mana salinan itu berasal bisa kita telusuri bertahap, dimulai dari berkas HEAD di dalam .git:

bash 
cat .git/HEAD

Output yang Dihasilkan:

text 
ref: refs/heads/main

Isi HEAD adalah nama rujukan, bukan hash langsung: kita sedang berada pada branch main. Rujukan itu berupa berkas fisik yang menyimpan posisi terkini branch:

bash 
cat .git/refs/heads/main

Output yang Dihasilkan:

text 
462b791829f26390eb7773946830b6fe6e64efa4

Deretan 40 karakter tersebut adalah identitas commit terbaru pada branch main — commit 462b791 yang bertuliskan “Tambah glosarium istilah” pada latihan kita. Cara resmi membacanya tanpa menyentuh folder .git adalah git rev-parse HEAD, yang menghasilkan hash yang sama. Commit tersebut menyimpan penunjuk ke sebuah tree: struktur yang memuat daftar seluruh berkas pada snapshot itu. Isi tree-nya bisa kita lihat langsung:

bash 
git ls-tree HEAD

Output yang Dihasilkan:

text 
100644 blob 5d6c796d22b17e6903812567e89e248b139fdac4	README.md
100644 blob 4c89c665d067b4212b9debdf05acf8b167fd69cb	glosarium.md

Setiap baris memuat empat bagian: mode 100644 (berkas biasa), jenis objek blob (isi berkas), hash identitas isi tersebut, dan nama berkasnya. Inilah daftar inventaris lengkap snapshot — dan working tree kita yang sedang bersih berisi persis dua berkas itu. Hash pada keluaran di atas milik isi berkas latihan ini; hash di mesin pembaca berbeda karena dihitung dari isi masing-masing.

Tracked dan Untracked #

Setiap berkas di working tree berada pada salah satu dari dua kategori besar. Berkas tracked adalah berkas yang Git awasi: berkas tersebut pernah masuk ke snapshot dan Git terus mencocokkan isinya dengan versi terakhir yang dicatat. Berkas untracked adalah berkas yang berada di folder proyek tetapi belum pernah dicatat — Git melihat keberadaannya, namun belum diminta mengawasi isinya.

Berkas baru yang kita buat selalu lahir sebagai untracked, dan berpindah menjadi tracked pada saat pertama kali di-git add lalu di-commit. Kategori ini menentukan keluaran git status: hanya berkas tracked yang dilaporkan modified, sementara berkas untracked dilaporkan terpisah sebagai kandidat pelacakan. Bedah rinci status per berkas ada di chapter Untracked dan Tracked Files ; sebagian berkas juga bisa kita minta diabaikan total lewat berkas .gitignore, dibahas pada chapter .gitignore .

Bersih dan Kotor #

Keadaan working tree punya dua sebutan resmi. Working tree bersih (clean) berarti setiap berkas tracked persis sama dengan snapshot yang ditunjuk HEAD, dan tidak ada berkas untracked:

bash 
git status

Output yang Dihasilkan:

text 
On branch main
nothing to commit, working tree clean

Baris nothing to commit, working tree clean adalah keadaan yang kita kejar setiap kali menyelesaikan pekerjaan: seluruh suntingan sudah aman di dalam riwayat. Sekarang kita buat working tree kotor (dirty) — menyunting berkas tracked dan menambahkan satu berkas baru:

bash 
printf '# Situs Dokumentasi\n\nKumpulan catatan teknis tim.\nDiperbarui setiap pekan.\n' > README.md
printf 'Draf catatan internal, belum siap dibagikan.\n' > catatan-pribadi.txt
git status

Output yang Dihasilkan:

text 
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	catatan-pribadi.txt

no changes added to commit (use "git add" and/or "git commit -a")

Status kotor tersebut melaporkan dua jenis perbedaan sekaligus: README.md yang berstatus modified karena isinya menyimpang dari snapshot, dan catatan-pribadi.txt yang dilaporkan sebagai untracked. Baris-baris (use ...) pada keluaran adalah petunjuk langsung dari Git tentang perintah selanjutnya — kita bedah tuntas cara membacanya pada chapter git status .

Antara working tree yang bebas disunting dan riwayat yang permanen, Git menempatkan satu ruang transit: staging area. Pemahaman tentang working tree barusan menjadi bekal untuk memahami mengapa ruang transit itu ada. Lanjut ke Staging Area .