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: version control (riwayat berversi), history (catatan kenapa kode jadi seperti sekarang), collaboration (banyak orang satu basis kode), rollback (kembali ke versi sehat saat ada bug), code review (perubahan ditinjau sebelum masuk), dan release tracking (menandai versi mana yang dirilis). 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.

Git menyimpan snapshot, bukan diff; 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 = 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 section 04; 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.

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"

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.

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, menjelaskan kenapa perubahan ini perlu, bukan mengulang apa yang sudah terbaca dari diff.

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"

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.

Bila ingin melihat satu commit secara utuh, git show <hash> menampilkan metadata sekaligus diff lengkapnya. Untuk membandingkan dua titik mana pun, git diff a..b menunjukkan selisih dari commit a ke b, berguna saat menyiapkan release atau meninjau apa yang berubah sejak tag terakhir.

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.

Branch adalah pointer ringan ke commit

Branch bukan salinan kode, melainkan pointer ringan yang menunjuk ke satu commit, dan itulah kenapa Git memberanikan kita membuatnya sesering apa pun.

Pada section sebelumnya kita melihat histori sebagai rantai commit yang saling menunjuk ke parent-nya. Branch adalah lapisan di atas rantai itu: sebuah nama yang menyimpan satu hash commit. Tidak ada folder baru, tidak ada penggandaan file. Saat kamu menjalankan git branch feature/login, Git hanya menulis satu baris berisi hash ke dalam .git/refs/heads/. Itu sebabnya membuat branch terasa instan, bahkan pada repo dengan ratusan ribu commit.

Yang membuat branch terasa “hidup” adalah HEAD. HEAD adalah pointer ke branch yang sedang aktif, bukan langsung ke commit. Saat kamu commit, Git menambah commit baru lalu menggeser pointer branch yang ditunjuk HEAD untuk menunjuk commit baru itu. Branch lain tidak bergerak. Inilah mekanisme isolasi: pekerjaan di feature/login tidak menyentuh main sampai kamu memutuskan menggabungkannya.

flowchart LR
  C1["c1"] --> C2["c2"]
  C2 --> C3["c3 main"]
  C2 --> C4["c4 feature"]
  HEAD(["HEAD"]) -.-> C4

Branch sebagai pointer. main menunjuk c3, feature menunjuk c4, dan HEAD menandai feature sebagai branch aktif.

Di proyek skincare-backend, alur ini sangat praktis. Misalnya main memuat kode yang sudah jalan di produksi, sementara kamu sedang menggarap endpoint checkout. Kamu buat branch feature/checkout, bekerja bebas di sana, dan main tetap utuh siap dirilis kapan saja tanpa terkontaminasi kode setengah jadi.

Untuk berpindah branch, perintah modern adalah git switch. Versi lama memakai git checkout yang memikul peran ganda (pindah branch sekaligus memulihkan file), sehingga Git memisahnya menjadi git switch dan git restore. git checkout masih ada dan berfungsi, tapi untuk berpindah branch sebaiknya pakai git switch agar niat kode lebih jelas.

TerminalSalin
# membuat dan langsung pindah ke branch baru
git switch -c feature/login
# ... edit file, lalu:
git add .
git commit -m "feat: tambah handler login"

# kembali ke main; commit feature/login tidak terbawa ke sini
git switch main
git log --oneline   # commit login tidak terlihat di main

git switch -c feature/login setara dengan git branch feature/login lalu git switch feature/login dalam satu langkah, jadi kamu langsung berada di ruang kerja baru.

Fast-forward versus three-way merge

Merge adalah cara Git menyatukan pekerjaan dari satu branch ke branch lain, dan hasilnya bergantung pada apakah base sudah bergerak sejak branch dibuat.

Setelah pekerjaan di feature/login selesai dan teruji, kamu ingin perubahannya masuk ke main. Caranya: pindah ke branch tujuan, lalu jalankan git merge. Git punya dua strategi yang dipilih otomatis tergantung bentuk histori, dan memahami keduanya membuat histori proyekmu lebih mudah dibaca.

Kasus pertama adalah fast-forward. Ini terjadi bila main tidak menerima commit baru sejak feature/login dipisah, sehingga commit main masih merupakan leluhur (ancestor) dari ujung feature. Karena tidak ada yang perlu didamaikan, Git cukup menggeser pointer main maju ke commit terakhir feature. Tidak ada commit baru yang dibuat; histori tetap satu garis lurus.

