Foto oleh Zulfugar Karimov via Pexels

Merge dan rebase adalah dua cara berbeda untuk menggabungkan perubahan dari satu branch ke branch lain di Git, keduanya mencapai tujuan akhir yang serupa namun dengan dampak yang sangat berbeda terhadap riwayat commit yang dihasilkan.

Merge menggabungkan dua branch dengan membuat commit baru khusus (merge commit) yang memiliki dua parent, mempertahankan riwayat persis seperti yang terjadi, sementara rebase memindahkan seluruh commit dari satu branch untuk ditempatkan ulang di atas commit terbaru branch lain, menghasilkan riwayat yang terlihat linear seolah-olah tidak pernah ada percabangan.

Artikel ini membahas perbedaan mendasar keduanya, dampaknya terhadap riwayat commit, serta kapan masing-masing pendekatan lebih tepat dipakai, termasuk aturan emas tentang kapan rebase sebaiknya dihindari.

Merge Mempertahankan Riwayat Apa Adanya

Merge commit menggabungkan dua riwayat tanpa mengubah commit asli

git checkout main git merge feature/login # Riwayat SETELAH merge: # ●---------● <- merge commit (2 parent) # \ / # ●--●--● <- commit dari feature/login
Merge membuat satu commit baru (merge commit) yang menggabungkan dua riwayat berbeda tanpa mengubah commit yang sudah ada sama sekali, menghasilkan riwayat yang menunjukkan persis kapan dan bagaimana percabangan terjadi, meski ini membuat riwayat terlihat sedikit lebih kompleks dengan percabangan visual yang jelas terlihat pada graph commit.

Rebase Menghasilkan Riwayat yang Linear

Rebase menulis ulang commit dengan hash baru di lokasi berbeda

git checkout feature/login git rebase main # Riwayat SETELAH rebase: # ●--●--●--●--● <- LINEAR, seolah tidak pernah ada percabangan # (commit feature/login ditempatkan ulang setelah commit terbaru main)
Rebase mengambil setiap commit dari feature/login dan menerapkannya ulang satu per satu di atas commit terbaru main, menghasilkan riwayat yang linear dan terlihat rapi, namun penting disadari bahwa commit yang dihasilkan rebase sebenarnya adalah commit BARU dengan hash berbeda, meski isi perubahannya sama.

Golden Rule: Jangan Rebase Branch yang Sudah Dibagikan

Rebase mengubah hash commit, berbahaya untuk branch yang dibagikan

# BERBAHAYA: rebase branch yang SUDAH di-push dan dipakai orang lain git checkout main git rebase feature/login # JANGAN jika main sudah dipakai tim lain # AMAN: rebase branch LOKAL yang BELUM di-push atau hanya milik sendiri git checkout feature/login-saya-sendiri git rebase main
Karena rebase mengubah hash setiap commit yang di-rebase, melakukan rebase pada branch yang sudah di-push dan sedang dipakai developer lain akan menyebabkan riwayat mereka dan riwayat yang sudah di-rebase menjadi tidak sinkron, berpotensi menimbulkan konflik rumit; aturan emasnya adalah hanya rebase branch yang masih sepenuhnya lokal atau memang hanya dipakai sendiri.

Interactive Rebase untuk Merapikan Riwayat Lokal

Interactive rebase memungkinkan penyuntingan riwayat commit lokal

git rebase -i HEAD~3 # Membuka editor dengan opsi untuk setiap commit: # pick, squash (gabung dengan commit sebelumnya), # reword (ubah pesan), drop (hapus commit)
Interactive rebase memungkinkan developer merapikan riwayat commit lokal sebelum di-push, misalnya menggabungkan beberapa commit kecil 'wip' menjadi satu commit yang bersih dengan pesan yang lebih bermakna, sangat berguna untuk menjaga riwayat commit tetap rapi sebelum dibagikan ke tim lain.

Interactive Rebase untuk Merapikan Riwayat Commit Sebelum Push

