Rebase: apa itu, perbedaannya dengan Merge dan prinsip kerja

Apa itu Rebase?

Rebase (pengubahan basis) — adalah operasi Git yang memindahkan commit dari cabang saat ini ke titik referensi baru (basis). Alih-alih membuat commit penggabungan, rebase mengambil setiap commit dari cabang sumber dan menerapkannya secara berurutan di atas basis baru. Hasilnya adalah urutan commit linier tanpa percabangan.

Nama rebase berasal dari „re-base" — mengubah basis. Jika merge menggabungkan dua cabang di satu titik, rebase sebenarnya memindahkan seluruh cabang Anda ke lokasi baru, menciptakan ilusi bahwa Anda memulai pengembangan dari status terkini cabang target. Ini menciptakan kesan kerja yang sangat sekuensial.

Menurut Atlassian, 2025, tim yang menggunakan rebase untuk cabang feature menghabiskan waktu 30% lebih sedikit untuk menganalisis riwayat commit dibandingkan tim yang hanya menggunakan merge. Riwayat linier menyederhanakan git blame, bisect, dan melihat log melalui git log --oneline.

Perbedaan mendasar dari Merge

Merge menggabungkan cabang dengan membuat commit yang memiliki dua induk. Rebase menulis ulang riwayat: commit baru dibuat kembali dengan hash baru, meskipun perubahannya identik dengan yang asli. Ini berarti rebase mengubah identifikasi SHA commit, yang sangat penting untuk cabang publik.

Bagaimana Rebase bekerja

Mekanisme rebase terdiri dari empat langkah: Git menentukan leluhur bersama (merge base) dari cabang saat ini dan target, kemudian secara berurutan menerapkan setiap commit dari cabang saat ini ke atas cabang target. Jika pada suatu langkah terjadi konflik — rebase berhenti dan menunggu penyelesaian.

# Situasi awal: feature tertinggal 3 commit dari develop
git checkout feature/new-login
git rebase develop

# Git mengambil 3 commit dari feature dan menerapkannya di atas develop
# Jika tidak ada konflik — rebase selesai secara otomatis
# Jika ada — Git berhenti pada commit yang konflik

Setelah rebase, cabang feature berisi semua commit dari develop ditambah commit-nya sendiri, yang terlihat seperti kelanjutan dari develop. Ini memungkinkan penggabungan ke develop melalui fast-forward, tanpa membuat commit penggabungan.

Proses langkah demi langkah

Mari kita lihat contoh detail: seorang pengembang membuat cabang feature dari develop, melakukan dua commit, dan sementara itu pengembang lain menambahkan tiga commit ke develop. Rebase akan memindahkan dua commit feature ke lokasi baru, membuat salinannya dengan SHA baru.

# 1. Membuat cabang feature
git checkout -b feature/payment-refactor develop

# 2. Melakukan commit di feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Memperbarui develop (pekerjaan rekan kerja)
git checkout develop
git pull

# 4. Rebase feature di atas develop baru
git checkout feature/payment-refactor
git rebase develop

# 5. Sekarang feature dapat digabung melalui fast-forward
git checkout develop
git merge feature/payment-refactor

Jika pada langkah 4 terjadi konflik, Git berhenti pada commit yang bermasalah. Pengembang menyelesaikan konflik, melakukan git add dan menjalankan git rebase --continue. Jika perlu melewati commit — git rebase --skip, jika membatalkan seluruh rebase — git rebase --abort.

Melewatkan commit kosong secara otomatis

Flag --empty mengontrol perilaku rebase pada commit kosong — situasi di mana semua perubahan commit sudah ada di cabang target. Secara default, rebase berhenti dan meminta keputusan. Dengan flag --empty=drop, Git secara otomatis melewatkan commit tersebut tanpa berhenti, yang mempercepat pengubahan basis massal dengan jumlah commit yang banyak.

Rebase Interaktif

Interactive rebase (git rebase -i) — alat yang kuat untuk mengedit riwayat commit. Ini membuka editor dengan daftar commit dan perintah kunci: pick (pertahankan), reword (ubah pesan), edit (ubah konten), squash (gabung dengan sebelumnya), fixup (gabung tanpa pesan), drop (hapus).

# Rebase interaktif dari 4 commit terakhir
git rebase -i HEAD~4

# Di editor akan terbuka rencana rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Kita ubah menjadi:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Hasil: tiga commit (layar login, validasi, tata letak) diringkas menjadi satu, dan commit dengan komentar dihapus. Ini memungkinkan penyajian riwayat bersih tanpa draf dan koreksi untuk tinjauan kode. Interactive rebase adalah alat standar untuk menyiapkan cabang feature sebelum Pull Request.