Kasus kedua adalah three-way merge. Ini terjadi bila kedua branch sama-sama maju: ada commit baru di main dan ada commit baru di feature. Git tidak bisa sekadar menggeser pointer karena keduanya menyimpang. Git mengambil tiga titik (ujung kedua branch dan commit leluhur bersama), menggabungkannya, lalu membuat merge commit yang istimewa karena punya dua parent.

gitGraph
  commit id: "c1"
  commit id: "c2"
  branch feature/login
  checkout feature/login
  commit id: "f1"
  commit id: "f2"
  checkout main
  commit id: "m1"
  merge feature/login id: "merge"

Three-way merge. Karena main maju dengan m1 dan feature dengan f1, f2, Git membuat merge commit berisi dua parent.

TerminalSalin
# pindah ke branch tujuan dulu
git switch main

# fast-forward bila main belum bergerak sejak feature dibuat
git merge feature/login
# Updating a1b2c3d..e4f5g6h
# Fast-forward

# memaksa merge commit walau sebenarnya bisa fast-forward
git merge --no-ff feature/login

Kapan memilih --no-ff? Flag ini memaksa Git membuat merge commit meski fast-forward sebenarnya mungkin. Hasilnya, jejak bahwa serangkaian commit itu berasal dari satu feature branch tetap terlihat sebagai satu gugus di histori. Banyak tim memakai --no-ff saat menggabungkan feature ke main agar histori bercerita “ini sekelompok perubahan untuk satu fitur”, bukan deret commit datar yang sulit dilacak asalnya.

Saat Git tidak bisa menggabungkan otomatis

Merge conflict bukan tanda ada yang rusak, melainkan momen Git jujur bahwa ia tidak punya cukup informasi untuk memilih gabungan yang benar, dan menyerahkan keputusan itu kepadamu.

Konflik muncul ketika dua branch mengubah baris yang sama pada file yang sama, atau satu sisi mengubah file sementara sisi lain menghapusnya. Untuk perubahan yang menyentuh baris berbeda, Git menggabungkan otomatis tanpa kamu sadari. Hanya saat dua sisi bertabrakan di baris yang persis sama, Git berhenti, menandai file, dan meminta penyelesaian manual.

Saat konflik terjadi, Git menyisipkan conflict marker ke dalam file. Ada tiga penanda: kepala <<<<<<< menandai awal versi branch saat ini (current), pemisah ======= membatasi kedua versi, dan ekor >>>>>>> menutup versi yang masuk (incoming). Tugasmu mengganti seluruh blok bertanda ini dengan versi final yang benar.

internal/order/service.go (saat konflik)Salin
func calcTotal(items []Item) int64 {
<<<<<<< HEAD
	var total PriceRupiah
	for _, it := range items {
		total += it.Price * int64(it.Qty)
	}
=======
	var total int64
	for _, it := range items {
		total += it.Subtotal
	}
>>>>>>> feature/discount
	return int64(total)
}

Setelah membaca kedua sisi, kamu menulis ulang blok itu menjadi satu versi yang menggabungkan maksud keduanya, lalu menghapus semua marker. Hasil resolusi bisa berupa gabungan ide dari kedua branch, bukan sekadar memilih salah satu mentah-mentah.

internal/order/service.go (setelah resolve)Salin
func calcTotal(items []Item) PriceRupiah {
	var total PriceRupiah
	for _, it := range items {
		total += it.Price*int64(it.Qty) - it.Discount
	}
	return total
}

Begitu file beres, kamu menandainya selesai dengan git add <file>, lalu menuntaskan merge dengan git commit. Bila ternyata situasinya terlalu rumit dan kamu ingin mundur, git merge --abort mengembalikan working tree ke kondisi sebelum merge dimulai, seolah merge tak pernah terjadi.

Menghubungkan repo lokal dengan workspace tim

Sampai sini Git masih sepenuhnya lokal, hidup di folder .git di laptopmu sendiri. Remote adalah pintu keluarnya ke tim.

Sebuah remote hanyalah repo Git lain yang bisa kamu ajak bertukar commit lewat jaringan, entah itu GitHub, GitLab, atau server internal kantor. Repo lokalmu menyimpan daftar remote beserta URL-nya, dan menurut konvensi remote utama bernama origin. Lihat daftarnya dengan git remote -v (flag -v menampilkan URL fetch dan push). Yang penting dipahami, Git itu terdistribusi: setiap klona membawa salinan riwayat penuh, dan origin bukan “pusat ajaib”, ia cuma satu repo yang kebetulan disepakati tim sebagai titik temu bersama.