Menggabungkan tiga commit kecil menjadi satu commit yang rapi dengan interactive rebase

$ git log --oneline e4f1a2c fix typo d3c9b81 perbaiki lagi validasi a1b2c3d tambah validasi harga $ git rebase -i HEAD~3 pick a1b2c3d tambah validasi harga squash d3c9b81 perbaiki lagi validasi squash e4f1a2c fix typo # ketiga commit digabung jadi satu commit bersih sebelum di-push

Interactive rebase, dijalankan lewat git rebase -i, memberi kontrol penuh untuk menyusun ulang riwayat commit sebelum dibagikan ke branch bersama, termasuk menggabungkan beberapa commit kecil menjadi satu commit yang lebih bermakna. Opsi squash pada contoh di atas menggabungkan commit perbaikan typo dan validasi tambahan ke dalam commit utamanya, menghasilkan riwayat yang lebih bersih untuk dibaca tim lain.

Interactive rebase hanya aman dilakukan pada commit yang belum pernah di-push ke branch bersama, karena mengubah riwayat commit yang sudah dibagikan ke orang lain akan membuat salinan riwayat di komputer rekan tim menjadi tidak sinkron dan memicu konflik yang rumit saat mereka melakukan pull. Aturan praktisnya adalah rebase bebas dilakukan di branch pribadi, namun hindari rebase pada branch yang sudah dipakai bersama.

Fast-Forward Merge vs Merge Commit dan Dampaknya pada Grafik Riwayat

Fast-forward menggeser pointer branch, merge commit menyatukan dua riwayat

# Fast-forward: branch fitur tidak punya commit baru di main sejak dibuat $ git checkout main $ git merge fitur/validasi-harga Fast-forward # main hanya "digeser" maju, tidak ada commit merge baru dibuat # Merge commit: main sudah berubah sejak branch fitur dibuat $ git merge fitur/validasi-stok Merge made by the 'recursive' strategy. # Sebuah commit merge baru dibuat dengan DUA parent, # menandakan persis kapan dua jalur riwayat bertemu $ git merge --no-ff fitur/validasi-harga # Memaksa membuat merge commit meski sebenarnya bisa fast-forward

Fast-forward merge terjadi ketika branch main tidak memiliki commit baru sejak branch fitur dibuat, sehingga Git cukup menggeser pointer main maju mengikuti commit terakhir di branch fitur tanpa perlu membuat commit gabungan baru. Hasilnya, grafik riwayat terlihat seolah semua commit dikerjakan secara linear di satu jalur, tanpa jejak bahwa pekerjaan tersebut sebenarnya dilakukan di branch terpisah. Banyak tim menetapkan kebijakan agar branch fitur selalu di-rebase ke main terlebih dahulu sebelum merge, sehingga hasil akhirnya selalu fast-forward.

Merge commit dibuat ketika main sudah memiliki commit baru sejak branch fitur dipisahkan, sehingga Git perlu menyatukan dua jalur riwayat yang berbeda lewat sebuah commit khusus yang memiliki dua parent sekaligus. Commit merge ini menjadi penanda eksplisit kapan dan di mana dua jalur pekerjaan bertemu, yang berguna untuk audit riwayat dan untuk perintah seperti git revert yang perlu tahu batas sebuah fitur dimulai dan berakhir. Pesan commit merge biasanya otomatis dibuat Git, namun developer tetap bisa menuliskan deskripsi singkat untuk menjelaskan konteks fitur yang digabungkan.

Opsi --no-ff bisa dipakai untuk memaksa Git selalu membuat merge commit meski sebenarnya fast-forward dimungkinkan, sebuah kebijakan yang banyak diadopsi tim agar riwayat tetap menunjukkan batas setiap fitur secara jelas sebagai grup commit tersendiri. Trade-off-nya, riwayat dengan banyak merge commit menjadi lebih bercabang dan sedikit lebih rumit dibaca dibanding riwayat linear murni hasil fast-forward atau rebase. Sebagian tim lain justru lebih menyukai fast-forward murni agar riwayat tetap sederhana dan mudah dibaca secara linear dari atas ke bawah.

