Git Rebase Bikin Kamu Bingung Jangan Takut Ini Panduannya

Pernah nggak sih kamu lagi asik ngoding, terus tiba-tiba ketemu sama perintah Git yang namanya rebase? Rasanya kayak masuk ke dimensi lain, langsung pusing tujuh keliling. Nggak jarang kan, perintah ini bikin deg-degan, takut salah malah bikin history Git berantakan?

Tenang, kamu nggak sendirian! Banyak banget developer, apalagi yang masih awal-awal pakai Git secara serius, ngerasa git rebase itu misterius dan agak menakutkan. Padahal, kalau kamu udah paham, rebase ini powerful banget buat bikin sejarah (history) proyek kamu jadi lebih rapi, bersih, dan mudah dibaca. Ini penting banget lho, apalagi kalau kerja bareng tim, biar nggak ada lagi tuh history bercabang-cabang nggak jelas kayak akar pohon.

Artikel ini dibuat khusus buat kamu yang pengen ‘taklukin’ git rebase tanpa harus jidat berkerut. Kita bakal bedah pelan-pelan, dari yang paling dasar sampai yang interaktif, biar kamu nggak bingung lagi dan malah bisa pakai rebase buat ningkatin produktivitas kamu dan tim. Yuk, kita mulai petualangan menaklukan git rebase!

Git Rebase Vs. Git Merge: Apa Bedanya Sih?

Oke, sebelum nyelam lebih dalam ke rebase, kita harus paham dulu bedanya sama saudaranya yang lebih populer, yaitu git merge. Kamu pasti lebih familiar sama merge kan?

• git merge: Ini kayak menggabungkan dua jalur sejarah jadi satu. Jadi, kalau kamu punya cabang (branch) A dan cabang B, terus kamu merge B ke A, Git bakal bikin "merge commit" baru di cabang A. Commit ini fungsinya kayak jembatan yang nyambungin ujung cabang B ke cabang A. History-nya bakal kelihatan bercabang, terus nyatu di merge commit tadi. Gampangnya, merge itu menjaga sejarah apa adanya, cuma nambahin catatan kalau ada penggabungan.

git rebase: Nah, kalau rebase ini beda. Dia kayak "memindahkan" (re-base) serangkaian commit dari satu branch ke branch lain, tapi dengan cara menulis ulang sejarah. Analoginya gini: Bayangin kamu punya cabang A dan B. Cabang B dibuat dari titik tertentu di A. Nah, kalau kamu rebase cabang B di atas A terbaru, Git bakal ngambil semua commit yang ada di cabang B (setelah titik awal B dibuat), terus 'tempelin' lagi satu per satu di ujung* cabang A yang paling baru. Hasilnya? History cabang B bakal kelihatan lurus, seolah-olah cabang B itu dibuat dari versi A yang paling baru, bukan dari yang lama. Nggak ada merge commit, history-nya kelihatan lebih linear.

Jadi, perbedaan fundamentalnya ada di cara mengelola sejarah proyek: merge mempertahankan sejarah percabangan dengan merge commit, sedangkan rebase "meratakan" sejarah dengan memindahkan commit.

Mana yang lebih baik? Nggak ada jawaban tunggal. Dua-duanya punya kelebihan dan kekurangan, tergantung kebutuhan dan workflow tim kamu. Merge lebih aman karena nggak nulis ulang history (jadi gampang dilacak), tapi history-nya bisa jadi kelihatan 'kotor' kalau banyak branch pendek yang sering di-merge. Rebase bikin history kelihatan rapi jali, linear, tapi prosesnya bisa lebih tricky (terutama kalau ada konflik) dan berbahaya kalau dipakai di branch yang dipakai bareng-bareng (shared branch). Ini poin penting banget yang nanti bakal kita bahas lebih lanjut.

Rebase Dasar: Memindahkan Commit dengan Santai

Oke, kita mulai dari yang paling basic: git rebasebranchtarget>.

