Git Merge vs Rebase: Perbedaan dan Kapan Menggunakannya

Setiap developer yang bekerja dalam tim pasti pernah menghadapi pertanyaan ini: gabungkan branch dengan merge atau dengan rebase? Pembahasan git merge vs rebase sering memicu perdebatan, padahal keduanya sama-sama sah dan punya tempat masing-masing. Perbedaannya terletak pada bagaimana riwayat commit dibentuk, dan itu berdampak langsung pada keterbacaan history, cara menangani konflik, hingga kemudahan melacak bug.

Artikel ini membahas cara kerja keduanya, contoh perintah, perbandingan, aturan penting yang tidak boleh dilanggar, serta skenario kapan sebaiknya memilih salah satunya.

Memahami Masalah yang Diselesaikan Merge dan Rebase

Bayangkan Anda membuat branch feature/login dari main. Selama Anda mengerjakan fitur, rekan tim ikut menambahkan commit baru ke main. Kini kedua branch berpisah jalur, dan perubahan di feature/login harus digabungkan kembali.

Sebelum digabungkan:

      A---B---C        feature/login
     /
D---E---F---G          main

Merge dan rebase adalah dua cara berbeda untuk menyatukan kedua jalur ini. Hasil akhirnya, yaitu isi kode, bisa sama. Yang berbeda adalah bentuk riwayat yang tertinggal.

Cara Kerja Git Merge

Git merge menggabungkan dua branch dengan membuat satu commit baru, disebut merge commit, yang memiliki dua induk. Riwayat kedua branch dipertahankan apa adanya, sehingga jejak percabangan tetap terlihat.

git checkout main
git merge feature/login

Setelah merge:

      A---B---C
     /         \
D---E---F---G---M      main

Commit M adalah merge commit. Commit A, B, dan C tetap utuh dengan hash aslinya.

Fast-forward dan three-way merge

Git memilih salah satu dari dua mode secara otomatis:

Fast-forward: terjadi jika main tidak mendapat commit baru sejak branch dibuat. Git cukup memajukan pointer main ke ujung branch fitur, tanpa merge commit.
Three-way merge: terjadi jika kedua branch sudah berpisah jalur. Git membandingkan tiga titik, yaitu ujung kedua branch dan nenek moyang bersama mereka, lalu membuat merge commit.

Jika ingin selalu membuat merge commit sebagai penanda fitur, gunakan opsi --no-ff:

git merge --no-ff feature/login

Kelebihan dan kekurangan merge

Aman: tidak mengubah commit yang sudah ada, sehingga cocok untuk branch yang dipakai bersama.
Jejak jelas: riwayat menunjukkan kapan sebuah fitur digabungkan.
Mudah dibatalkan: seluruh fitur bisa dibatalkan dengan membatalkan satu merge commit.
Riwayat bisa ramai: repositori aktif dengan banyak merge commit membuat grafik history sulit dibaca.

Cara Kerja Git Rebase

Git rebase memindahkan commit dari satu branch agar seolah-olah dibuat dari ujung branch lain. Secara teknis, Git mengambil commit Anda, menyimpannya sementara, lalu memutar ulang satu per satu di atas titik baru. Hasilnya adalah riwayat lurus tanpa percabangan.

git checkout feature/login
git rebase main

Setelah rebase:

D---E---F---G                main
                \
                 A'--B'--C'  feature/login

Perhatikan tanda petik pada A’, B’, dan C’. Commit tersebut adalah commit baru dengan hash berbeda, walaupun isi perubahannya sama. Karena itulah rebase disebut “menulis ulang riwayat”. Setelah itu, penggabungan ke main bisa dilakukan secara fast-forward:

git checkout main
git merge feature/login

Interactive rebase

Selain memindahkan commit, rebase interaktif membantu merapikan riwayat sebelum dibagikan:

git rebase -i HEAD~3

Perintah ini membuka editor berisi tiga commit terakhir. Beberapa tindakan yang umum dipakai:

pick: pertahankan commit apa adanya.
reword: ubah pesan commit.
squash: gabungkan ke commit sebelumnya dan gabungkan pesannya.
fixup: gabungkan ke commit sebelumnya dan buang pesannya.
drop: hapus commit.

Kelebihan dan kekurangan rebase

Riwayat bersih dan lurus: mudah dibaca dengan git log --oneline.
Tanpa merge commit tambahan: history tidak dipenuhi commit penggabungan.
Fleksibel: commit bisa dirapikan, digabung, atau diganti pesannya.
Berisiko jika disalahgunakan: menulis ulang commit yang sudah dibagikan dapat merusak pekerjaan rekan tim.
Konteks hilang: kapan sebuah branch dibuat dan digabung tidak lagi terlihat.

