Rebase: apa itu, bagaimana cara kerja rebase dan bekerja dengan Git

Apa itu rebase di Git

Rebase — adalah perintah Git yang memindahkan basis cabang saat ini ke cabang yang ditentukan: mengambil semua commit cabang saat ini, menyimpannya sementara, memindahkan pointer cabang ke commit target, dan menerapkan commit yang disimpan secara berurutan di atasnya. Hasilnya — riwayat terlihat seolah-olah pengembang bekerja langsung dari commit terakhir cabang target.

Sintaks dasar: git rebase main — saat berada di cabang feature, perintah ini memindahkan semua commit feature ke puncak main. Git menggunakan strategi three-way merge untuk setiap commit secara terpisah. Jika commit A sudah ada di cabang target (ditentukan oleh hash), Git secara otomatis melewatkannya, yang menghindari duplikasi perubahan.

Rebase juga mendukung mode onto untuk memindahkan sebagian commit: git rebase --onto target start end — bentuk ini memungkinkan mengekstrak rentang commit dari satu cabang dan menerapkannya di atas cabang lain. Misalnya, git rebase --onto main feature~3 feature akan memindahkan tiga commit terakhir cabang feature ke puncak main.

# Beralih ke cabang feature
git checkout feature

# Rebase feature ke main
git rebase main

# Setelah rebase berhasil — riwayat linier
git log --oneline --graph

# Pindahkan 3 commit terakhir ke main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: perbedaan utama

Rebase dan merge menyelesaikan tugas yang sama — menggabungkan perubahan dari cabang yang berbeda — tetapi melakukannya dengan cara yang fundamentally berbeda. Merge mempertahankan riwayat penggabungan lengkap dengan membuat merge-commit dengan dua induk. Rebase menulis ulang riwayat, menjadikannya linier. Pilihan di antara keduanya tergantung pada alur kerja tim dan aturan bekerja dengan repositori.

Perbedaan utama — bagaimana fakta penggabungan dicatat. Merge menyimpan: “pada titik ini kami menggabungkan feature ke main” — ini informatif untuk riwayat proyek, tetapi mengotori log saat penggabungan sering. Rebase menunjukkan: “commit feature dibuat secara berurutan dari keadaan terakhir main” — ini bersih, tetapi menyembunyikan fakta bahwa pekerjaan dilakukan secara paralel.

Perbedaan kedua — penanganan konflik. Saat merge, konflik diselesaikan sekali dan solusinya dicatat dalam merge-commit. Saat rebase, konflik dapat muncul untuk setiap commit yang dipindahkan dan masing-masing memerlukan penyelesaian terpisah. Ini lebih memakan waktu, tetapi memungkinkan kontrol yang lebih tepat atas perubahan mana yang masuk ke versi akhir.

Rebase interaktif: perintah dan flag

Rebase interaktif (git rebase -i) — adalah mode di mana Git membuka editor dengan daftar commit dan tindakan yang tersedia untuk masing-masing. Pengembang dapat menulis ulang riwayat sebelum mengirim ke repositori jarak jauh. Ini adalah alat utama untuk menjaga kebersihan commit di cabang feature.

Perintah yang tersedia dalam mode interaktif: pick (biarkan commit apa adanya), reword (ubah pesan commit), edit (berhenti untuk perubahan), squash (gabung dengan commit sebelumnya, pertahankan kedua pesan), fixup (gabung dengan membuang pesan), drop (hapus commit). Setiap perintah ditunjukkan sebelum hash commit di editor yang terbuka.

Squash dan fixup — perintah yang paling sering digunakan untuk menggabungkan commit. Jika pengembang membuat 5 commit kecil dengan koreksi selama bekerja, squash akan menggabungkannya menjadi satu commit logis dengan pesan yang bermakna. Fixup berguna untuk memperbaiki kesalahan ketik: perubahan masuk ke commit sebelumnya tanpa menyimpan pesannya sendiri.

# Buka editor untuk 4 commit terakhir
git rebase -i HEAD~4

# Editor akan menampilkan:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Setelah disimpan — Git melakukan rebase
# dan membuka editor untuk pesan commit gabungan

# Auto-squash tanpa membuka editor
git rebase -i HEAD~4 --autosquash

Flag --autosquash secara otomatis mengatur fixup/squash untuk commit yang pesannya dimulai dengan fixup! atau squash!. Ini mempercepat pekerjaan jika pengembang menandai commit terlebih dahulu untuk penggabungan selanjutnya. Flag --committer-date-is-author-date mempertahankan tanggal asli commit saat rebase — berguna untuk menjaga kronologi dalam riwayat.

Penyelesaian konflik saat rebase