Saat kamu menghubungkan ke remote, Git membuat remote-tracking branch seperti origin/main. Ini adalah cermin lokal dari posisi main di remote pada saat terakhir kamu berkomunikasi dengannya. Penting: origin/main tidak diperbarui sendiri, ia hanya bergerak ketika kamu menjalankan fetch atau pull. Jadi main (branch kerjamu) dan origin/main (cermin remote) bisa berbeda, dan justru selisih itulah yang ingin kamu pahami sebelum menggabungkan.

flowchart LR
  subgraph Lokal["Repo lokal"]
    L["main"]
    OM["origin/main (cermin)"]
  end
  subgraph Remote["origin (GitHub)"]
    R["main"]
  end
  R -- "git fetch" --> OM
  L -- "git push" --> R
  OM -. "merge / rebase" .-> L

Fetch lalu push. Fetch memperbarui cermin origin/main, push mengirim commit lokal ke remote. Penggabungan ke main lokal adalah langkah terpisah yang kamu kendalikan.

Di sinilah git fetch dan git pull berbeda secara fundamental. git fetch mengunduh objek dan commit baru dari remote lalu menggerakkan origin/main, tetapi tidak menyentuh branch aktifmu. Working tree dan main lokal tetap apa adanya. git pull adalah fetch yang langsung disusul integrasi ke branch aktif, secara default lewat merge (atau rebase bila kamu pakai git pull --rebase). Karena pull menggabungkan tanpa memberimu jeda untuk melihat, fetch dulu lalu lihat selisihnya adalah kebiasaan yang lebih tenang.

Untuk push pertama kali sebuah branch, gunakan git push -u origin main. Flag -u (singkatan --set-upstream) menetapkan upstream: relasi tetap antara branch lokalmu dan origin/main. Setelah upstream tersetel, git push, git pull, dan git status tahu lawan bicaranya tanpa kamu sebutkan lagi, dan git status bahkan akan memberitahu “your branch is ahead of origin/main by 2 commits”.

TerminalSalin
# hubungkan repo lokal ke remote dan dorong main pertama kali
git remote add origin git@github.com:kamu/skincare-backend.git
git remote -v
git push -u origin main

# lihat update tim tanpa mengubah branch aktif, lalu bandingkan
git fetch origin
git log --oneline main..origin/main      # commit yang ada di remote, belum di lokal
git status                                # ahead/behind terhadap upstream

Lalu ada momen yang pasti kamu temui: push ditolak dengan pesan ! [rejected] ... (non-fast-forward). Artinya remote sudah punya commit yang belum ada di repo lokalmu (rekan setim mendorong duluan), sehingga push-mu akan menghapus jejak mereka. Git menolak demi keselamatan. Penyelesaiannya bukan memaksa, melainkan menarik dulu pekerjaan mereka, menumpuk commit-mu di atasnya, baru mendorong lagi.

Tempat review, CI, dan keputusan merge

Mendorong branch ke remote baru setengah cerita, pull request adalah tempat branch itu ditinjau, diuji, dan diputuskan layak masuk main.

Pull request (PR di GitHub) atau merge request (MR di GitLab) adalah usulan formal untuk menggabungkan branch-mu ke branch target. Ia jauh lebih dari tombol merge: PR menyatukan judul yang jelas, deskripsi yang menjelaskan kenapa perubahan ini ada, reviewer yang ditunjuk, status check dari CI, dan keputusan approval. Inti reviewnya berbasis diff, jadi reviewer membaca selisih baris demi baris, bukan menjalankan seluruh aplikasi di kepala mereka. Karena itulah PR menjadi titik kendali mutu sekaligus arsip keputusan: enam bulan kemudian, PR-lah yang menjelaskan mengapa PriceRupiah diubah menjadi int64.

flowchart LR
  B["branch feature"] --> P["git push"]
  P --> PR["buka Pull Request"]
  PR --> RV["review + CI checks"]
  RV -->|request changes| FIX["push perbaikan"]
  FIX --> RV
  RV -->|approve + hijau| MG["merge ke main"]
  MG --> DP["deploy"]

Siklus pull request. Branch didorong, PR dibuka, review dan CI berputar sampai hijau dan disetujui, baru merge lalu deploy.

Alur code review yang sehat punya ritme khas. Reviewer bisa meninggalkan comment biasa untuk diskusi, suggestion yang berisi potongan kode siap-terima sekali klik, request changes yang memblokir merge sampai diperbaiki, atau approve yang memberi lampu hijau. Sebagai penulis, tanggapi setiap komentar, dorong commit perbaikan ke branch yang sama (PR memperbarui dirinya otomatis), dan tandai percakapan selesai. Yang paling menentukan kualitas review bukan ketajaman reviewer, melainkan ukuran PR: diff 60 baris diperiksa teliti dalam sepuluh menit, diff 1.500 baris hanya akan dapat “LGTM” yang sebenarnya berarti “saya menyerah membacanya”.