Git Merge vs Rebase: Tabel Perbandingan

Aspek	Git merge	Git rebase
Bentuk riwayat	Bercabang, ada merge commit	Lurus, tanpa percabangan
Commit yang sudah ada	Tidak diubah	Ditulis ulang dengan hash baru
Keamanan di branch bersama	Aman	Berisiko jika branch sudah dipublikasikan
Penanganan konflik	Diselesaikan sekali pada merge commit	Bisa muncul berulang di tiap commit
Keterbacaan history	Lengkap tetapi bisa ramai	Bersih dan mudah dibaca
Membatalkan fitur	Mudah lewat satu merge commit	Perlu membatalkan beberapa commit
Jejak kapan digabung	Terlihat	Tidak terlihat

Aturan Emas: Jangan Rebase Branch yang Sudah Dibagikan

Karena rebase membuat commit baru, riwayat lama dan baru menjadi dua versi berbeda. Jika rekan Anda sudah mengambil commit lama dari repositori bersama, lalu Anda memaksa mendorong versi yang di-rebase, riwayat mereka akan tidak sinkron dengan remote. Hasilnya bisa berupa konflik berulang, commit ganda, atau pekerjaan yang hilang.

Pegangan praktisnya: rebase hanya untuk branch lokal atau branch pribadi yang belum dipakai orang lain. Branch utama seperti main atau develop jangan pernah di-rebase.

Jika setelah rebase Anda perlu memperbarui branch pribadi di remote, gunakan opsi yang lebih aman daripada --force biasa:

git push --force-with-lease

Opsi ini menolak dorongan jika ada commit baru di remote yang belum Anda lihat, sehingga mengurangi risiko menimpa pekerjaan orang lain. Dokumentasinya bisa dibaca di dokumentasi resmi git push.

Kapan Memakai Merge dan Kapan Memakai Rebase

Jawaban atas pertanyaan git merge vs rebase tergantung pada konteks, bukan pada mana yang “lebih benar”. Berikut panduan skenarionya.

Gunakan merge ketika

Menggabungkan fitur selesai ke branch utama yang dipakai bersama tim.
Anda ingin mempertahankan jejak lengkap kapan dan bagaimana sebuah fitur digabungkan.
Branch sudah dipublikasikan dan dipakai banyak orang.
Tim memprioritaskan keamanan dan kesederhanaan dibanding riwayat yang rapi.

Gunakan rebase ketika

Memperbarui branch fitur lokal dengan perubahan terbaru dari main.
Merapikan commit sendiri sebelum dibuka sebagai pull request.
Tim menginginkan riwayat lurus tanpa merge commit tambahan.
Branch masih pribadi dan belum dipakai orang lain.

Pertimbangkan squash merge

Ada pilihan ketiga yang sering dipakai pada pull request, yaitu menggabungkan semua commit sebuah fitur menjadi satu commit:

git merge --squash feature/login
git commit -m "Tambah fitur login"

Hasilnya riwayat main tetap lurus dan ringkas, dengan satu commit per fitur. Kekurangannya, detail commit kecil di dalam fitur tidak ikut tersimpan di main.

Contoh Alur Kerja Tim yang Seimbang

Banyak tim memadukan keduanya: rebase untuk merapikan pekerjaan pribadi, merge untuk menggabungkan ke branch bersama. Alurnya kira-kira seperti ini:

Buat branch fitur dari main dan kerjakan seperti biasa.
Selama bekerja, ambil perubahan terbaru dengan git pull --rebase agar tidak menumpuk merge commit kecil.
Sebelum membuka pull request, rapikan commit dengan git rebase -i.
Dorong branch ke remote, lalu minta peninjauan.
Setelah disetujui, gabungkan ke main dengan merge biasa, --no-ff, atau squash sesuai kesepakatan tim.

Agar git pull otomatis memakai rebase, Anda bisa mengatur:

git config --global pull.rebase true

Apa pun alurnya, kesepakatan tim jauh lebih penting daripada pilihan itu sendiri. Tulis aturannya dalam panduan kontribusi repositori agar semua orang konsisten.

Menangani Konflik pada Merge dan Rebase

Konflik muncul ketika dua perubahan menyentuh baris yang sama. Cara menanganinya mirip, tetapi alurnya berbeda.

Pada merge

Konflik diselesaikan sekali untuk seluruh penggabungan. Setelah mengedit file yang bertanda konflik, jalankan:

git add nama-file
git commit

Jika ingin membatalkan seluruh proses, gunakan git merge --abort.

Pada rebase

Karena commit diputar ulang satu per satu, konflik bisa muncul berkali-kali, sekali untuk tiap commit yang bersinggungan. Setelah menyelesaikan satu konflik:

git add nama-file
git rebase --continue

Pilihan lain yang tersedia adalah git rebase --skip untuk melewati commit bermasalah, dan git rebase --abort untuk membatalkan dan kembali ke kondisi semula. Dokumentasi lengkapnya ada di dokumentasi resmi git rebase.

Memulihkan Diri dari Kesalahan

Salah rebase terasa menakutkan, tetapi hampir selalu bisa dipulihkan karena Git menyimpan catatan pergerakan pointer.

Lihat riwayat pergerakan: git reflog menampilkan posisi HEAD sebelumnya, termasuk sebelum rebase dimulai.
Kembali ke kondisi sebelum rebase atau merge: git reset --hard ORIG_HEAD bisa dipakai tepat setelah operasi selesai, selama belum ada operasi lain yang menimpanya.
Batalkan fitur yang sudah di-merge: git revert -m 1 hash-merge-commit membuat commit baru yang membalikkan perubahan merge tersebut.

Selalu pastikan tidak ada perubahan yang belum disimpan sebelum memakai reset --hard, karena perintah ini membuang perubahan lokal. Untuk memahami konsepnya lebih dalam, bab Rebasing di buku Pro Git layak dibaca.

Kesalahan Umum dalam Memilih Antara Merge dan Rebase

Rebase branch yang sudah dibagikan. Ini sumber masalah paling umum dan paling merugikan.
Memakai force push biasa. Pilih --force-with-lease agar tidak menimpa pekerjaan orang lain.
Merge main ke branch fitur berulang kali. Riwayat fitur jadi dipenuhi merge commit yang tidak bermakna. Rebase lebih tepat untuk memperbarui branch pribadi.
Tidak menyepakati aturan tim. Campuran gaya tanpa aturan membuat riwayat tidak konsisten.
Takut berlebihan terhadap rebase. Selama dipakai di branch pribadi, rebase aman dan sangat membantu.

Jika Anda baru mulai membangun kebiasaan belajar yang konsisten, lihat juga tulisan lain di NgodingDaily untuk topik ngoding harian lainnya.

Pertanyaan yang Sering Diajukan

Mana yang lebih baik, git merge atau rebase?

Tidak ada yang mutlak lebih baik. Merge lebih aman untuk branch bersama, sedangkan rebase menghasilkan riwayat yang lebih rapi untuk branch pribadi. Banyak tim memadukan keduanya.

Apakah rebase menghapus commit?

Rebase tidak menghapus commit, tetapi membuat salinan baru dengan hash berbeda. Commit lama tetap ada sementara waktu dan masih bisa ditemukan lewat git reflog.

Apakah merge commit buruk?

Tidak. Merge commit menyimpan konteks bahwa sebuah fitur digabungkan pada waktu tertentu. Yang perlu dihindari hanyalah merge commit yang tidak bermakna, misalnya dari menarik perubahan berulang kali.

Apa bedanya pull dan pull –rebase?

git pull secara bawaan melakukan fetch lalu merge, sehingga bisa menghasilkan merge commit. git pull --rebase melakukan fetch lalu memutar ulang commit lokal Anda di atas perubahan remote, sehingga riwayat tetap lurus.

Apakah rebase aman untuk pemula?

Aman selama dipakai pada branch pribadi dan Anda memahami cara membatalkannya. Mulailah dengan berlatih di repositori percobaan sebelum memakainya di proyek tim.

Kapan sebaiknya memakai squash?

Saat sebuah fitur terdiri dari banyak commit kecil yang tidak perlu dipertahankan satu per satu, misalnya commit “perbaikan typo” atau “coba lagi”. Squash menjaga riwayat utama tetap ringkas.

Kesimpulan

Pembahasan git merge vs rebase pada dasarnya soal memilih antara riwayat yang jujur dan lengkap atau riwayat yang rapi dan lurus. Merge mempertahankan semua jejak dan aman untuk branch bersama. Rebase merapikan riwayat, tetapi hanya boleh dipakai pada commit yang belum dibagikan. Pegang satu aturan: rebase untuk pekerjaan pribadi, merge untuk menggabungkan ke branch bersama, dan sepakati alurnya bersama tim. Dengan begitu riwayat repositori Anda tetap mudah dibaca dan aman dari kejutan.