Misalnya, kamu lagi kerja di branch namanya fitur-keren. Branch ini kamu buat dari branch main. Sementara kamu asik ngoding di fitur-keren, teman satu tim kamu push update baru ke branch main. Sekarang branch main kamu ketinggalan kan? Biar fitur-keren kamu up-to-date sama main terbaru sebelum nanti di-merge atau di-rebase lagi, kamu bisa rebase fitur-keren di atas main yang baru.

Caranya:

1. Pastikan kamu lagi di branch fitur-keren: git checkout fitur-keren
2. Jalankan perintah rebase: git rebase main

Apa yang terjadi di balik layar?

• Git bakal mundur ke commit terakhir yang sama antara fitur-keren dan main.
• Git bakal nyimpen semua commit yang cuma ada di fitur-keren (setelah titik pisah itu) sementara.
• Git pindah ke branch main yang paling baru.
• Git nempelin (apply) lagi satu per satu commit yang tadi disimpen ke atas main yang baru.
• Setelah semua commit berhasil ditempel, ujung branch fitur-keren bakal geser ke commit terakhir yang baru aja ditempel.

Voila! Sekarang branch fitur-keren kamu udah sinkron sama main yang baru, dan history-nya kelihatan seolah-olah kamu buat branch fitur-keren itu dari main yang udah up-to-date. History-nya jadi linear dan rapi.

Tapi, hati-hati! Kalau ada konflik pas Git nempelin commit satu per satu, proses rebase-nya bakal berhenti. Kita bahas itu sebentar lagi.

Kekuatan Super: Git Rebase Interaktif (-i)

Ini nih bagian paling seru dan paling sering bikin pusing. git rebase -i (interaktif) adalah alat super power buat bersih-bersih history kamu. Dengan mode interaktif, kamu nggak cuma mindahin commit, tapi juga bisa:

• Mengubah pesan commit (reword): Kalau ada typo di pesan commit atau pengen pesannya lebih jelas.
• Menggabungkan beberapa commit jadi satu (squash atau fixup): Cocok banget buat ngegabungin commit-commit kecil kayak "fix typo", "WIP", atau "sementara" jadi satu commit yang lebih bermakna. squash nanti bakal minta kamu nulis pesan commit baru yang gabungan, kalau fixup bakal buang pesan commit yang di-fixup dan pakai pesan commit yang 'dipertahankan'.
• Mengubah commit (edit): Ini kalau kamu pengen nambahin perubahan ke commit yang udah lewat atau bahkan misahin satu commit besar jadi beberapa commit kecil.
• Menghapus commit (drop): Kalau ada commit yang ternyata nggak penting atau salah.
• Mengubah urutan commit (reorder): Meskipun jarang dipakai, kamu bisa aja geser-geser urutan commit.

Gimana cara pakainya?

Sama kayak rebase biasa, kamu checkout dulu ke branch yang mau dibersihin history-nya. Misalnya, masih di branch fitur-keren.

git checkout fitur-keren

Kemudian, jalankan rebase interaktif. Kamu perlu tentuin sampai commit mana kamu mau rebase atau bersih-bersih. Biasanya, kamu pengen bersih-bersih commit yang ada di branch kamu aja, bukan commit yang udah ada di branch asalnya (main).

Jadi, perintahnya bakal kayak gini: git rebase -i main

Atau, kalau kamu tahu berapa commit terakhir di branch kamu yang mau diedit (misalnya 3 commit terakhir): git rebase -i HEAD~3

Setelah perintah itu dijalanin, Git bakal ngebuka text editor default kamu. Di dalamnya bakal ada daftar commit yang lagi "diproses" rebase, dari yang paling tua di atas sampai yang paling baru di bawah. Di setiap baris ada instruksi yang bisa kamu ganti (defaultnya pick), diikuti hash commit dan pesan commit.

