Alur Kerja Harian
Stage, Commit, History

status, add, restore, diff: memilih perubahan dengan sadar

Git memisahkan perubahan menjadi tiga kondisi, dan justru di pemisahan itulah letak kendali kamu atas apa yang masuk ke sebuah commit.

Sebuah file yang kamu sentuh hidup di salah satu dari tiga kondisi: modified (sudah diubah di working tree tapi belum ditandai), staged (sudah dipilih ke staging area, siap dibungkus jadi commit), dan committed (sudah tersimpan permanen di repository). Staging area inilah yang sering diremehkan pemula: ia bukan sekadar formalitas sebelum commit, melainkan ruang untuk menyusun commit secara sadar, memilih perubahan mana yang layak masuk bersama dan mana yang ditunda.

Titik masuknya selalu git status. Perintah ini membaca ketiga area dan memberitahu kamu: file mana yang modified tapi belum staged, file mana yang sudah staged, dan file mana yang sama sekali belum dilacak (untracked). Biasakan menjalankannya sebelum dan sesudah git add, karena ia adalah kompasmu, bukan sekadar laporan.

TerminalSalin
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   internal/product/handler.go

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:   internal/product/service.go

Untuk memindahkan perubahan ke staging, git add <path>. Untuk membatalkan, ada dua arah yang sering tertukar. git restore <file> membuang perubahan di working tree (mengembalikan file ke kondisi terakhir di index, perubahanmu hilang). Sementara git restore --staged <file> hanya meng-unstage: perubahan tetap ada di working tree, hanya dikeluarkan dari staging. Perhatikan perbedaannya: yang satu membuang isi, yang satu hanya menarik dari antrean commit.

Dua perintah diff menjawab dua pertanyaan berbeda. git diff menunjukkan selisih working tree vs index: perubahan yang sudah kamu buat tapi belum di-stage. git diff --staged menunjukkan index vs HEAD: persis apa yang akan tercatat bila kamu commit sekarang. Membaca keduanya sebelum commit adalah kebiasaan yang memisahkan commit rapi dari commit berantakan.

Mari praktik. Ubah dua file, stage satu, lalu bandingkan kedua diff sebelum commit.

TerminalSalin
$ git add internal/product/handler.go   # stage satu file saja
$ git diff                              # sisa yang BELUM di-stage (service.go)
$ git diff --staged                     # yang AKAN masuk commit (handler.go)
$ git commit -m "Validate price is positive in product handler"

Di dunia nyata, kemampuan memilih potongan inilah yang menyelamatkan history. Bayangkan kamu sedang memperbaiki validasi harga, tapi di tengah jalan iseng merapikan nama variabel di fungsi yang sama. Dua hal itu tidak berhubungan, dan menggabungnya jadi satu commit membuat keduanya sulit dipisah nanti. git add -p menyelesaikan ini: ia menampilkan tiap hunk dan bertanya y/n, sehingga satu file berisi dua perubahan bisa dipecah jadi dua commit terpisah.

Atomic, pesan jelas, why over what

Commit yang baik bukan tentang menyimpan kode, melainkan menulis catatan yang masih masuk akal saat dibaca enam bulan kemudian oleh orang yang lupa konteksnya, termasuk dirimu sendiri.

Prinsip pertama adalah atomic: satu commit memuat satu perubahan logis yang utuh. Bukan “satu file”, bukan “satu hari kerja”, tapi satu ide yang bisa dijelaskan dalam satu kalimat. Commit atomic membuat git log mudah dibaca, git revert aman (membatalkan satu commit tidak ikut menghapus hal lain), dan git bisect efektif saat memburu bug. Bila kamu menggabungkan perbaikan validasi harga dengan rename variabel di satu commit, dua-duanya jadi sulit dipisah lagi nanti. Inilah kenapa git add -p di section sebelumnya penting: ia alat untuk menjaga keatomikan.

Prinsip kedua adalah pesan yang menjelaskan kenapa. Pesan commit punya dua bagian: subject (baris pertama) dan body (paragraf setelah baris kosong). Subject ditulis imperatif dan singkat, sekitar maksimal 50 karakter, seolah memberi perintah: “Add”, “Fix”, “Refactor”, bukan “Added” atau “Fixing”. Body, yang opsional, dibungkus sekitar 72 karakter per baris dan menjelaskan kenapa perubahan ini perlu, bukan mengulang apa yang sudah terbaca dari diff. Konvensi 50/72 ini bukan rewel gaya: subject pendek tampil utuh di git log --oneline, di daftar PR, dan di antarmuka hosting tanpa terpotong.