Rebase vs Merge: perbandingan

Rebase dan Merge menyelesaikan tugas yang sama — integrasi perubahan — tetapi dengan cara yang fundamental berbeda. Pilihan di antara keduanya tergantung pada riwayat seperti apa yang ingin Anda lihat di git log dan siapa lagi yang bekerja dengan cabang Anda.

Aturan praktis: gunakan merge untuk integrasi ke cabang bersama (develop, main) dan rebase untuk memperbarui cabang feature pribadi ke status terkini. Banyak tim menggabungkan: rebase feature ke develop, lalu --no-ff merge ke develop.

Pengaruh pada git bisect

Git bisect — alat untuk menemukan commit yang memperkenalkan regresi. Saat menggunakan merge, git bisect melewati commit penggabungan dengan benar, memperhitungkan kedua induk. Pada rebase, bisect bekerja lebih cepat karena riwayat linier dan tidak memerlukan percabangan. Namun, jika rebase dilakukan setelah commit diketahui oleh tim, SHA asli hilang dan bisect mungkin tidak dapat menemukan commit yang bermasalah.

Kapan menggunakan Rebase

Rebase optimal dalam tiga skenario: menyiapkan cabang feature untuk Pull Request, memperbarui cabang pribadi ke status terkini main/develop, dan membersihkan riwayat sebelum penggabungan. Dalam setiap kasus, rebase meningkatkan keterbacaan riwayat tanpa risiko untuk kerja tim.

Sebelum Pull Request disarankan untuk melakukan interactive rebase guna menggabungkan commit kerja (WIP, koreksi setelah review) menjadi unit logis yang bermakna. Ini memudahkan tinjauan kode: pengulas melihat bukan 15 commit kecil, melainkan 3-5 perubahan terstruktur dengan pesan yang jelas.

Untuk memperbarui cabang feature, rebase lebih diutamakan daripada merge karena tidak membuat commit penggabungan yang tidak perlu. Jika Anda secara berkala melakukan git rebase develop di dalam cabang feature, setelah penggabungan akhir tidak akan ada kaskade 10 commit penggabungan — hanya commit fitur bersih di atas develop.

Membersihkan riwayat melalui interactive rebase sebelum penggabungan memungkinkan menyembunyikan koreksi kecil (kesalahan ketik, pemformatan) dan mengelompokkan commit berdasarkan fungsionalitas. Pesan Git harus mengikuti konvensi Conventional Commits (fix:, feat:, refactor:, docs:), yang menghasilkan changelog otomatis.

Risiko dan aturan Rebase

Rebase — operasi berbahaya jika diterapkan secara tidak benar. Risiko utama — menulis ulang riwayat yang telah dipublikasikan. Jika seorang pengembang melakukan rebase pada cabang yang sudah di-push dan digunakan oleh orang lain, salinan lokal mereka akan tidak sinkron dan mereka harus melakukan force-pull dengan risiko kehilangan data.

• Aturan emas: jangan pernah melakukan rebase pada commit yang sudah ada di repositori bersama. Ini berlaku untuk semua cabang yang dapat diakses oleh anggota tim lainnya
• Force push: setelah rebase cabang feature lokal, diperlukan push dengan flag --force-with-lease, yang lebih aman daripada --force karena memeriksa apakah seseorang telah memperbarui cabang di server
• Kehilangan konteks: rebase menghancurkan informasi tentang kapan dan dari cabang mana cabang feature dibuat. Jika penting untuk menyimpan tanggal pembuatan cabang — gunakan merge
• Konflik: pada rebase, konflik harus diselesaikan untuk setiap commit secara terpisah, yang bisa melelahkan dengan jumlah commit yang banyak

Untuk meminimalkan risiko, patuhi aturan: rebase hanya untuk cabang pribadi yang belum dipublikasikan. Jika cabang sudah ada di repositori bersama — gunakan merge dengan --no-ff. Jika perlu melakukan rebase pada cabang yang dipublikasikan — peringatkan tim dan koordinasikan force push terlebih dahulu.

Perlindungan otomatis terhadap rebase berbahaya diimplementasikan melalui server-side hooks: pre-receive hook di sisi server Git dapat memeriksa apakah push menulis ulang commit yang dipublikasikan. GitHub dan GitLab menyediakan perlindungan bawaan untuk cabang yang dilindungi — force push diblokir kecuali perlindungan dihapus oleh administrator.