Cara `git rebase -i` Bikin History Commit Kamu Jauh Lebih Bersih Sebelum Bikin PR

Cara `git rebase -i` Bikin History Commit Kamu Jauh Lebih Bersih Sebelum Bikin PR
Photo by Markus Winkler/Unsplash

Pernah enggak sih kamu ngerasa malu sendiri saat buka history commit branch lokal kamu? Isinya campur aduk: "WIP," "Fix typo (again)," "Lupa nambahin semicolon," atau bahkan yang paling parah, puluhan commit kecil yang seharusnya bisa disatukan jadi satu kesatuan yang rapi.

Di dunia pengembangan profesional, apalagi kalau kamu kerja di software house yang mengedepankan kualitas dan maintainability (seperti di Javapixa Creative Studio, misalnya), history commit itu bukan cuma catatan pribadi, tapi juga aset tim. Commit yang bersih, terstruktur, dan jelas maknanya adalah kunci agar proses code review (PR/Merge Request) berjalan mulus, cepat, dan enggak bikin reviewer kamu pusing tujuh keliling.

Nah, di sini lah jagoan kita muncul: git rebase -i, alias Interactive Rebase. Ini adalah jurus rahasia para developer senior untuk memoles riwayat branch mereka, mengubah yang awalnya mirip catatan belanja jadi laporan keuangan yang detail dan profesional. Siap-siap, karena setelah ini, cara kamu berinteraksi dengan Git bakal naik level.

Kenapa Harus Repot-repot Pakai Rebase? Bukannya Merge Sudah Cukup?

Sebelum kita masuk ke interactive rebase, kita harus bedakan dulu dua cara utama menggabungkan perubahan: git merge dan git rebase.

git merge itu ibaratnya kamu gabung dua jalur kereta api di stasiun. Sejarah kedua jalur itu tetap dipertahankan, dan hasilnya adalah merge commit baru yang menjadi saksi penggabungan. Keuntungannya, sejarahnya jujur (tidak ada yang diubah). Kekurangannya, kalau sering dipakai, history kamu bisa jadi kusut dan bercabang-cabang, sering disebut "Christmas Tree History."

git rebase itu beda lagi. Dia bukan menggabungkan, tapi memindahkan. Secara harfiah, rebase mengambil commit-commit dari branch kamu, lalu menempelkannya di atas HEAD branch tujuan (misalnya, main atau develop) seolah-olah kamu baru mulai kerja dari titik terbaru itu. Hasilnya? Sejarah yang lurus (linear), bersih, dan indah dilihat.

Ketika kita menambahkan opsi -i (interactive), kita tidak hanya memindahkannya, tapi kita diberi kesempatan untuk mengedit, menggabungkan, atau bahkan menghapus commit-commit tersebut sebelum mereka ditempelkan. Ini dia bagian yang gokilnya.

*

Mengenal Kekuatan Magis git rebase -i

git rebase -i memungkinkan kamu untuk menata ulang, menyusun kembali, dan membersihkan setiap commit yang ada di branch lokal kamu, sebelum kamu mengajukannya sebagai Pull Request.

Bayangkan kamu sedang menulis naskah film. Commit-commit kecil adalah draf-draf adeganmu. Tapi, saat diserahkan ke produser, kamu enggak mau mereka baca puluhan draf yang sama dengan koreksi minor. Kamu mau mereka baca naskah final yang rapi per bab. git rebase -i adalah proses penyuntingan dan penggabungan draf menjadi bab yang kohesif.

Bagaimana Cara Memanggil Si Jagoan?

Command yang paling umum digunakan biasanya seperti ini:

bash
git rebase -i HEAD~N

Atau, lebih sering:

bash
git rebase -i branchdasar>

Contoh: Jika kamu sedang mengerjakan fitur di branch fitur-keren dan ingin membersihkannya sebelum di-merge ke main, kamu jalankan:

bash
git rebase -i main

Setelah menjalankan command tersebut, editor default (biasanya Vim atau Nano) akan terbuka, menampilkan daftar commit terbaru di branch kamu, dan di bawahnya ada petunjuk instruksi yang bisa kamu gunakan. Ini adalah daftar tugas yang harus Git lakukan.

Lima Instruksi Utama yang Wajib Kamu Kuasai

