Fondasi & Mental Model
Git

Sistem koordinasi kerja, bukan sekadar simpan kode

Git bukan tempat menyimpan kode, melainkan sistem koordinasi kerja yang menjawab pertanyaan “siapa mengubah apa, kapan, dan kenapa” di sebuah tim.

Banyak orang pertama kali mengenal Git sebagai “tombol simpan ke cloud”. Anggapan itu menyesatkan karena membuat Git terasa seperti pengganti Google Drive. Kenyataannya Git adalah version control system terdistribusi: setiap perubahan dicatat sebagai titik histori yang punya penulis, waktu, dan pesan, lalu titik-titik itu dirangkai menjadi narasi proyek yang bisa diaudit, ditelusuri, dan diputar mundur kapan saja.

Pada proyek backend skincare github.com/kamu/skincare-backend, kamu tidak bekerja sendiri. Ada yang menggarap modul katalog produk, ada yang menggarap checkout, ada yang menambah migrasi database. Tanpa sistem koordinasi, dua orang yang menyentuh file internal/product/service.go akan saling menimpa. Git membuat pekerjaan paralel itu aman: tiap orang punya jalur sendiri, lalu hasilnya digabung dengan jejak yang jelas.

gitGraph
  commit id: "init produk"
  commit id: "tambah harga"
  branch feat/checkout
  checkout feat/checkout
  commit id: "draft keranjang"
  commit id: "validasi stok"
  checkout main
  commit id: "perbaiki kategori"
  merge feat/checkout id: "rilis v0.2"

Kerja paralel di repo bersama. Jalur feat/checkout berkembang sendiri lalu disatukan ke jalur utama tanpa menghapus jejak siapa pun.

Setidaknya ada enam peran yang Git mainkan setiap hari. Keenamnya saling menopang, dan semuanya hilang begitu kamu mengandalkan salin-tempel folder.

Mari rasakan langsung. Tiga perintah berikut membuat repo, menyetujui satu perubahan ke staging, lalu mengabadikannya sebagai commit pertama.

TerminalSalin
mkdir skincare-backend && cd skincare-backend
git init
echo "# Skincare Backend" > README.md
git add README.md
git commit -m "chore: inisialisasi proyek"

Setelah git commit, kamu sudah memiliki satu titik histori yang permanen. Mulai detik ini, setiap perubahan punya rumah yang aman dan setiap keputusan teknis punya jejak. Itulah fondasi cara tim software bekerja: bukan karena Git menyimpan file, melainkan karena Git mengoordinasikan manusia di sekitar file tersebut. Pertanyaan berikutnya yang wajar: bagaimana sebenarnya Git menyimpan titik histori itu di balik layar? Itu yang kita bedah di section berikut.

Git menyimpan snapshot utuh; tiga area kerja

Kunci memahami Git adalah satu kalimat: tiap commit menyimpan snapshot utuh proyek, bukan daftar perubahan yang menumpuk.

Banyak sistem versi lama berpikir dalam diff: mereka menyimpan “baris 10 berubah, baris 22 dihapus” lalu menumpuknya. Git memilih cara berbeda. Saat kamu commit, Git memotret seluruh isi proyek pada momen itu dan menyimpannya sebagai snapshot. File yang tidak berubah tidak disalin ulang, melainkan ditunjuk kembali ke isi yang identik. Hasilnya histori terasa seperti rangkaian foto utuh, bukan tumpukan catatan tambal sulam.

Agar snapshot itu hemat dan konsisten, Git bersifat content-addressable: setiap potongan isi diberi nama dari hash isinya sendiri. Isi file mentah disimpan sebagai blob, struktur folder sebagai tree, dan satu commit menunjuk ke satu tree (snapshot proyek) plus pointer ke parent (commit sebelumnya). Karena nama objek berasal dari isinya, isi yang sama otomatis berbagi penyimpanan, dan perubahan sekecil apa pun menghasilkan hash berbeda yang langsung terdeteksi.

flowchart LR
  WT["Working tree<br/>(file di disk)"] -->|git add| ST["Staging area<br/>(index)"]
  ST -->|git commit| CM["Commit<br/>(snapshot + parent)"]
  C1["commit A"] --> C2["commit B"] --> C3["commit C (HEAD)"]

