Stop Ngerjain Fitur Baru Dulu Coba Bersihin Dulu Histori Git Kamu Pakai Trik Rebase -i Ini

Banyak dari kita, terutama yang baru nyemplung di dunia development, sering banget punya kebiasaan buruk yang bikin pusing tim lain: commit history yang berantakan.

Coba deh jujur, berapa kali kamu melakukan commit dengan pesan seperti:

  • fix: typo
  • fix: typo lagi
  • WIP
  • lupa tadi apa ya
  • cuma nambahin titik koma

Kalau kamu mau diakui sebagai developer yang profesional, apalagi kalau nanti kamu bekerja dengan standar tinggi seperti di Javapixa Creative Studio, kebiasaan ini harus segera dihilangkan. Tim reviewer di sana tidak akan mau melihat PR (Pull Request) kamu berisi 20 commit yang 15 di antaranya cuma fix kecil.

Stop ngerjain fitur baru dulu. Sebelum kamu merge atau kirim PR, ada satu tugas wajib yang harus kamu lakukan: bersih-bersih rumah. Dan senjata rahasia kita untuk operasi bersih-bersih ini adalah git rebase --interactive atau yang lebih keren kita sebut rebase -i.

Ini bukan sekadar tips coding biasa. Ini adalah etika profesionalisme yang membedakan developer amatir dan developer yang serius.

Kenapa Histori Git yang Bersih Itu Wajib?

Mungkin kamu mikir, "Ah, yang penting kodenya jalan. History itu urusan belakang." Salah besar! History Git adalah jurnal resmi dari proyek kamu.

  1. Memudahkan Code Review: Tim kamu (atau tim profesional seperti di Javapixa Creative Studio) akan lebih mudah melacak dan me-review. Daripada melihat 20 commit kecil, mereka hanya perlu melihat 1 atau 2 commit yang isinya perubahan fungsionalitas besar.
  2. Debugging Jadi Gampang: Kalau nanti terjadi bug dan kamu perlu menggunakan git bisect (tools super keren untuk mencari commit mana yang menyebabkan bug), history yang rapi akan mempercepat proses pencarian. Bayangkan kalau git bisect berhenti di commit yang cuma berbunyi fix: typo. Itu buang-buang waktu.
  3. Kejelasan Fungsionalitas: Setiap commit harus mewakili satu unit perubahan logis. Satu commit = satu tujuan. Ini membuat maintainability kode jadi jauh lebih tinggi.

rebase -i memungkinkan kita menulis ulang sejarah lokal (yang belum di-push atau di-share ke orang lain) sedemikian rupa sehingga seolah-olah kamu sudah mengerjakannya dengan sempurna sejak awal. Keren, kan?

---

Memanggil Kekuatan rebase -i

Inti dari rebase -i adalah mengubah daftar commit menjadi script yang bisa kamu edit. Kamu bisa mengubah urutan, menggabungkan, bahkan menghapus commit yang tidak penting.

1. Tentukan Batasan Sejarah

Sebelum kamu mulai, kamu harus tahu batas mana yang ingin kamu bersihkan. Ada dua cara paling umum untuk memanggilnya:

A. Berdasarkan Jumlah Commit (Paling Sering Digunakan):

Misalnya, kamu mau bersih-bersih lima commit terakhir kamu:

bash
git rebase -i HEAD~5

B. Berdasarkan SHA Commit:

Jika kamu ingin membersihkan semua commit yang terjadi setelah commit dengan SHA tertentu (misalnya a3b4c5d), kamu menggunakan SHA sebelum commit pertama yang ingin kamu ubah.

bash
git rebase -i a3b4c5d

Setelah kamu jalankan perintah itu, editor teks kamu (Vim, Nano, VS Code, tergantung setting kamu) akan terbuka dan menampilkan daftar commit yang urutannya dari yang paling lama di atas, sampai yang paling baru di bawah.

Contoh tampilan di editor:

pick f0472e3 feat: menambahkan kerangka landing page
pick 8a9b1c2 fix: memperbaiki warna tombol
pick e3d0f0c wip: mencoba implementasi animasi
pick a7f8b9d fix: benerin lagi warna tombol
pick 1d2e3f4 clean: menghapus kode yang tidak terpakaiRebase 5d1f8a..1d2e3f4 onto 5d1f8a

Tugas kamu sekarang adalah mengubah kata kunci pick yang ada di sebelah kiri SHA.

---