Konflik saat rebase muncul ketika Git tidak dapat secara otomatis menerapkan commit yang dipindahkan karena pertentangan dengan perubahan di cabang target. Berbeda dengan merge di mana konflik diselesaikan sekali, saat rebase setiap commit dapat menyebabkan konflik dan harus diselesaikan secara berurutan untuk setiap commit dari yang tertua ke yang terbaru.

Ketika konflik terjadi, Git menjeda rebase dan melaporkan commit mana yang menyebabkan masalah. Pengembang membuka file yang berkonflik (Git menandai area konflik dengan penanda <<<<<<<, =======, >>>>>>>), mengeditnya, menambahkannya ke indeks (git add), dan melanjutkan rebase dengan perintah git rebase --continue. Jika solusi tidak ditemukan — git rebase --abort membatalkan rebase sepenuhnya.

Tips: pada konflik berganda, lebih efisien menggunakan git mergetool yang membuka editor visual untuk menyelesaikan pertentangan. Anda juga dapat melewati commit yang bermasalah (git rebase --skip), tetapi ini akan menghapus perubahannya dari riwayat akhir, yang jarang menjadi solusi yang tepat.

# Mulai rebase dengan konflik
git rebase main
# Auto-merging file.txt
# KONFLIK (konten): Konflik penggabungan di file.txt

# Periksa status
git status
# keduanya dimodifikasi: file.txt

# Edit bagian yang konflik → git add → lanjutkan
git add file.txt
git rebase --continue

# Jika ragu — batalkan
git rebase --abort

Kapan tidak boleh melakukan rebase

Aturan emas rebase: jangan pernah memindahkan basis commit yang sudah dikirim ke repositori jarak jauh dan tersedia untuk pengembang lain. Karena rebase menulis ulang hash commit, rekan kerja akan mengalami konflik saat mencoba sinkronisasi — riwayat lokal mereka akan bertentangan dengan riwayat jarak jauh yang ditulis ulang.

Situasi di mana rebase secara kategoris dilarang: jika seseorang sudah membuat cabang berdasarkan commit Anda (misalnya, rekan Anda membuat feature dari feature Anda), mengubah riwayat akan merusak pekerjaannya. Dalam kasus seperti itu, harus menggunakan merge. Juga tidak disarankan melakukan rebase tepat sebelum tenggat waktu — kesalahan saat menyelesaikan konflik dapat memakan waktu lebih lama dari yang diharapkan dan memblokir rilis.

Pengecualian: jika cabang hanya digunakan oleh satu pengembang (cabang feature pribadi, tidak dipublikasikan atau dipublikasikan dalam mode draft), rebase sebelum push adalah praktik standar. Setelah publikasi dan dimulainya kerja tim — hanya merge. GitHub dan GitLab secara default menawarkan squash merge sebagai kompromi: menggabungkan commit menjadi satu, tetapi tidak menulis ulang riwayat cabang target.

• Cabang publik (main, develop, release) — rebase sepenuhnya dilarang.
• Commit orang lain — jika cabang berisi commit pengembang lain, rebase tidak diperbolehkan.
• Sebelum rilis — risiko konflik lebih tinggi: merge lebih aman sehari sebelum tenggat waktu.
• Cabang dengan tag — memindahkan commit dengan tag melanggar konvensi versioning semantik.
• CI/CD terikat pada hash — beberapa sistem deployment mengidentifikasi build berdasarkan hash commit; rebase akan merusak pelacakan.

Alur kerja praktis dengan rebase

Dalam tim modern, paling sering digunakan alur kerja berorientasi rebase dalam kombinasi dengan GitHub Flow. Prosesnya terlihat seperti ini: pengembang membuat cabang feature dari main, bekerja di dalamnya, secara periodik sinkronisasi melalui git rebase main, dan sebelum membuat pull request melakukan rebase interaktif untuk membersihkan riwayat.

Setelah membuat PR (jika perlu menarik perubahan baru dari main) digunakan git pull --rebase main sebagai pengganti git pull biasa. Ini memungkinkan menarik perubahan tanpa membuat merge-commit yang tidak perlu. Git pull dengan flag --rebase setara dengan git fetch + git rebase — Git pertama memuat commit baru, kemudian memindahkan basis perubahan lokal di atasnya.

Git memungkinkan mengatur rebase sebagai perilaku default untuk pull: git config --global pull.rebase true. Setelah konfigurasi ini, git pull selalu melakukan rebase alih-alih merge. Jika pull biasa diperlukan — digunakan git pull --no-rebase. Banyak tim juga mengaktifkan autostash: git config --global rebase.autoStash true — ini secara otomatis menyembunyikan perubahan yang belum di-commit sebelum rebase dan mengembalikannya setelahnya.