Berikut anatomi pesan commit yang lengkap: subject imperatif singkat, baris kosong, lalu body yang menjawab “kenapa”.

Pesan commitSalin
Reject negative price at product creation

PriceRupiah disimpan sebagai int64 dalam rupiah penuh, tapi handler
lama menerima nilai negatif tanpa keluhan, lalu lolos sampai ke
database. Validasi di tepi mencegah data harga rusak masuk ke sistem
diskon yang mengandalkan nilai non-negatif.

Prinsip ketiga: pecah perubahan besar jadi beberapa commit logis. Bila satu sesi kerja menyentuh validasi, lalu rename, lalu perbaikan test, stage dan commit terpisah dengan bantuan git add -p agar tiap commit tetap atomic.

TerminalSalin
$ git add -p internal/product/service.go   # pilih hunk validasi saja
$ git commit -m "Reject negative price at product creation"
$ git add -p internal/product/service.go   # sekarang hunk rename
$ git commit -m "Rename priceCents to priceRupiah for clarity"

Format pesan terstruktur ini punya kelanjutan yang kuat. Di Chapter 6 kita lihat bagaimana konvensi type(scope): description (Conventional Commits) membuat pesan bisa dibaca mesin untuk menghasilkan changelog dan menentukan versi rilis otomatis. Kebiasaan menulis subject imperatif yang jelas sekarang adalah modal untuk otomasi itu nanti.

log, show, diff tanpa rasa takut

History bukan museum yang hanya dipajang, melainkan alat investigasi: ia menjawab kenapa sebuah baris ada, kapan sebuah bug masuk, dan apa yang berubah di antara dua rilis.

Pintu utamanya git log. Apa adanya ia menampilkan tiap commit beserta hash, author, date, dan pesan, dari yang terbaru ke terlama. Tapi yang membuatnya berguna adalah flag-flagnya. --oneline memampatkan tiap commit jadi satu baris. --graph menggambar struktur cabang dengan garis ASCII. --all menyertakan semua branch, bukan hanya yang sedang aktif. Dikombinasikan, ketiganya memberi peta repositori yang cepat dibaca.

TerminalSalin
$ git log --oneline --graph --all
* 8f3a1c2 (HEAD -> main) Reject negative price at product creation
* a1b9d04 Add price validation to product handler
| * 4c7e8f1 (feat/discount) Add discount engine skeleton
|/
* 2d5a6b3 Initialize skincare-backend module layout

Peta cabang dari satu perintah. Garis menunjukkan feat/discount bercabang dari commit yang sama dengan main.

Secara model, history adalah rantai commit yang tiap simpulnya menunjuk ke induknya. Pada satu branch lurus, rantai itu terlihat seperti ini.

gitGraph
  commit id: "init module"
  commit id: "add handler"
  commit id: "validate price"
  commit id: "reject negative"

Rantai commit linear. Tiap commit menyimpan snapshot penuh dan menunjuk ke induknya, sehingga history bisa ditelusuri mundur.

Beberapa “lensa” history paling sering kamu pakai di kerja nyata, masing-masing menjawab satu pertanyaan investigasi yang berbeda.

TerminalSalin
$ git show 8f3a1c2                 # metadata + diff satu commit
$ git diff a1b9d04..8f3a1c2        # selisih antara dua commit
$ git log -p -- internal/product/service.go   # riwayat + diff satu file
$ git log --follow -- internal/product/price.go  # ikut menembus rename file

Sering yang kamu butuhkan bukan seluruh history, melainkan siapa yang menyentuh satu file. git log -- path/file menyaring commit yang mengubah file tersebut, dan --follow membuat penelusuran tetap utuh meski file pernah di-rename. Tambahkan -p untuk melihat diff tiap perubahannya, sehingga evolusi sebuah file terbaca seperti cerita.

Loop harian yang menjaga history tetap berharga

Tracking, commit, dan history adalah satu lingkaran: kualitas dua yang pertama menentukan nilai yang ketiga.

Kamu kini punya loop harian yang utuh. Staging memberi kendali memilih perubahan dengan sadar, lebih baik git add -p ketimbang refleks git add .. Commit atomic dengan subject imperatif dan body yang menjelaskan “kenapa” membuat tiap titik history bermakna. Dan git log, git show, serta git diff mengubah history dari arsip pasif menjadi alat investigasi. Di Chapter 3 kita keluar dari satu garis lurus ini: bekerja paralel lewat branch, lalu menyatukannya dengan merge dan menyelesaikan konflik.