Deskripsi PR yang baik menjawab tiga hal sekaligus: apa yang berubah, kenapa, dan bagaimana cara memverifikasinya. Reviewer yang membaca diff tidak otomatis tahu konteks bisnisnya, jadi deskripsilah yang memberi mereka peta.

PR descriptionSalin
## Apa
Tambah endpoint POST /v1/products untuk membuat produk skincare.

## Kenapa
Tim katalog perlu menambah SKU baru tanpa akses langsung ke database.
Harga disimpan sebagai PriceRupiah int64 (rupiah penuh, bukan float)
agar bebas galat pembulatan.

## Cara verifikasi
- `go test ./internal/product/...` hijau
- curl contoh ada di komentar pertama

Melindungi main dengan review, status check, dan owner

PR hanya berarti bila aturannya ditegakkan, branch protection memastikan tidak ada perubahan yang menyelinap ke main tanpa review dan CI.

Branch penting seperti main adalah sumber kebenaran yang biasanya jadi dasar deploy, jadi ia layak dipagari. GitHub menyediakan dua mekanisme: branch protection rules klasik dan rulesets modern yang lebih luwes. Rulesets bisa banyak aktif bersamaan, punya status on/off, dan dapat dilihat siapa pun yang punya akses baca; menurut dokumentasi GitHub tentang rulesets, aturan-aturan ini “layer with protection rules” sehingga ketika tumpang tindih, yang paling restriktif yang menang. Aturan yang paling sering dipakai: wajib pull request sebelum merge dengan jumlah approval tertentu, wajib status check (CI) lulus, blokir force push, dan larang penghapusan branch.

Reviewer tidak harus ditunjuk manual setiap kali. File CODEOWNERS memetakan path ke pemilik, sehingga GitHub otomatis meminta review dari tim yang tepat begitu PR menyentuh file di area mereka. File ini dicari di .github/, root, lalu docs/, dan sintaksnya mengikuti pola gitignore diikuti @username atau @org/team-name. Menurut dokumentasi GitHub tentang code owners, bila digabung dengan aturan “require review from Code Owners”, satu approval dari salah satu owner sudah cukup.

CODEOWNERSSalin
# Owner default untuk semua file
*                   @org/maintainers

# Per area: yang paling spesifik menang
/frontend/          @org/team-fe
/backend/           @org/team-be
/infra/             @org/team-infra

