Belajar Git Branching Strategies - Konsep Dasar Branching & Visualisasi dengan Mermaid

#Pendahuluan

Setelah di episode 1 kita memahami mengapa branching strategy diperlukan — masalah kolaborasi, evolusi dari SVN ke Git, dan governance tim — pada episode ini kita masuk ke mekanisme teknis: bagaimana branch bekerja di Git, cara memvisualisasikannya, dan trade-off antara merge vs rebase.

Pemahaman konsep dasar ini penting karena semua branching strategy (GitFlow, GitHub Flow, Trunk-Based) pada akhirnya beroperasi di atas mekanisme branch, merge, dan rebase ini. Tanpa fondasi ini, kalian akan kesulitan memahami mengapa sebuah strategy memilih merge commit dibanding rebase.

#Branch di Git: Pointer Ringan

Branch di Git bukan salinan kode — branch adalah pointer ke sebuah commit. Ini adalah perbedaan fundamental dari SVN. Membuat branch semurah membuat satu file baru yang berisi 41 byte (hash SHA-1 commit).

Membuat dan melihat branch

git branch feature/latihan
git branch -a

git branch -a akan menampilkan semua branch: lokal dan remote. Branch main menunjuk ke commit terakhir di branch utama, sementara feature/latihan menunjuk ke commit yang sama (baru dibuat, belum ada commit baru).

#HEAD: Pointer ke Branch Aktif

HEAD adalah pointer spesial yang menunjuk ke branch yang sedang aktif. Saat kalian melakukan commit, HEAD bergerak maju bersama branch aktif:

Melihat HEAD dan branch aktif

cat .git/HEAD
git log --oneline -3

Pemahaman tentang HEAD penting untuk memahami bagaimana git switch dan git checkout bekerja — dan mengapa rebase bisa "memindahkan" commit.

#Visualisasi Alur Kerja dengan Mermaid

Mermaid adalah tool diagram-as-code yang didukung secara native oleh banyak platform. Sintaks gitGraph memungkinkan kalian memvisualisasikan branch, commit, dan merge secara visual:

100%

Graf di atas menunjukkan:

main linear dari A ke B ke E ke merge-1 ke F.
feature/search lahir dari B, berisi C dan D, lalu di-merge ke main di merge-1.

Visualisasi seperti ini membantu tim memahami alur kode tanpa membaca log komit yang panjang. Kita akan menggunakan Mermaid secara konsisten di sepanjang series.

#Anatomi Merge vs Rebase

Ketika sebuah feature branch selesai dan ingin di-integrasi ke main, ada dua cara utama: merge dan rebase.

#Merge: Mempertahankan History Asli

Merge feature branch ke main

git switch main
git merge feature/search

Merge menghasilkan merge commit — satu commit baru yang memiliki dua parent (commit terakhir di main dan commit terakhir di feature/search). History asli dipertahankan: kalian bisa melihat kapan branch dibuat, kapan commit dilakukan, dan kapan di-merge.

100%

#Rebase: History Linear

Rebase feature branch ke main

git switch feature/search
git rebase main
git switch main
git merge feature/search

Rebase mengambil semua commit di feature/search dan menempatkan ulang di atas commit terakhir di main. History menjadi linear — seolah-olah kalian mulai bekerja dari main terbaru. Tidak ada merge commit, graf bersih.

100%

Perhatikan commit C dan D menjadi C' dan D' — mereka adalah commit baru (hash berbeda) yang berisi konten yang sama. Ini konsekuensi penting dari rebase: history di-rewrite.

#Kapan Pakai Merge, Kapan Pakai Rebase?

Aspek	Merge	Rebase
History	Mempertahankan semua commit & branch	Linear, tanpa merge commit
Traceability	Bisa melihat kapan branch dibuat/di-merge	Kehilangan jejak branch asal
Conflict	Diselesaikan satu kali saat merge	Diselesaikan per commit saat rebase
Safety	Aman untuk branch yang sudah di-share	Berbahaya untuk branch yang sudah di-share

Warning

Aturan emas: jangan pernah rebase branch yang sudah di-push dan di-share ke orang lain. Rebase menulis ulang history — jika rekan kerja masih bekerja di branch lama, mereka akan mengalami konflik yang membingungkan.

#Fast-Forward vs Non-Fast-Forward

#Fast-Forward Merge

Ketika main tidak memiliki commit baru sejak branch feature dibuat, Git bisa melakukan fast-forward: pointer main cukup dipindahkan ke commit terakhir feature tanpa merge commit.

100%

#Non-Fast-Forward (--no-ff)

Jika main sudah bergerak maju (ada commit baru), Git melakukan non-fast-forward merge — menghasilkan merge commit. Kalian juga bisa memaksa merge commit dengan flag --no-ff meskipun fast-forward mungkin:

Paksa merge commit dengan --no-ff

git merge --no-ff feature/search -m "Merge feature/search into main"

Flag --no-ff penting untuk tracing: kalian bisa melihat kapan sebuah branch di-merge meskipun secara teknis fast-forward mungkin dilakukan. Banyak branching strategy (termasuk GitHub Flow) merekomendasikan squash merge atau --no-ff agar history tetap terbaca.

#Penutup

Pada episode 2 ini, kalian telah memahami fondasi teknis branching:

Branch di Git adalah pointer ringan ke commit, bukan salinan kode.
HEAD menunjuk ke branch aktif; commit bergerak HEAD maju.
Merge mempertahankan history asli dengan merge commit; rebase membuat history linear tetapi menulis ulang commit.
Fast-forward adalah pointer move sederhana; --no-ff memaksa merge commit untuk tracing.
Mermaid gitGraph adalah cara yang efektif untuk memvisualisasikan alur kerja.

Di episode 3 selanjutnya kita akan mempelajari Trunk-Based Development (TBD) — salah satu branching strategy paling populer di era CI/CD modern, di mana semua developer bekerja di branch utama dengan feature branch yang sangat pendek-lived. Sampai jumpa di episode 3!