pick aaaaaaa commit pesan 1
pick bbbbbbb commit pesan 2
pick ccccccc commit pesan 3Perintah-perintah yang bisa kamu pakai:
p, pick  = pakai commit
r, reword  = pakai commit, tapi ubah pesan commit
e, edit  = pakai commit, tapi berhenti untuk mengubah commit (amend)
s, squash  = pakai commit, gabungkan dengan commit di atasnya
f, fixup  = pakai commit, gabungkan dengan commit di atasnya dan buang pesan log-nya
x, exec  = jalankan command di shell untuk commit ini
d, drop  = hapus commit
l, label  = mark current HEAD with a name
t, tag  = tag the commit
m, merge [-C  | -c ]  [# ]Rebase aaaaaaa..ccccccc onto aaaaaaa (3 commands)
# Changes to be committed:
(use "git commit --amend" to add changes to the latest commit)
#

Nah, di sini kamu bisa ngubah kata pick di depan setiap baris jadi perintah lain sesuai keinginan kamu.

Contoh Skenario Interaktif:

Misalnya, kamu punya history commit kayak gini di branch fitur-keren kamu:

1. aaaaaaa (commit awal branch fitur-keren dari main)
2. bbbbbbb fix typo di halaman utama
3. ccccccc add button
4. ddddddd lagi-lagi fix typo
5. eeeeeee nambahin fungsi klik buat button

Kamu pengen:

• Ngubah pesan commit bbbbbbb biar lebih jelas.
• Nggabungin ddddddd (fix typo) ke commit sebelumnya (ccccccc).
• Nggabungin ccccccc dan eeeeeee jadi satu commit "Implementasi Button".

Kalau kamu jalanin git rebase -i aaaaaaa^ (ini artinya rebase setelah commit aaaaaaa, atau rebase semua commit di branch ini kalau aaaaaa adalah commit terakhir di main sebelum branch kamu dibuat), editor bakal nampilin:

pick bbbbbbb fix typo di halaman utama
pick ccccccc add button
pick ddddddd lagi-lagi fix typo
pick eeeeeee nambahin fungsi klik buat button

Kamu bisa ubah jadi gini:

reword bbbbbbb fix typo di halaman utama
pick ccccccc add button
fixup ddddddd lagi-lagi fix typo
squash eeeeeee nambahin fungsi klik buat button

Penjelasannya:

• reword bbbbbbb: Pas Git sampai di commit ini, dia bakal berhenti dan ngebuka editor lagi biar kamu bisa ubah pesan commit-nya.
• pick ccccccc: Commit ini diambil apa adanya.
• fixup ddddddd: Commit ini digabungin ke commit di atasnya (ccccccc). Pesan commit ddddddd ("lagi-lagi fix typo") bakal dibuang.
• squash eeeeeee: Commit ini digabungin ke commit di atasnya (ddddddd yang sebenarnya udah digabungin ke ccccccc oleh fixup). Git bakal ngebuka editor buat kamu nulis pesan commit baru untuk gabungan ccccccc, ddddddd, dan eeeeeee. Kamu bisa tulis "Implementasi Button dan perbaikan terkait".

Setelah kamu simpan dan tutup editor rebase interaktif yang pertama, Git bakal mulai prosesnya.

1. Git bakal berhenti di commit bbbbbbb karena kamu pakai reword. Editor bakal kebuka, kamu ubah pesannya (misalnya jadi "Perbaikan typo di header"). Simpan & tutup.
2. Git lanjut, ambil ccccccc.
3. Git lanjut, sampai di ddddddd. Karena fixup ke commit di atasnya (ccccccc), perubahannya digabung. Pesan commit ddddddd dibuang.
4. Git lanjut, sampai di eeeeeee. Karena squash ke commit di atasnya (yang sekarang jadi gabungan ccccccc dan ddddddd), Git gabungin perubahannya. Editor kebuka, kamu tulis pesan commit baru untuk gabungan ini.
5. Selesai! History kamu sekarang jadi lebih rapi dengan commit yang lebih bermakna.

Penting: Urutan commit di file editor interaktif itu dari yang paling tua ke yang paling baru. Kalau kamu squash atau fixup, itu selalu digabungin ke commit yang ada persis di atasnya di daftar editor.

Resolusi Konflik Saat Rebase: Jangan Panik!

Nah, ini nih momen yang paling sering bikin developer dag-dig-dug saat rebase: konflik! Konflik terjadi kalau Git berusaha nempelin commit (saat rebase), tapi ada perubahan di file yang sama persis dengan yang sudah ada di branch target, dan perubahannya beda atau tumpang tindih.

Kalau konflik muncul, proses rebase bakal berhenti dan Git bakal kasih tahu file mana aja yang konflik. Tampilannya di terminal bakal kayak gini:

Applying: pesan commit yang konflik
Using index info to reconstruct a base tree...
M   nama/file/yang/konflik.js
...
CONFLICT (content): Merge conflict in nama/file/yang/konflik.js
Failed to merge in the changes.
Patch failed at 0001 Applying: pesan commit yang konflik
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To abort and get back to the state before the rebase, run "git rebase --abort".

Jangan panik! Git udah kasih tahu langkah-langkahnya kok di pesan itu.

1. Lihat file yang konflik: Buka file yang disebutin (misalnya nama/file/yang/konflik.js) di editor kode kamu. Kamu bakal lihat tanda-tanda konflik kayak <<<<<<<, =======, >>>>>>>. Bagian antara <<<<<<< HEAD dan ======= adalah perubahan yang ada di branch kamu (branch yang lagi di-rebase). Bagian antara ======= dan >>>>>>> adalah perubahan dari branch target (branch yang jadi basis rebase, misalnya main).
2. Edit file untuk menyelesaikan konflik: Pilih atau gabungkan perubahan dari kedua sisi sesuai keinginan kamu. Hapus baris-baris <<<<<<<, =======, dan >>>>>>> setelah selesai.
3. Tambahkan file yang sudah selesai di-resolve: Setelah konflik selesai di semua file yang bermasalah, beri tahu Git kalau kamu udah selesai dengan menjalankan git add nama/file/yang/konflik.js (atau git add . kalau konflik di banyak file).
4. Lanjutkan rebase: Jalankan perintah git rebase --continue.

Git bakal lanjut nempelin commit berikutnya. Kalau ada konflik lagi di commit lain, ulangi langkah 1-3. Terus begitu sampai semua commit berhasil ditempel.

Perintah Penting saat Konflik:

• git status: Selalu cek status buat lihat file mana aja yang masih konflik.
• git rebase --continue: Melanjutkan proses rebase setelah kamu menyelesaikan konflik dan git add file-file yang konflik.

git rebase --skip: Melewatkan commit yang lagi diproses saat ini*. Hati-hati pakai ini, artinya commit itu bakal hilang dari history kamu. Hanya pakai kalau kamu yakin commit itu nggak relevan atau perubahannya udah dicover di commit lain.

• git rebase --abort: Membatalkan seluruh proses rebase dan mengembalikan branch kamu ke kondisi sebelum rebase dimulai. Ini "tombol darurat" kalau kamu ngerasa kacau banget.

Menyelesaikan konflik saat rebase memang butuh latihan. Kuncinya adalah teliti saat ngedit file konflik dan jangan takut pakai git status atau git diff untuk melihat perubahan.

Aturan Emas Git Rebase: Jangan Rebase Branch yang Dibagi!

Ini adalah aturan paling PENTING yang harus kamu ingat tentang git rebase.

JANGAN PERNAH jalankan git rebase di branch yang sudah kamu push ke remote repository (GitHub, GitLab, Bitbucket, dll) dan sudah dipakai atau ditarik (pulled) oleh anggota tim lain.

Kenapa?

Karena rebase menulis ulang sejarah. Saat kamu rebase dan sukses, commit-commit di branch kamu yang tadinya punya hash A, B, C, D, sekarang jadi A', B', C', D'. Hash commit-nya berubah!

Kalau kamu paksa push history yang baru ini ke remote repository (pakai git push --force atau git push --force-with-lease), remote repository bakal punya dua 'versi' sejarah yang berbeda tapi isinya sama (history yang lama sebelum rebase dan history yang baru setelah rebase).

Nah, kalau ada anggota tim lain yang udah menarik history branch kamu yang lama, nanti pas dia mau push atau pull lagi, Git di komputernya bakal bingung karena history di lokal dia beda sama history di remote yang udah kamu "paksa" ganti. Ini bakal bikin konflik parah dan susah banget diselesaiin, apalagi kalau banyak orang yang terlibat.

Kapan Boleh Rebase?

Kamu boleh rebase hanya di branch yang masih bersifat pribadi (private/local branch) dan belum kamu push ke remote, atau kalaupun udah di-push, kamu yakin banget nggak ada satu orang pun di tim kamu yang narik atau pakai branch itu.

Idealnya, rebase dipakai untuk membersihkan history branch lokal kamu sebelum kamu buka Pull Request/Merge Request atau sebelum di-merge ke branch utama (main, develop, dll). Ini tujuannya biar waktu di-merge nanti, history-nya kelihatan rapi dan linear di branch utama.

Kalau kamu pengen sinkronisasi branch lokal kamu (fitur-keren) dengan branch utama (main) yang udah di-update oleh orang lain, tapi branch fitur-keren kamu sudah terlanjur di-push dan mungkin ada yang pakai, lebih aman pakai git merge main ke branch fitur-keren kamu, daripada pakai git rebase main.

Tips dan Trik Pakai Git Rebase Biar Makin Jago

• Pahami git reflog: Ini sahabat terbaik kamu kalau ada yang salah. git reflog itu semacam catatan sejarah lokal yang nyimpen setiap kali HEAD kamu berpindah (termasuk saat rebase). Kalau kamu ngerasa rebase kamu kacau dan pengen balik ke kondisi sebelum rebase, jalankan git reflog, cari posisi HEAD sebelum rebase, terus git reset --hard HEAD@{indeksdireflog}. Ini kayak tombol undo super power!
• Lakukan rebase secara berkala: Jangan tunggu sampai branch kamu punya puluhan commit baru baru direbase. Rebase branch lokal kamu ke branch utama secara berkala (misalnya setiap hari atau setiap kali ada update besar di branch utama) bisa mengurangi kemungkinan konflik yang parah.
• Rebase commit sedikit demi sedikit: Kalau kamu mau rebase interaktif banyak commit, coba pecah jadi beberapa rebase interaktif yang lebih kecil. Misalnya, rebase dulu 10 commit pertama, selesaikan, baru rebase 10 commit berikutnya. Ini bikin proses debug kalau ada yang salah jadi lebih gampang.
• Gunakan rebase untuk memisahkan commit: Kadang kamu bikin satu commit gede yang isinya perubahan buat dua fitur berbeda. Pakai git rebase -i dengan perintah edit di commit itu. Git bakal berhenti di commit tersebut, kamu bisa pakai git reset HEAD^ (buat ngembaliin perubahan commit itu jadi staged changes), terus pakai git add -p atau git addbuat milih perubahan mana aja yang mau dijadiin commit pertama, commit, terus git add sisa perubahan buat commit kedua, commit lagi. Setelah itu, jalankan git rebase --continue.
• Latihan di repository dummy: Sebelum pakai rebase di proyek sungguhan, coba dulu di repository lokal yang kamu buat sendiri. Bikin beberapa branch, bikin commit, merge, terus coba rebase dan rebase interaktif. Bikin konflik sengaja, coba selesaikan. Ini cara terbaik buat kenalan sama rebase tanpa risiko merusak proyek tim.

Penutup: Taklukkan Rebase, Bikin History Rapi!

Memang nggak bisa dipungkiri, git rebase itu perintah yang lumayan kompleks dan punya kurva belajar yang agak curam dibanding merge. Tapi, manfaatnya buat bikin history proyek kamu jadi rapi, linear, dan mudah dibaca itu besar banget, terutama kalau kamu pengen proses code review atau debugging jadi lebih gampang.

Mulai sekarang, jangan takut lagi sama git rebase. Coba pelan-pelan, mulai dari rebase dasar, lalu coba rebase interaktif dengan skenario sederhana (kayak reword atau squash dua commit terakhir). Jangan lupa selalu ingat aturan emas: jangan rebase branch yang dipakai bareng-bareng! Dan ingat git reflog adalah penyelamat kamu.

Dengan latihan dan pemahaman yang benar, git rebase bakal jadi salah satu alat paling ampuh di toolkit Git kamu. Jadi, siap untuk bikin sejarah Git kamu sebersih mungkin? Gas!