Kamus Aksi rebase -i

Inilah daftar aksi yang paling sering kamu gunakan untuk membersihkan history. Kamu hanya perlu mengganti pick dengan salah satu kata kunci di bawah ini:

1. pick (p)

Ini adalah default. Artinya: "Pertahankan commit ini, dan jangan diapa-apain." Biasanya commit pertama dalam daftar (yang paling atas) tetap kamu biarkan sebagai pick.

2. squash (s)

Artinya: "Gabungkan commit ini dengan commit sebelumnya, tapi beri aku kesempatan untuk mengubah pesan commit yang baru."

Kamu akan menggunakan ini ketika kamu punya beberapa commit yang secara logis harusnya jadi satu, tapi kamu ingin membuat pesan commit yang lebih jelas dan profesional.

3. fixup (f)

Ini adalah malaikat penyelamat para developer yang sering bikin commit fix: typo. Artinya: "Gabungkan commit ini dengan commit sebelumnya, dan buang pesan commit ini. Gunakan saja pesan commit yang sebelumnya."

Jika kamu punya commit feat: add user login diikuti oleh fix: typo di user login, lebih baik kamu fixup yang kedua ke yang pertama. Hasilnya, history kamu cuma akan mencatat satu commit: feat: add user login.

4. edit (e)

Artinya: "Berhenti dulu proses rebase di commit ini. Biarkan aku mengubah isi commit (misalnya mengubah kode atau pesan commit secara mendalam) sebelum kamu lanjut ke commit berikutnya."

Ini berguna kalau kamu sadar ada kesalahan di commit yang sudah lama, dan kamu perlu memperbaikinya tanpa membuat commit baru.

5. drop (d)

Artinya: "Hapus commit ini sepenuhnya dari sejarah."

Gunakan ini jika kamu melakukan commit berisi file besar yang tidak sengaja ter-commit, atau commit yang benar-benar tidak relevan.

---

Studi Kasus Praktis: Mengubah Sampah Menjadi Emas

Bayangkan daftar commit kamu seperti ini (diurutkan dari lama ke baru):

pick 111a Initial setup
pick 222b feat: buat fitur A
pick 333c fix: benerin bug kecil di fitur A
pick 444d docs: nambahin komen
pick 555e fix: benerin lagi bug kecil di fitur A (lupa tadi)

Kamu ingin mengubahnya menjadi dua commit bersih: Initial setup dan feat: fitur A sudah sempurna.

Langkah 1: Mengedit Script rebase -i HEAD~5

Kamu buka editor, dan ubah seperti ini:

pick 111a Initial setup
pick 222b feat: buat fitur A
fixup 333c fix: benerin bug kecil di fitur A  <-- fixup ke 222b
squash 444d docs: nambahin komen             <-- squash ke 222b
fixup 555e fix: benerin lagi bug kecil di fitur A (lupa tadi) <-- fixup ke 222b

(Catatan: Semua aksi selain pick akan digabungkan ke pick terdekat di atasnya. squash memberi kamu kesempatan untuk edit, fixup langsung gabung tanpa tanya)

Langkah 2: Menjalankan Rebase

Setelah kamu simpan dan tutup editor, Git akan mulai bekerja.

  1. Git akan menggabungkan semua fixup (333c dan 555e) ke commit 222b tanpa bertanya.
  2. Karena kamu menggunakan squash di 444d, Git akan membuka editor lagi dan meminta kamu menggabungkan pesan commit dari 222b dan 444d.

Langkah 3: Mengedit Pesan Commit Gabungan (hanya jika ada squash)

Editor akan muncul dengan pesan seperti ini:

# This is a combination of 3 commits.
The first commit message will be the new one:
feat: buat fitur APlease enter the commit message for your changes. Lines starting
with '#' will be ignored, and an empty message aborts the commit.

Kamu hapus baris yang tidak perlu, dan buat pesan commit baru yang super jelas:

feat: Mengimplementasikan Fitur A secara lengkap

Langkah 4: Selesai

Setelah kamu simpan, proses rebase selesai. Sekarang, history kamu hanya berisi dua commit yang bersih, logis, dan profesional:

  1. Initial setup
  2. feat: Mengimplementasikan Fitur A secara lengkap

Jauh lebih rapi, bukan? Inilah standar kualitas yang dipegang oleh developer profesional, termasuk yang bekerja di bawah naungan Javapixa Creative Studio.

---

Trik Level Lanjut: Mengedit Commit di Tengah Sejarah (edit)