Di dalam editor, setiap baris mewakili satu commit, diawali dengan kata kunci instruksi. Lima instruksi ini adalah senjata utama kamu:

1. pick (p)

Ini adalah default-nya. Artinya: "Ambil commit ini sebagaimana adanya, jangan diubah." Jika kamu tidak melakukan apa-apa, semua akan di-pick.

2. squash (s)

Ini dia yang sering dipakai! squash digunakan untuk menggabungkan commit saat ini ke commit sebelumnya (yang ada di atasnya). Setelah penggabungan, Git akan meminta kamu untuk mengedit pesan commit gabungan baru. Pesan-pesan dari kedua commit akan muncul sebagai saran.

Kapan pakai squash? Ketika kamu punya tiga commit yang semuanya terkait dengan satu fitur logis, tapi kamu ingin agar history mencatatnya hanya sebagai satu commit besar. Misalnya: "Implementasi fitur login."

3. fixup (f)

Sama seperti squash, fixup menggabungkan commit saat ini ke commit sebelumnya. Bedanya, fixup membuang pesan commit yang sekarang dan hanya menggunakan pesan commit yang pertama (yang di atasnya).

Kapan pakai fixup? Sering dipakai untuk "perbaikan kilat." Misalnya, commit pertama kamu adalah "Implementasi header navbar," lalu commit kedua kamu "Fix typo di navbar." Kamu enggak butuh pesan "Fix typo" muncul di history final. Cukup ganti instruksi commit kedua menjadi fixup.

4. reword (r)

Instruksi ini memungkinkan kamu mengubah pesan commit saat ini, tanpa mengubah konten atau kodenya. Git akan berhenti setelah memproses commit ini dan membuka editor lagi hanya untuk mengganti pesannya.

Kapan pakai reword? Ketika pesan commit kamu terlalu singkat ("fiks bug") dan kamu ingin membuatnya lebih deskriptif ("Memperbaiki isu infinite loading pada halaman dashboard").

5. edit (e)

Perintah ini akan menghentikan proses rebase setelah commit ini diproses. Ini memberi kamu kesempatan untuk melakukan perubahan tambahan pada kodenya, menambahkan file, atau bahkan memecah commit yang terlalu besar menjadi beberapa commit kecil. Setelah selesai, kamu harus menjalankan git commit --amend (jika hanya mengubah commit yang sedang di-edit) atau git add . && git commit (jika membuat commit baru), lalu git rebase --continue.

*

Studi Kasus Nyata: Membersihkan History Sebelum PR

Misalkan kamu punya history commit seperti ini:

  1. 8a3d12a: feat: Add basic user profile page structure
  2. c9b0e4f: fix: Forgot to include CSS file
  3. 2d6f890: style: Adjusting margin spacing on profile page
  4. e1f2g3h: refactor: Cleaning up commented code
  5. 4h5j6k7: chore: Updating documentation about user profile (THE REAL FEATURE COMPLETE)

Ini kelihatan berantakan kalau diajukan PR. Kamu ingin agar semua commit terkait styling dan perbaikan kecil (c9b0e4f, 2d6f890, e1f2g3h) digabungkan ke commit fitur utama (8a3d12a), dan commit dokumentasi (4h5j6k7) berdiri sendiri.

Langkah 1: Panggil Interactive Rebase

bash
git rebase -i main

Langkah 2: Edit Instruksi di Editor

Di editor kamu, awalnya akan terlihat seperti ini:

pick 8a3d12a feat: Add basic user profile page structure
pick c9b0e4f fix: Forgot to include CSS file
pick 2d6f890 style: Adjusting margin spacing on profile page
pick e1f2g3h refactor: Cleaning up commented code
pick 4h5j6k7 chore: Updating documentation about user profileRebase 1b2c3d4..4h5j6k7 onto 1b2c3d4

Kamu ubah menjadi:

pick 8a3d12a feat: Add basic user profile page structure
fixup c9b0e4f fix: Forgot to include CSS file
fixup 2d6f890 style: Adjusting margin spacing on profile page
fixup e1f2g3h refactor: Cleaning up commented code
squash 4h5j6k7 chore: Updating documentation about user profile