Dua sudut pandang. Atas: perjalanan satu perubahan dari disk ke commit. Bawah: commit bertaut ke parent membentuk rantai snapshot.

Soal nama objek, Git default memakai SHA-1 dan sedang dalam transisi resmi ke SHA-256. Untuk kerja harian perbedaannya tak terasa; yang penting dipahami adalah idenya: nama sama dengan hash dari isi. Itu yang membuat Git bisa memverifikasi integritas histori dan mendeteksi korupsi data.

Git mengatur kerja lewat tiga area: working tree (file yang kamu edit di disk), staging area alias index (ruang tunggu tempat kamu memilih perubahan mana yang akan masuk commit berikutnya), dan repository (database objek di dalam .git tempat snapshot disimpan permanen). Detail mendalam tiga area ini dibahas di Chapter 2 saat kita masuk alur kerja harian; di sini cukup pahami bahwa staging memberimu kontrol untuk menyusun commit yang rapi, bukan asal melempar semua perubahan sekaligus.

Identitas commit, config, dan isi folder .git

Sebelum commit pertama yang serius, luangkan lima menit menyetel identitas dan preferensi Git agar setiap jejak yang kamu tinggalkan benar dan konsisten.

Setiap commit mencatat siapa penulisnya. Bila identitas belum diset, commit-mu akan tertempel nama dan email asal yang membuat histori sulit ditelusuri dan riwayat kontribusi berantakan. Karena itu langkah pertama adalah menyetel user.name dan user.email secara global, lalu menentukan beberapa preferensi yang akan terasa setiap hari.

TerminalSalin
git config --global user.name "Nama Kamu"
git config --global user.email "kamu@contoh.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global core.autocrlf input

Empat baris setelah identitas itu penting dipahami, bukan sekadar disalin. init.defaultBranch main menetapkan nama branch awal saat git init, mengikuti standar komunitas dan hosting modern yang memakai main. core.editor menentukan editor yang dibuka saat Git butuh pesan panjang (misalnya saat rebase interaktif); --wait memastikan Git menunggu sampai editor ditutup. core.autocrlf input mengatur line endings: ia menormalkan akhir baris ke gaya Unix saat menyimpan ke repo, penting di tim lintas sistem operasi agar diff tidak penuh perubahan palsu. Untuk autentikasi ke remote, credential helper menyimpan kredensial agar kamu tidak mengetik token berulang.

Setelah config beres, git init mengubah folder biasa menjadi repository dengan membuat subfolder .git. Folder inilah otak repo: ia menyimpan seluruh objek (blob, tree, commit), referensi branch, dan konfigurasi lokal.

Di dalam repo, setiap file berada di salah satu status lifecycle. File yang belum pernah Git lihat berstatus untracked; setelah git add, ia menjadi tracked dan masuk pengawasan Git. Jalankan git status kapan saja untuk membaca peta ini.

TerminalSalin
git init
git status

stateDiagram-v2
  [*] --> Untracked: file baru
  Untracked --> Staged: git add
  Staged --> Committed: git commit
  Committed --> Modified: edit file
  Modified --> Staged: git add

Lifecycle file. Dari untracked sampai committed, lalu kembali berputar setiap kali file disunting.

Fondasi yang menopang seluruh chapter berikut

Tiga ide chapter ini, kenapa Git, model snapshot, dan repo lokal yang benar, adalah lantai tempat semua perintah lanjutan berdiri.

Kita mulai dari pergeseran cara pikir: Git mengoordinasikan manusia di sekitar kode, bukan sekadar menyimpan file. Lalu kita lihat mesin di baliknya, snapshot content-addressable dengan tiga area kerja yang membuat pindah versi jadi murah dan integritas terjamin. Terakhir, kita siapkan repo lokal dengan identitas dan preferensi yang benar agar setiap jejak yang kamu tinggalkan rapi sejak commit pertama. Di Chapter 2 kita pakai fondasi ini untuk menjalani alur kerja harian: memilih perubahan dengan staging, menulis commit yang baik, dan membaca history.