Terkadang, kamu sadar ada kesalahan kecil (misalnya, kamu lupa menjalankan formatter kode atau salah menulis nama variabel) di commit nomor tiga, padahal kamu sudah punya sepuluh commit setelahnya. Kalau kamu cuma fixup seperti biasa, perbaikannya akan menempel di commit paling baru, bukan di commit yang bermasalah.

Di sinilah edit berguna.

  1. Panggil rebase -i dan ubah pick pada commit yang ingin diperbaiki menjadi edit.

pick 111a Initial setup
    edit 222b feat: fitur A (salah variabel di sini)
    pick 333c feat: fitur B
    ...
  1. Jalankan Rebase. Git akan berhenti setelah memproses 111a dan menampilkan pesan:
Stopped at 222b... feat: fitur A
    You can amend the commit now...
  1. Lakukan Perbaikan. Kamu bebas mengubah kode. Setelah selesai, stage perubahannya:
bash
    # Lakukan perubahan kode
    git add .
    # Ambil perubahan tersebut dan masukkan ke commit 222b
    git commit --amend --no-edit

Opsi --no-edit penting di sini, karena kita hanya ingin mengubah isi kode di commit itu, tanpa mengubah pesan commit yang sudah ada.

  1. Lanjutkan Rebase. Setelah amend selesai, beritahu Git untuk melanjutkan prosesnya:
bash
    git rebase --continue

Git akan melanjutkan memproses commit 333c dan seterusnya. Sekarang, commit 222b sudah diperbaiki, dan sejarah terlihat rapi seolah-olah kesalahan itu tidak pernah terjadi.

---

Aturan Emas: Jangan Rebase Sejarah yang Sudah Dishare!

Ini adalah bagian terpenting dari etika penggunaan rebase -i.

JANGAN PERNAH menggunakan git rebase pada branch atau commit yang sudah kamu push ke remote (GitHub, GitLab) dan sudah ditarik (pulled) oleh rekan tim kamu.

Kenapa? Karena rebase membuat commit baru dengan SHA ID yang berbeda. Jika kamu rebase sejarah yang sudah di-share, kamu menghapus sejarah lama di remote dan menggantinya dengan sejarah baru.

Ketika rekan tim kamu mencoba pull atau push, Git akan kebingungan (karena ada dua versi sejarah yang berbeda) dan meminta mereka melakukan merge, yang akan menimbulkan konflik besar dan kekacauan.

rebase -i hanya boleh digunakan pada branch lokal dan privat kamu (misalnya, branch fitur sebelum di-PR).

Jika Terpaksa Melakukan Rebase pada Shared History

Dalam kasus yang sangat jarang dan genting (misalnya, kamu push ke branch fitur pribadi tapi tidak ada yang pull), kamu harus menggunakan force push:

bash
git push --force-with-lease

Penting: Selalu gunakan --force-with-lease bukan --force. Opsi --force-with-lease akan memastikan kamu tidak menimpa pekerjaan orang lain yang mungkin baru saja mereka push sebelum kamu. Ini adalah best practice yang sangat penting dalam pengembangan tim profesional.

---

Penutup: Upgrade Diri Jadi Developer Profesional

Menguasai git rebase -i bukan hanya soal skill teknis, tapi soal kedisiplinan dan profesionalisme. Developer yang baik tidak hanya menulis kode yang berfungsi, tetapi juga meninggalkan jejak (history Git) yang mudah dibaca, dipelihara, dan diverifikasi.

Jika kamu bercita-cita membangun produk digital berkualitas tinggi, baik itu website canggih, aplikasi mobile yang responsif, atau sistem backend yang kuat—standar ini tidak bisa ditawar. Javapixa Creative Studio, misalnya, selalu menekankan bahwa hasil akhir yang bersih dimulai dari proses pengembangan yang disiplin, dan itu termasuk memiliki commit history yang layak dicetak.

Jadi, mulai hari ini, sebelum kamu klik tombol Push atau Submit Pull Request, luangkan waktu 5 menit untuk menjalankan git rebase -i. Ubah semua fixup, typo, dan WIP menjadi commit logis yang menggambarkan alur kerja yang cerdas.

Jadikan commit kamu sebagai dokumentasi yang menceritakan sebuah kisah, bukan sekadar buku harian harian berisi keluhan dan perbaikan kecil. Clean history = professional developer. Sekarang, waktunya kamu praktik!