Merge No-FF: Menjaga Jejak Fitur

Ketika riwayat bercabang

Kali ini main ikut maju saat kamu kerja di branch fitur:

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

Git tidak bisa fast-forward karena ada dua jalur. Ia membuat merge commit khusus (misal M) yang punya DUA parent:

      C --- D
     /       A --- B ----- M (main)

KENAPA merge commit ini ada? Karena Git butuh "titik pertemuan" yang jujur: commit M mendokumentasikan bahwa pada momen ini, dua jalur pengembangan yang tadinya paralel resmi disatukan. Tanpa M, riwayat akan berbohong seolah semuanya terjadi dalam satu garis lurus.

Contoh 1: merge normal saat main sudah maju.

git switch main
git merge fitur

Merge made by the 'ort' strategy.
 index.html | 4 ++++
 1 file changed, 4 insertions(+)

Frasa Merge made by (bukan Fast-forward) adalah tandanya: Git membuat merge commit baru. KAPAN ini terjadi? Setiap kali dua sisi punya commit masing-masing sejak bercabang, dan tidak ada konflik baris yang sama.

Memaksa merge commit dengan --no-ff

Bahkan saat fast-forward memungkinkan (main diam saja), kamu bisa MEMAKSA merge commit:

git merge --no-ff fitur-login

Contoh 2: lihat bedanya di log enam bulan kemudian. Tanpa --no-ff:

d4e5f6a Tambah show/hide password
c3d2e1f Validasi email di form login
b2a1c9d Buat halaman login

Dengan --no-ff:

m1a2b3c Merge branch 'fitur-login'
d4e5f6a Tambah show/hide password
c3d2e1f Validasi email di form login
b2a1c9d Buat halaman login

KENAPA repot-repot? Karena baris merge menjadi penanda satu fitur utuh. Satu baris merge = satu fitur = satu unit yang bisa di-review, di-revert, atau di-cherry-pick. Tanpa penanda itu, commit-commit fitur tenggelam dalam lautan commit dan tidak ada yang tahu di mana satu fitur berakhir dan fitur lain dimulai.

Kapan pakai --no-ff, kapan tidak?

• Tim menengah-besar: hampir wajib. Reviewer butuh batas fitur yang jelas, dan revert satu fitur jauh lebih gampang kalau ada merge commit-nya.
• Proyek solo kecil: opsional. Fast-forward biasa sudah cukup rapi, merge commit tiap fitur kecil malah bikin log berisik.
• Aturan main tim: ikuti kesepakatan. Konsistensi lebih penting daripada pilihan mana yang "benar".

KAPAN perintah ini dipakai dalam praktik? Saat kamu jadi orang yang merge PR ke main di repo tim, atau saat timmu menyepakati "setiap fitur harus punya merge commit".

Kesalahan umum pemula: salah vs benar

SALAH: panik melihat merge commit dan mengira merge-nya gagal.

git log --oneline -3
# m1a2b3c Merge branch 'fitur'   <- "ini error ya?"

Bukan error. Itu Git bekerja dengan benar mendokumentasikan penggabungan dua jalur.

BENAR: pahami dulu kenapanya dengan melihat grafik.

git log --oneline --graph -5

Kalau grafiknya bercabang lalu menyatu di merge commit, semuanya normal.

SALAH: membatalkan merge yang konflik dengan git reset --hard lalu kehilangan jejak kondisi sebelum merge.

BENAR: untuk merge yang BELUM selesai dan terlalu berantakan, pakai perintah khusus yang aman:

git merge --abort

Perintah ini mengembalikan semuanya ke kondisi persis sebelum merge dimulai. KAPAN dipakai? Saat konflik terlalu banyak dan kamu ingin mulai lagi dengan strategi berbeda (misal rebase dulu). Untuk merge yang SUDAH selesai di-commit, pembatalannya beda: git reset --hard ORIG_HEAD, tapi itu berbahaya karena membuang commit, dibahas di modul reset.

Catatan teknis: pesan default merge commit adalah Merge branch 'nama-branch'. Boleh diganti dengan -m, mis. git merge --no-ff -m "Fitur: login dengan Google" fitur-google. Banyak tim mewajibkan format pesan merge yang konsisten supaya log enak dibaca.