Struktur Repository

Kita sudah dua kali membuat repository — sekali lewat git init, sekali lewat git clone — dan keduanya meninggalkan jejak yang sama: folder tersembunyi bernama .git. Selama folder itu dianggap kotak hitam, Git terasa seperti sihir: perintah berjalan, riwayat muncul, tetapi kita tidak tahu di mana datanya tinggal. Chapter ini membuka kotak itu: kita petakan isi folder proyek, kenali satu per satu penghuni .git, lalu letakkan tiga area kerja Git pada posisi fisiknya yang sebenarnya. Pemetaan ini juga menjawab pertanyaan praktis: kenapa Git bisa bekerja penuh tanpa server.

Peta Folder Proyek #

Kita pakai satu repository latihan dengan dua commit — dibangun dengan cara yang sama seperti latihan sebelumnya: git init -b main, konfigurasi identitas lokal, lalu dua putaran add–commit untuk berkas README.md dan glosarium.md. Riwayatnya berbunyi:

git log --oneline

Output yang Dihasilkan:

462b791 Tambah glosarium istilah
642e91f Tambah README dokumentasi

Sekarang kita lihat apa saja yang ada di folder proyek:

ls -A

Output yang Dihasilkan:

.git
README.md
glosarium.md

Daftar pendek tersebut memuat seluruh repository. Dua berkas terakhir adalah working tree — berkas proyek yang kita lihat dan sunting di editor. Satu entri pertama, .git, adalah seluruh sisanya: database tempat riwayat, konfigurasi, dan posisi branch tersimpan. Opsi -A pada ls penting di sini karena Linux menyembunyikan berkas dan folder yang diawali titik secara bawaan.

Isi Direktori .git #

Kita masuk ke dalam database-nya:

ls .git

Output yang Dihasilkan:

COMMIT_EDITMSG
HEAD
branches
config
description
hooks
index
info
logs
objects
refs

Sebelas entri tersebut adalah kerangka standar sebuah .git setelah commit dibuat. Tabel berikut merangkum peran masing-masing:

Empat entri pertama adalah inti repository: HEAD, config, objects/, dan refs/. Sisanya pelengkap yang tumbuh mengikuti pemakaian — index dan logs/ baru muncul setelah commit pertama, dan hooks/ mulai terpakai ketika kita memasang skrip otomasi. Dua area kerja Git juga tampak di daftar ini: staging area hidup di berkas index, sementara isi riwayat permanen hidup di objects/.

Tiga Area pada Posisi Fisiknya #

Aliran perubahan pada Git — dari suntingan menjadi commit — sudah kita bahas pada chapter Cara Kerja Git . Peta fisiknya kini bisa dilengkapi: area pertama berada di luar .git, dua lainnya di dalamnya.

Diagram tersebut menegaskan satu hal yang sering mengejutkan: staging area bukan konsep abstrak, melainkan berkas index yang nyata di dalam .git, dan “repository” pada arti sempitnya adalah direktori objects. Perpindahan git add dan git commit sesungguhnya adalah pembaruan berkas-berkas di dalam .git itu. Bedah masing-masing area menyusul pada chapter Working Tree , Staging Area , dan Git Directory .

Model Bukan Client-Server #

Susunan ini menjawab pertanyaan besar: mengapa Git tidak membutuhkan server yang menyala? Jawabannya, seluruh data yang dibutuhkan setiap operasi berada di satu folder pada komputer kita. Perintah git log, git diff, hingga git commit membaca dan menulis langsung ke .git lokal tanpa satu paket jaringan pun. Bandingkan dengan model terpusat yang dibahas pada chapter Mengenal Version Control : di sana, riwayat hidup di satu server, dan hampir semua operasi harus menunggu server menjawab.

Konsekuensinya mengubah cara berpikir tentang salinan. Menyalin folder proyek lengkap dengan .git-nya berarti menyalin repository beserta seluruh riwayatnya — basis dari model terdistribusi. Meski begitu, cara menyalin yang benar tetap git clone, karena clone sekaligus merapikan remote dan pengaturan yang menyesuaikan lokasi baru, sebagaimana dibuktikan pada chapter git clone . Server hanyalah peran yang bisa dijalankan komputer mana pun — repository bare yang kita buat sekilas pada chapter git init adalah wujudnya.

Struktur folder kini terpetakan: berkas proyek di luar, database di dalam. Titik berangkat pendalaman berikutnya adalah area yang paling sering kita saksikan: working tree. Lanjut ke Working Tree .