Penjelasan Perubahan:

  1. 8a3d12a (Fitur utama) tetap di-pick. Ini akan menjadi base untuk penggabungan.
  2. Commit 2, 3, dan 4 diubah menjadi fixup. Mereka akan digabungkan ke commit di atasnya (8a3d12a), dan pesan commit mereka (yang minor) akan dibuang.
  3. Commit terakhir diubah menjadi squash. Ini akan digabungkan ke 8a3d12a, tapi Git akan menanyakan pesan commit baru, memungkinkan kita menggabungkan pesan fitur utama dan pesan dokumentasi menjadi satu.

Langkah 3: Selesaikan Proses Rebase

  1. Simpan dan tutup editor.
  2. Git akan mulai memproses. Karena kita menggunakan squash (bukan fixup semua), Git akan membuka editor lagi. Di sini, kamu harus menggabungkan pesan dari 8a3d12a dan 4h5j6k7 menjadi satu pesan yang rapi, misalnya:
feat: User Profile Page Implemented
  1. Simpan dan tutup editor lagi.
  2. Selesai!

History kamu sekarang hanya memiliki dua commit (bukan lima), dan keduanya sangat jelas serta fokus.

The Golden Rule of Rebase: Kapan Harus Stop?

Meskipun git rebase -i sangat ampuh untuk membersihkan sejarah, ada satu aturan emas yang tidak boleh dilanggar. Aturan ini sangat ditekankan di lingkungan profesional, termasuk di Javapixa Creative Studio, demi menjaga integritas tim.

JANGAN PERNAH REBASE COMMIT YANG SUDAH KAMU PUSH KE PUBLIC BRANCHS (BRANCH YANG SUDAH DIPAKAI ORANG LAIN).

Kenapa? Karena rebase mengubah identitas commit (SHA hash). Jika kamu mengubah commit yang sudah diunduh orang lain, saat mereka mencoba mengunduh perubahan terbaru, Git akan bingung. Ini memaksa rekan tim kamu untuk melakukan reset atau force pull, yang bisa menyebabkan hilangnya pekerjaan mereka.

Kapan rebase -i aman digunakan?

  1. Hanya pada local branch kamu yang belum di-push sama sekali.
  2. Pada feature branch yang sudah kamu push, asalkan kamu satu-satunya yang bekerja di branch tersebut (atau kamu sudah memastikan semua orang tahu dan setuju dengan perubahan itu).

Jika kamu sudah terlanjur rebase branch yang sudah di-push, kamu harus menggunakan:

bash
git push --force-with-lease

Jangan gunakan git push --force! Perintah --force-with-lease jauh lebih aman karena dia akan membatalkan force push jika branch remote sudah berubah sejak terakhir kali kamu pull. Ini adalah pengaman wajib agar kamu tidak menimpa pekerjaan rekan tim yang mungkin baru saja di-push.

Mengapa History Commit yang Bersih Adalah Standar Profesional

Di Javapixa Creative Studio, kami selalu menekankan bahwa kode yang bersih harus didukung oleh proses yang bersih. History commit yang rapi bukan sekadar soal estetika; ini adalah tentang efisiensi tim:

  1. Code Review Lebih Cepat: Reviewer bisa memahami keseluruhan fitur hanya dengan membaca satu atau dua commit yang deskriptif, alih-alih harus membaca puluhan typo fix. Ini membuat Pull Request kamu auto-approve lebih cepat.
  2. Debugging Mudah: Saat terjadi bug di masa depan, menggunakan git bisect (alat untuk mencari commit yang menyebabkan bug) akan jauh lebih mudah dan akurat jika setiap commit mewakili perubahan fungsional yang utuh, bukan hanya perbaikan minor.
  3. Dokumentasi yang Jelas: Setiap commit berfungsi sebagai dokumentasi mini tentang mengapa dan bagaimana suatu fitur dibuat.

Mempelajari dan menguasai git rebase -i adalah lompatan besar dari sekadar coder menjadi software engineer yang disiplin. Ini menunjukkan bahwa kamu peduli tidak hanya pada kode yang kamu tulis, tetapi juga pada proses kolaborasi dan kualitas history proyek secara keseluruhan.

Jadi, mulai sekarang, jadikan ritual: sebelum kamu membuat PR, selalu sediakan waktu 5 menit untuk menjalankan git rebase -i main dan bersihkan kekacauan yang kamu buat selama proses pengembangan. Percayalah, rekan tim kamu (dan diri kamu di masa depan) akan sangat berterima kasih.