Git Rebase --onto untuk Memindahkan Sebagian Riwayat Branch

Memindahkan branch fitur-b agar tidak lagi bergantung pada fitur-a

# Branch fitur-b dibuat dari fitur-a, padahal fitur-a belum siap merge # Struktur: main -> fitur-a -> fitur-b $ git rebase --onto main fitur-a fitur-b # Memindahkan commit fitur-b agar langsung berbasis main, # melompati seluruh commit fitur-a yang belum siap $ git log --oneline fitur-b # Sekarang fitur-b hanya berisi commit miliknya sendiri di atas main

Git rebase --onto dipakai untuk kasus yang lebih spesifik dibanding rebase biasa, yaitu ketika sebuah branch perlu dipindahkan dasarnya dari satu titik ke titik lain sambil melompati sebagian riwayat yang tidak diinginkan. Contoh umum adalah branch fitur-b yang dibuat dari fitur-a yang ternyata masih jauh dari selesai, sehingga fitur-b perlu dilepaskan dari ketergantungan tersebut.

Perintah ini menerima tiga argumen, yaitu basis baru, basis lama, dan branch yang ingin dipindahkan, sehingga Git tahu persis commit mana saja yang perlu diterapkan ulang dan commit mana yang harus dilewati. Teknik ini lebih presisi dibanding rebase biasa untuk membersihkan riwayat yang sudah telanjur bercabang dari branch perantara yang belum siap digabung ke branch utama.

Kesalahan Umum yang Sering Terjadi

Melakukan Rebase pada Branch yang Sudah Dibagikan Tim

Rebase branch yang sudah di-push dan sedang dipakai developer lain mengubah hash seluruh commit, menyebabkan konflik rumit saat developer lain mencoba pull atau push ke branch yang sama.

Bingung Mengapa Commit 'Hilang' Setelah Rebase

Commit asli sebelum rebase sebenarnya tidak hilang sepenuhnya (masih bisa ditemukan lewat git reflog untuk sementara waktu), namun developer yang tidak memahami cara kerja rebase sering panik mengira pekerjaan mereka hilang begitu saja.

Memakai Merge atau Rebase Tanpa Memahami Perbedaan Dampaknya

Memilih antara merge dan rebase hanya berdasarkan kebiasaan tanpa memahami bahwa keduanya menghasilkan riwayat yang berbeda bisa menyebabkan kebingungan tim ketika riwayat project menjadi tidak konsisten gaya penggabungannya.

Kapan Pendekatan Ini Tidak Cocok Dipakai

Merge mempertahankan riwayat apa adanya termasuk informasi kapan percabangan terjadi, lebih aman dipakai pada branch yang sudah dibagikan karena tidak mengubah commit yang sudah ada, namun menghasilkan riwayat yang terlihat lebih kompleks dengan banyak percabangan visual.

Rebase menghasilkan riwayat yang bersih dan linear, lebih mudah dibaca saat menelusuri riwayat project, namun berisiko jika dipakai sembarangan pada branch yang sudah dibagikan, sehingga penggunaannya perlu dibatasi hanya pada branch lokal yang belum di-push ke tim lain.

Ringkasan

Merge dan rebase sama-sama menggabungkan perubahan antar branch namun dengan dampak berbeda terhadap riwayat commit: merge mempertahankan riwayat apa adanya, sementara rebase menghasilkan riwayat linear dengan commit baru. Ingat aturan emas untuk tidak melakukan rebase pada branch yang sudah dibagikan dengan tim lain, demi menghindari konflik riwayat yang rumit.

Seri Belajar Git & CI/CD:

← Sebelumnya: Branching Strategy dan Git Flow

→ Selanjutnya: Menyelesaikan Merge Conflict di Git