# Pola bisa per ekstensi atau direktori dalam
**/*.sql            @org/team-be

Menyetel proteksi pada main hanya beberapa langkah lewat antarmuka GitHub.

Linear history, merge vs rebase, dan interactive rebase

Rebase memindahkan commit branch-mu ke atas base terbaru, menulis ulang sejarah agar menjadi garis lurus yang mudah dibaca.

Saat kamu bekerja di branch feature/checkout, branch main tidak diam. Rekanmu terus merge fitur lain ke sana. Kalau nanti kamu merge balik, sejarah jadi rumit: garis bercabang, merge commit di mana-mana, dan git log terlihat seperti peta kereta bawah tanah. Rebase menawarkan jalan lain: alih-alih menyatukan dua cabang dengan merge commit, ia mengangkat commit-commitmu dan menanamnya ulang satu per satu di atas ujung main yang terbaru.

Dokumen GitHub menyebut rebasing sebagai cara “menulis ulang riwayat commit”, yang membuat riwayat lebih bersih namun harus dipakai dengan hati-hati karena commit lama digantikan oleh commit baru dengan hash berbeda.

TerminalSalin
git switch feature/checkout
git fetch origin
git rebase origin/main

Secara teknis, git rebase origin/main melakukan ini: Git mencari commit nenek moyang bersama antara feature/checkout dan origin/main, “melepas” tiap commit milikmu sejak titik itu, memindahkan HEAD ke ujung origin/main, lalu memutar ulang (replay) commit-commitmu satu demi satu. Karena induknya berubah, setiap commit mendapat hash baru. Isinya sama, identitasnya berbeda. Inilah inti dari “menulis ulang sejarah” yang harus kamu pahami benar sebelum melangkah lebih jauh.

Merge versus rebase

Keduanya menggabungkan kerja dari dua branch, tetapi menghasilkan sejarah yang berbeda secara mendasar. Merge jujur apa adanya: ia menyimpan fakta bahwa dua jalur paralel pernah ada lalu bertemu di satu merge commit. Rebase memilih kerapian: ia berpura-pura kerjamu memang dibangun di atas base terbaru, menghasilkan garis lurus tanpa merge commit.

flowchart LR
  subgraph Merge
    A1[main] --> M[merge commit]
    B1[feature] --> M
  end
  subgraph Rebase
    A2[main] --> C1[feature']
    C1 --> C2[feature'']
  end

Dua hasil akhir. Merge menyatu di satu titik; rebase memanjang lurus.

Konflik saat rebase

Karena rebase memutar ulang commit satu per satu, konflik bisa muncul di commit mana pun di tengah jalan. Saat itu terjadi, rebase berhenti dan menunggu. Pola penyelesaiannya berbeda dari merge: kamu tidak commit, melainkan melanjutkan rebase.

Interactive rebase: poles sebelum PR

git rebase -i membuka editor berisi daftar todo: tiap commit satu baris dengan kata kunci di depannya. Di sinilah kamu merapikan riwayat draft sebelum dibaca reviewer. Tiga commit “wip”, “fix typo”, dan “beneran fix” bisa dilebur jadi satu commit bersih yang menceritakan satu perubahan utuh.

TerminalSalin
git rebase -i HEAD~3
# editor terbuka:
# pick a1b2c3d add product handler
# fixup d4e5f6a fix typo
# fixup 9z8y7x6 wip
# simpan & tutup → tiga commit jadi satu

Membatalkan perubahan dengan aman

Git punya beberapa cara membatalkan perubahan, dan salah memilih bisa menghapus kerja keras secara permanen.

Pertanyaan “bagaimana cara undo di Git?” tidak punya satu jawaban, karena tergantung kamu ingin membatalkan apa: perubahan file yang belum di-commit, staging yang keliru, atau commit yang sudah masuk sejarah. Empat perintah menangani kasus yang berbeda, dan memahami batas masing-masing menyelamatkanmu dari kehilangan data.

git restore: buang perubahan working tree

git restore menangani file yang sudah kamu ubah tapi belum di-commit. Ada dua arah: mengembalikan isi file ke versi terakhir, atau mengeluarkannya dari staging area.

TerminalSalin
git restore internal/product/service.go   # buang edit, kembali ke HEAD
git restore --staged internal/product/service.go   # unstage, edit tetap ada

git reset: memindahkan HEAD

reset menggeser pointer HEAD ke commit lain, dan tiga modenya menentukan area mana yang ikut berubah. Inilah perintah yang paling sering disalahpahami, dan --hard adalah yang paling berbahaya.

TerminalSalin
git reset --soft HEAD~1    # batalkan commit terakhir, isinya tetap tersimpan & staged
git reset HEAD~1           # (--mixed) batalkan commit, isi jadi unstaged di working tree
git reset --hard HEAD~1    # batalkan commit DAN buang semua perubahannya

--soft berguna saat kamu ingin menyusun ulang commit terakhir tanpa kehilangan apa pun. --mixed mengembalikan perubahan ke working tree untuk dipilah ulang. --hard membuang semuanya tanpa ampun.

git revert: undo aman untuk sejarah publik

reset cocok untuk commit lokal, tapi berbahaya bila commit sudah di-push. Untuk membatalkan commit yang sudah dibagikan, pakai git revert. Alih-alih menghapus, ia membuat commit baru yang isinya kebalikan dari commit target. Sejarah tetap utuh, hash lama tetap ada, dan rekanmu tidak terganggu.

flowchart LR
  A[C1] --> B[C2 buggy] --> C[C3] --> D[C4 revert C2]

Revert menambah, bukan menghapus. C4 membalik efek C2 tanpa menyentuh sejarah yang sudah dipush.

TerminalSalin
git revert a1b2c3d   # buat commit baru yang membalik a1b2c3d

git stash: simpan sementara

Kadang kamu sedang setengah jalan mengerjakan sesuatu lalu harus pindah branch untuk perbaikan mendesak. git stash menyimpan perubahan yang belum di-commit ke tumpukan terpisah, membersihkan working tree, lalu bisa kamu kembalikan nanti.

TerminalSalin
git stash push -m "wip checkout"
git stash list                      # lihat semua stash
git switch hotfix/price-bug
# ... perbaiki, commit ...
git switch feature/checkout
git stash pop                       # lanjutkan kerja sebelumnya

Release, kebersihan repo, dan automasi pesan

Empat alat kebersihan yang membuat repo bisa dirilis dengan rapi dan dijaga tetap bersih tanpa disiplin manual.

Sejauh ini fokus kita pada bagaimana commit mengalir. Section ini melengkapi gambar dengan empat hal di sekelilingnya, menandai titik rilis (tag), menjaga file yang tak layak masuk (.gitignore), menjalankan pengecekan otomatis di momen tepat (hooks), dan menyepakati format pesan (Conventional Commits). Keempatnya saling menguatkan, tag dan pesan terstruktur memungkinkan changelog otomatis, hook memaksa pesan itu valid sebelum commit terbentuk.

Tag: menandai versi rilis

Tag adalah penanda permanen pada sebuah commit, biasanya untuk versi rilis. Ada dua jenis. Lightweight tag hanya pointer ke commit, seperti branch yang tidak bergerak. Annotated tag adalah objek penuh dengan nama tagger, tanggal, pesan, dan bisa ditandatangani GPG. Untuk rilis publik selalu pakai annotated.

TerminalSalin
git tag -a v1.0.0 -m "Rilis publik pertama skincare-backend"
git tag                       # daftar tag lokal
git show v1.0.0               # lihat objek tag + commit yang ditunjuk
git push origin v1.0.0        # tag tidak ikut push biasa, dorong eksplisit
git push origin --tags        # atau dorong semua tag sekaligus

Penomoran versi mengikuti Semantic Versioning, MAJOR.MINOR.PATCH. MAJOR naik saat ada perubahan yang memecah kompatibilitas, MINOR saat ada fitur baru yang tetap kompatibel, PATCH saat hanya perbaikan bug. Pemetaan ini bukan kebetulan, ia selaras persis dengan Conventional Commits di bawah.

.gitignore: menjaga repo tetap bersih

Repo backend tidak perlu menyimpan dependensi, rahasia, atau hasil build. File-file itu besar, berbeda per mesin, atau berbahaya bila bocor. .gitignore mendaftar pola yang Git abaikan.

.gitignoreSalin
# dependensi & build
node_modules/
/bin/
/tmp/
*.exe

# rahasia (JANGAN pernah commit)
.env
.env.*
!.env.example

# file OS & editor
.DS_Store
Thumbs.db
.idea/
.vscode/

Pola membaca seperti ini, / di akhir berarti hanya cocok direktori, / di awal meng-anchor relatif ke lokasi file .gitignore, dan tanpa / cocok di level mana pun. Tanda ! me-re-include file yang tadinya terabaikan, di contoh atas .env.* mengabaikan semua varian tapi .env.example tetap dilacak agar tim tahu kunci apa yang dibutuhkan. Untuk pola lintas semua proyek (mis. .DS_Store), pakai global ignore via git config --global core.excludesFile ~/.config/git/ignore.

Git hooks: automasi di momen tepat

Hook adalah skrip yang Git jalankan otomatis pada event tertentu. Tiga yang paling berguna di sisi klien, pre-commit (sebelum pesan ditulis, untuk lint/format/test cepat), commit-msg (validasi format pesan), dan pre-push (cek terakhir sebelum objek dikirim ke remote). Bila hook keluar dengan kode non-nol, operasi dibatalkan.

.git/hooks/pre-commitSalin
#!/bin/sh
# format & vet sebelum snapshot commit terbentuk
gofmt -l . | grep . && echo "Jalankan gofmt dulu" && exit 1
go vet ./... || exit 1
exit 0

Hook hidup di .git/hooks/ dan tidak ikut saat clone, jadi disiplin tim tidak terjaga sendiri. Karena itu tim memakai manajer hook yang menyimpan konfigurasi di dalam repo dan memasangnya lewat core.hooksPath. Pilihan umum, husky (ekosistem Node/npm), lefthook (ditulis Go, cepat dan paralel, cocok untuk proyek polyglot), dan pre-commit (berbasis Python, banyak bahasa).

Conventional Commits: pesan yang bisa diolah mesin

Conventional Commits 1.0.0 menstandarkan baris pertama pesan menjadi type(scope): description. Tipe yang lazim, feat (fitur baru), fix (perbaikan bug), docs, refactor, test, dan chore. Karena formatnya konsisten, alat bisa membaca riwayat untuk menghasilkan changelog dan menentukan versi otomatis.

Contoh pesanSalin
feat(cart): tambah endpoint POST /v1/carts/items

Hitung subtotal pakai PriceRupiah int64 agar bebas galat pembulatan.

fix(auth): tolak token kedaluwarsa dengan 401
refactor(order): pisahkan service dari handler
feat(api)!: ubah field harga jadi PriceRupiah, hapus "price_float"

BREAKING CHANGE: respons /v1/products kini memakai price_rupiah.

Pemetaan ke SemVer langsung, fix menaikkan PATCH, feat menaikkan MINOR, dan perubahan yang memecah kompatibilitas (ditandai ! setelah type atau footer BREAKING CHANGE:) menaikkan MAJOR. Gabungkan dengan commit-msg hook agar pesan yang tidak sesuai format ditolak sebelum masuk history.

GitHub Flow, GitLab Flow, Git Flow, Trunk-Based, plus hotfix

Workflow bukan aturan baku, ia cara tim menyepakati bagaimana cabang mengalir dari ide ke produksi.

Semua perintah yang sudah kamu kuasai (branch, merge, PR, rebase) adalah huruf. Workflow adalah kalimatnya, kesepakatan kapan membuat branch, ke mana ia merge, dan kapan kode mencapai pengguna. Tidak ada yang “paling benar”, yang ada adalah yang paling cocok dengan ukuran tim dan irama deployment. Mari telusuri dari yang paling sederhana.

GitHub Flow: sesederhana mungkin

GitHub Flow hanya punya satu cabang abadi, main, yang selalu siap deploy. Setiap pekerjaan lahir sebagai branch pendek dari main, dibuka sebagai Pull Request untuk review dan CI, lalu di-merge kembali dan langsung di-deploy. Branch berumur jam atau hari, bukan minggu.

gitGraph
  commit id: "init"
  commit id: "main siap"
  branch feat/cart
  checkout feat/cart
  commit id: "add cart"
  commit id: "test cart"
  checkout main
  merge feat/cart tag: "deploy"
  branch fix/auth
  checkout fix/auth
  commit id: "fix 401"
  checkout main
  merge fix/auth tag: "deploy"

GitHub Flow. Garis utama lurus, cabang lahir pendek lalu kembali dan langsung dirilis.

GitLab Flow: menambah environment branch

Saat deploy tidak instan dan perlu tahap (staging dulu, baru produksi), GitHub Flow kurang. GitLab Flow menambah environment branch. Fitur tetap merge ke main, lalu main dipromosikan downstream lewat merge request berurutan. Menurut dokumentasi GitLab, commit hanya mengalir ke hilir setelah teruji di tiap environment.

flowchart LR
  F[feature branch] -->|MR + review| M[main]
  M -->|promote| S[staging]
  S -->|MR| P[pre-production]
  P -->|MR| PR[production]

GitLab Flow dengan environment branch. Kode hanya bergerak ke kanan, tiap panah adalah gerbang yang sudah lolos uji.

Git Flow: lengkap tapi berat

Git Flow memakai banyak cabang berumur panjang, main (rilis), develop (integrasi), plus feature/*, release/*, dan hotfix/*. Cocok untuk produk dengan rilis berversi terjadwal, tapi sering terlalu berat untuk tim kecil yang deploy harian.

gitGraph
  commit id: "main"
  branch develop
  commit id: "dev base"
  branch feature/cart
  commit id: "cart"
  checkout develop
  merge feature/cart
  branch release/1.2
  commit id: "stabilize"
  checkout main
  merge release/1.2 tag: "v1.2.0"
  branch hotfix/1.2.1
  commit id: "patch"
  checkout main
  merge hotfix/1.2.1 tag: "v1.2.1"
  checkout develop
  merge hotfix/1.2.1

Git Flow. Dua cabang abadi (main + develop) plus release dan hotfix, perhatikan hotfix di-back-merge ke develop agar perbaikan tidak hilang.

Trunk-Based dan dua alur khusus

Trunk-Based Development mendorong integrasi sangat sering ke satu trunk dengan branch berumur sangat pendek (jam, bahkan langsung). Fitur yang belum siap disembunyikan di balik feature flag, bukan ditahan di branch panjang, sehingga konflik besar nyaris tak pernah terjadi. Di luar alur utama, dua pola sering muncul. Hotfix, cabang dari tag atau main untuk patch darurat, review cepat, tag versi PATCH baru, lalu back-merge agar perbaikan ikut ke cabang pengembangan. Release branch, cabang stabilisasi paralel tempat hanya bugfix yang diterima, sementara main jalan terus untuk fitur berikutnya, menghasilkan release candidate sebelum tag final.

Monorepo, submodule, bisect, pitfalls, security, CI/CD

Kumpulan kemampuan yang membedakan orang yang panik saat repo kacau dari orang yang tahu di mana commit “hilang” disimpan.

Setelah alur dasar lancar, sisa perjalanan adalah skala dan pemulihan, bagaimana repo besar dikelola, bagaimana melacak bug ke commit penyebabnya, dan apa yang dilakukan saat sesuatu terlihat lenyap. Kabar baiknya, Git jarang benar-benar membuang data, ia hanya menyembunyikannya sampai kamu tahu cara melihatnya.

Skala: monorepo, submodule, subtree

Monorepo menampung banyak layanan dalam satu repo. Kuncinya kepemilikan path lewat CODEOWNERS (file di .github/ berisi pola gitignore plus @tim), agar PR di area tertentu otomatis meminta review pemilik area. Untuk repo raksasa, sparse-checkout dan partial clone membuatmu mengunduh hanya bagian yang dikerjakan. Submodule dan subtree menyematkan repo lain, submodule menyimpan pointer ke commit eksternal, tapi keduanya menambah kompleksitas nyata dan sering lebih baik dihindari kecuali ada kebutuhan kuat. Apa pun pilihannya, PR kecil tetap aturan emas.

git bisect: berburu commit penyebab bug

Saat sebuah bug muncul entah kapan, jangan menebak. git bisect melakukan pencarian biner di antara commit yang masih baik dan yang sudah rusak, membelah rentang sampai menemukan commit pertama yang merusak.

TerminalSalin
git bisect start
git bisect bad                 # commit sekarang rusak
git bisect good v1.0.0         # versi ini masih sehat
# Git checkout commit di tengah, kamu uji, lalu beri tahu hasilnya:
git bisect good                # atau: git bisect bad
# ulangi sampai Git menunjuk "first bad commit"
git bisect reset               # kembali ke posisi semula

Bisect. 1000 commit ditelusuri hanya dalam ~10 langkah karena tiap jawaban memotong setengah ruang pencarian.

Pitfalls dan pemulihan lewat reflog

Jebakan tersering, detached HEAD, stale branch yang tertinggal jauh, commit nyasar di branch salah, dan force push yang menimpa kerja orang. Penyelamatnya satu, git reflog, catatan setiap pergerakan HEAD di mesinmu. Bahkan setelah reset --hard, commit lama masih tercatat di reflog dan bisa dipulihkan.

TerminalSalin
git reflog                     # contoh: a1b2c3d HEAD@{2}: commit: add cart
git switch -c rescue a1b2c3d   # tahan commit "hilang" dengan branch baru

Security dan CI/CD sebagai gerbang

Hygiene minimal, pastikan .env tidak pernah masuk repo, aktifkan secret scanning untuk menangkap kunci yang bocor, pertimbangkan signed commit untuk membuktikan author, dan terapkan least privilege pada akses. Bila secret pernah ter-commit, rotasi (ganti) kuncinya, menghapus dari history saja tidak cukup karena clone lama tetap menyimpannya. CI/CD mengikat semua ini, required status check menjadikan lolosnya test sebagai syarat merge (gerbang), sementara deploy bisa branch-based (merge ke main memicu staging) atau tag-based (tag v* memicu rilis produksi).

Dari kerja sendiri ke tim yang aman dan scalable

Git yang kamu kuasai sekarang bukan kumpulan perintah, melainkan satu model mental yang konsisten dari snapshot sampai kolaborasi tim.

Mari satukan benangnya. Semua dimulai dari satu ide, Git menyimpan snapshot, bukan diff. Dari sana mengalir tiga area (working tree, index, repo) yang menjelaskan kenapa add dan commit terpisah. Di atasnya berdiri commit yang baik (atomik, pesan jelas), lalu branch dan merge untuk bekerja paralel, conflict yang kamu selesaikan dengan tenang karena paham strukturnya, dan remote plus Pull Request + review untuk berbagi. Branch protection menjadikan kualitas itu wajib, sementara rebase dan operasi undo (reset, revert, reflog) memberi kendali untuk merapikan dan memulihkan. Workflow tim hanyalah cara menata semua itu untuk banyak orang.

Prinsip akhir yang menyatukan semuanya, mulai dari yang sederhana, tambah kompleksitas hanya saat tim dan deployment benar-benar membutuhkannya. Workflow yang berat sebelum waktunya adalah pajak harian tanpa imbalan.

Langkah berikutnya bukan lagi membaca, melainkan berkolaborasi nyata, buka PR pertamamu di skincare-backend, minta review, dan biarkan CI menjadi gerbang. Saat alur itu terasa alami, kamu siap menyambungkannya ke pipeline CI/CD penuh, tempat setiap merge ke main mengantar kode dengan aman sampai ke pengguna.