gitrebaseMenengah5 mnt baca

Rebase: Menata Ulang Riwayat

Memahami rebase interaktif, bedanya dengan merge, dan aturan emasnya.

Apa itu rebase?

Rebase "memindahkan" commit-commit branch-mu agar seolah-olah dikerjakan dari titik terbaru main. Hasilnya riwayat garis lurus tanpa merge commit:

bash
git switch fitur
git rebase main

Sebelum: A-B(main) bercabang dengan C-D(fitur). Sesudah: A-B-C'-D' lurus. Tanda petik itu PENTING: C' dan D' adalah commit baru (hash berbeda) dengan isi sama, dibuat ulang di atas titik baru.

KENAPA perintah ini ada? Karena ada dua selera: riwayat jujur (merge, apa adanya walau bercabang) vs riwayat bersih (linear, enak dibaca). Rebase memberi opsi kedua.

Contoh 1: sinkronisasi branch fitur dengan main terbaru sebelum PR.

bash
git switch fitur-login
git rebase main
bash
Successfully rebased and updated refs/heads/fitur-login.

KAPAN dipakai? Saat branch-mu ketinggalan dari main dan ingin mengejar tanpa merge commit. Branch-mu terlihat baru dikerjakan dari main paling anyar, PR jadi bersih dan gampang di-review.

Rebase interaktif: edit riwayat

bash
git rebase -i HEAD~3

Membuka editor berisi 3 commit terakhir dengan perintah yang bisa kamu pilih per baris:

  • pick: pakai apa adanya.
  • reword: ubah pesan commit (misal typo di pesan).
  • squash: gabung ke commit sebelumnya. Ini cara profesional merapikan 12 commit berantakan ("wip", "fix typo", "coba lagi") menjadi 3 commit yang bercerita jelas.
  • drop: buang commit sepenuhnya.

Contoh 2: merapikan sebelum Pull Request. Misal log branch-mu seperti ini:

bash
git log --oneline -4
bash
a1b2c3d fix typo
e4f5g6h wip
i7j8k9l Tambah halaman login
m0n1o2p Setup form

Setelah git rebase -i HEAD~4 dan squash dua commit kecil ke commit utamanya:

bash
x9y8z7w Tambah halaman login
m0n1o2p Setup form

KENAPA ini penting? Reviewer membuka PR berisi 2 commit yang jelas, bukan 12 commit berisi "wip" dan "eh salah". Kesan profesional itu gratis, cuma butuh 2 menit rebase.

Merge vs rebase: kapan pakai apa?

  • Merge: untuk menggabungkan branch yang sudah di-share (public). Aman, jujur, riwayat apa adanya.
  • Rebase: untuk merapikan branch pribadimu SEBELUM di-share. Riwayat bersih dan linear.

Aturan emas rebase (jangan dilanggar)

Jangan pernah rebase commit yang sudah di-push ke branch bersama. KENAPA? Karena rebase menulis ulang hash commit. Orang lain yang sudah menarik commit lama akan punya "kembaran" commit yang berbeda hash, dan sinkronisasi mereka kacau. Untuk branch pribadimu yang belum di-PR: bebas. Untuk main tim: haram.

bash
git rebase --abort     # batalkan saat konflik rebase terlalu rumit
git rebase --continue  # lanjutkan setelah resolve konflik per commit

KAPAN dua perintah ini dipakai? --abort saat kamu sadar rebase-nya salah arah dan ingin kembali ke kondisi sebelum rebase. --continue setelah kamu resolve konflik di satu commit dan siap lanjut ke commit berikutnya.

Kesalahan umum pemula: salah vs benar

SALAH: rebase branch main yang sudah di-push ke GitHub supaya "riwayatnya bersih".

bash
git switch main
git rebase origin/main   # JANGAN. Ini menulis ulang riwayat bersama.

Akibatnya tim-mu harus berjuang memperbaiki sinkronisasi mereka. Jangan jadi orang itu.

BENAR: rebase hanya untuk branch pribadi yang belum dishare.

bash
git switch fitur-login     # branch pribadimu, belum di-PR
git rebase main            # aman

SALAH: panik saat konflik muncul berkali-kali selama rebase dan mengira ada yang rusak.

BENAR: pahami bahwa konflik rebase diselesaikan PER COMMIT (bisa muncul berulang), berbeda dengan merge yang sekali di akhir. Itu harga riwayat linear. Kalau rebase terasa menyiksa untuk branch yang panjang, itu sinyal branch-nya sebaiknya di-merge saja, bukan di-rebase.

Catatan teknis: setelah rebase branch yang sudah pernah di-push (branch pribadimu), push berikutnya butuh git push --force-with-lease karena riwayatnya ditulis ulang. --force-with-lease lebih aman dari --force karena menolak jalan kalau ada commit baru dari orang lain di remote.

Tantangan

Squash 3 commit jadi 1

Di branch baru, buat 3 commit kecil ('tambah a', 'tambah b', 'fix typo'). Lalu git rebase -i HEAD~3: ubah dua commit terakhir jadi squash, tulis pesan baru 'Tambah fitur ab'. Verifikasi dengan git log --oneline -3 bahwa tinggal 1 commit rapi.