Merge Fast-Forward: Penggabungan Termudah

Skenario fast-forward

Bayangkan: main diam di commit A. Kamu buat branch fitur, kerja 3 commit (B, C, D). Selama itu tidak ada commit baru di main. Riwayatnya garis lurus:

A (main) --- B --- C --- D (fitur)

Karena main tidak bercabang, Git tidak perlu "menggabungkan" apa pun. Ia cukup memajukan pointer main ke D. Inilah fast-forward: tanpa commit merge, tanpa konflik, riwayat tetap garis lurus.

KENAPA mekanisme ini ada? Karena merge yang sebenarnya (menggabungkan dua jalur) butuh kerja ekstra: mencari ancestor bersama, membandingkan perubahan, membuat commit gabungan. Kalau jalurnya cuma satu, semua itu buang-buang waktu. Fast-forward adalah jalan pintas yang jujur: tidak ada yang digabung karena memang tidak ada yang bercabang.

Praktiknya

Contoh 1: merge branch fitur yang mulus.

git switch main
git merge fitur

Updating a3f9c1d..d4e5f6a
Fast-forward
 index.html | 10 ++++++++--
 1 file changed, 2 insertions(+), 8 deletions(-)

Kata Fast-forward di output adalah konfirmasinya. Baris Updating a3f9c1d..d4e5f6a menunjukkan pointer main melompat dari commit lama ke commit baru. KAPAN dipakai? Inilah alur merge paling umum sehari-hari: branch fitur selesai, pindah ke main, merge, beres.

Contoh 2: verifikasi riwayat tetap lurus setelah merge.

git log --oneline --graph -4

* d4e5f6a Tambah validasi form
* c3d2e1f Tambah halaman login
* b2a1c9d Setup awal
* a3f9c1d Commit pertama

Tidak ada garis bercabang, tidak ada commit merge. Riwayat terbaca seperti cerita linear dari bawah ke atas. KENAPA ini diinginkan? Karena git log yang linear jauh lebih gampang dibaca dan di-debug daripada riwayat penuh cabang, terutama saat kamu melacak kapan bug muncul.

Setelah merge, branch fitur biasanya dihapus karena riwayatnya sudah menyatu:

git branch -d fitur
# Deleted branch fitur (was d4e5f6a).

Kapan fast-forward terjadi, dan kapan tidak?

Fast-forward HANYA terjadi jika branch tujuan tidak punya commit baru sejak branch fitur bercabang. Ini alasan kenapa alur "branch pendek yang cepat di-merge" populer: makin cepat di-merge, makin besar peluang fast-forward, makin bersih riwayatnya.

Kalau main ikut maju saat kamu kerja (misal teman push commit E), Git tidak bisa fast-forward. Ia akan membuat merge commit (dibahas di modul merge-no-ff), atau konflik kalau keduanya menyentuh baris yang sama (modul resolve-conflict).

Kesalahan umum pemula: salah vs benar

SALAH: mengira setiap git merge pasti fast-forward, lalu kaget melihat merge commit muncul.

git merge fitur
# "kok ada commit 'Merge branch fitur'? padahal maunya lurus..."

Itu bukan error. Artinya main sudah maju duluan sejak kamu branching. Solusinya bukan menghapus merge commit, melainkan memahami kenapanya.

BENAR: cek posisi kedua branch SEBELUM merge supaya tidak terkejut.

git log --oneline --graph --all -6

Kalau grafiknya menunjukkan dua jalur bercabang, siapkan diri untuk merge commit atau rebase dulu. Kalau lurus, fast-forward dijamin terjadi.

SALAH: membiarkan branch fitur menganggur berminggu-minggu lalu merge dan heran kenapa riwayat jadi berantakan.

BENAR: sinkronkan branch fitur dengan main secara berkala (merge main ke branch-mu, atau rebase), dan merge kembali secepat fiturnya selesai. Branch yang pendek umur = merge yang bersih.

Catatan teknis: fast-forward bukan "merge" dalam arti sebenarnya, tidak ada penggabungan dua jalur karena memang cuma satu jalur. Beberapa tim justru MELARANG fast-forward (--no-ff) agar setiap fitur meninggalkan satu merge commit sebagai penanda, dibahas di modul berikutnya.