Split Commit Git Biar Rapi Caranya Gini Loh

Photo by Avery Meeker/Unsplash

Buat kamu yang lagi belajar atau udah sering ngoding, pasti nggak asing lagi sama Git. Git itu kayak mesin waktu pribadi buat proyek codingmu, ngerekam setiap perubahan yang kamu bikin. Nah, biar "mesin waktu" ini rapi dan nggak bikin pusing pas dibuka lagi, salah satu skill penting yang perlu dikuasai adalah bikin commit yang bersih.

Sering kan kejadian pas lagi ngoding, eh keterusan nambahin fitur baru, benerin bug yang nggak sengaja ketemu, sama sekalian ngerapiin code (refactoring) dalam satu sesi kerja? Terus pas mau commit, males misah-misahinnya, akhirnya semua dimasukin ke satu commit gede. Pesan commit-nya? Mungkin cuma "Update".

Nah, ini yang sering bikin repot nanti. Commit yang isinya campur aduk kayak gini tuh kayak laci yang semua isinya (kaos kaki, pulpen, charger, bon belanja) ditumpuk jadi satu. Pas butuh kaos kaki doang, nyarinya susah. Sama kayak di Git, pas kamu butuh ngeliat perubahan spesifik, nge-debug, atau mau balik ke versi sebelum ada perubahan tertentu, commit yang campur aduk bikin kerjaan nambah ribet.

Di sinilah pentingnya split commit atau memecah commit yang terlalu besar dan campur aduk jadi commit-commit yang lebih kecil dan logis. Setiap commit idealnya itu mewakili satu unit kerja yang utuh dan terpisah. Misalnya, satu commit buat nambahin fitur login, satu commit lagi buat benerin bug di fitur pembayaran, satu commit lagi buat ngerapiin struktur folder.

Kenapa sih Harus Repot-repot Split Commit?

Mungkin kedengarannya kayak kerjaan tambahan, ya? Tapi percayalah, investasimu buat bikin history Git yang rapi itu manfaatnya banyak banget lho:

Code Review Jadi Gampang: Bayangin kamu lagi nge-review kerjaan temen atau kerjaanmu sendiri bulan lalu. Kalau commit-nya kecil-kecil dan fokus, kamu bisa langsung liat perubahan apa yang dia bikin buat fitur A, apa yang buat fitur B. Nggak perlu pusing nyari di antara ratusan baris kode yang berubah dalam satu commit gede. Reviewer (atau kamu sendiri di masa depan) bakal lebih cepet paham dan kasih feedback yang relevan.
Debugging Lebih Mudah: Pernah nemu bug terus nggak tahu kapan bug itu mulai muncul? Fitur Git namanya git bisect bisa bantu nyari commit mana yang bikin bug. Kalau commit-mu gede dan isinya macam-macam, git bisect mungkin nunjuk ke commit yang bikin bug, tapi kamu tetep harus nyari di dalam commit itu, perubahan mana sebetulnya yang biang keroknya. Dengan commit yang kecil, begitu git bisect nunjuk satu commit, kemungkinan besar bugnya langsung ada di perubahan commit itu doang.
Rollback atau Revert Jadi Aman: Kalau ternyata satu fitur yang kamu tambahin di commit itu malah bikin masalah, kamu bisa dengan gampang nge-revert commit itu aja tanpa mempengaruhi perubahan lain yang nggak ada hubungannya (misalnya, benerin typo atau nambahin komen). Kalau commit-nya campur aduk, nge-revert satu commit bisa jadi malah ngerusak banyak hal yang nggak kamu niatin.
History Git Jadi 'Cerita' yang Jelas: Log Git itu harusnya kayak buku harian proyekmu. Setiap commit adalah entri yang jelas tentang apa yang terjadi. Kalau commit-nya rapi, siapa pun yang lihat log-mu (termasuk kamu nanti) bisa ngerti evolusi proyeknya, kenapa perubahan itu dibikin, dan kapan. Ini profesional banget!
Pake git blame Lebih Efektif: Kalau kamu nemu baris kode yang aneh atau bikin bug, kamu bisa pake git blame buat liat commit mana yang terakhir ngubah baris itu dan siapa yang ngerjain. Kalau commit-nya campur aduk, git blame mungkin nunjuk ke commit gede dengan pesan "Update", dan kamu tetep nggak tahu kenapa perubahan itu dibikin atau konteksnya apa. Kalau commit-nya rapi dengan pesan yang jelas, git blame akan sangat membantu investigasi.

Oke, Udah Paham Pentingnya. Terus Gimana Caranya Split Commit yang Udah Terlanjur Gede?

Git punya alat canggih buat ini, namanya git rebase --interactive atau disingkat git rebase -i. Ini kayak 'mesin waktu' Git yang lebih canggih lagi, yang ngasih kamu kekuatan buat ngedit history commit (dengan hati-hati ya, terutama kalau branch-mu udah di-push dan dipake orang lain!).

Langkah-langkah buat split commit pake git rebase -i itu gini nih:

Langkah 1: Tentukan Commit Mana yang Mau Di-Split

Pertama, kamu harus tahu commit mana yang mau kamu pecah. Kamu bisa liat history commit-mu pake command:

bash
git log --oneline

Kamu bakal liat daftar commit yang ringkas, misalnya gini:

abcdef1 Pesan commit terbaru
fedcba9 Commit yang mau di-split
1234567 Commit sebelumnya
...

Misalnya kamu mau split commit dengan hash fedcba9. Commit ini letaknya 2 commit sebelum HEAD (commit yang paling baru).

Langkah 2: Mulai Interactive Rebase

Sekarang kita panggil si git rebase -i. Kamu perlu kasih tahu Git seberapa jauh ke belakang kamu mau ngedit history. Kalau commit yang mau kamu split itu 2 commit sebelum HEAD, kamu bisa panggil:

bash
git rebase -i HEAD~2

Angka 2 di sini maksudnya, "rebase secara interaktif mulai dari 2 commit sebelum commit yang sekarang kamu injak (HEAD)". Kalau commit yang mau di-split itu 5 commit lalu, ya panggilnya HEAD~5.

Setelah kamu jalanin command itu, Git akan ngebuka editor teks default-mu (biasanya Vim, Nano, atau VS Code kalau udah diatur) dan nampilin daftar commit yang akan di-rebase, dari yang paling lama di atas sampe yang paling baru di bawah (yang paling deket ke HEAD):

pick 1234567 Commit sebelumnya
pick fedcba9 Commit yang mau di-splitRebase 1234567..abcdef1 onto 1234567 (2 commands)
# Commands:
p, pick  = use commit
r, reword  = use commit, but edit the commit message
e, edit  = use commit, but stop for amending
s, squash  = use commit, but meld into previous commit
f, fixup  = like "squash", but discard this commit's log message
x, exec  = run command (the rest of the line) using shell
d, drop  = remove commit
# These lines can be re-ordered; they are executed from top to bottom.
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Langkah 3: Ubah pick Jadi edit (atau e)

Di file editor itu, cari baris yang mewakili commit yang mau kamu split (pick fedcba9 Commit yang mau di-split). Ubah kata pick di depan hash commit itu jadi edit atau e.

pick 1234567 Commit sebelumnya
edit fedcba9 Commit yang mau di-splitRebase 1234567..abcdef1 onto 1234567 (2 commands)

Simpan perubahan di editor dan tutup editornya.

Langkah 4: Git Berhenti di Commit yang Ditarget

Git sekarang bakal mulai proses rebase. Begitu sampai di commit yang kamu tandai edit, Git akan berhenti dan ngasih tahu kamu lewat terminal:

Stopped at fedcba9... Commit yang mau di-split
You can amend the commit now, or run:

Ini artinya, Git sekarang nge-pause proses rebase, dan working directory serta staging area kamu isinya sama persis kayak setelah commit fedcba9 itu dibuat. Tapi commit fedcba9 itu sendiri belum diaplikasikan secara permanen di proses rebase baru ini.

Langkah 5: 'Un-commit' Perubahan

Saatnya kita bongkar isi commit fedcba9 itu. Kita mau ngembaliin semua perubahan dari commit itu ke status 'unstaged', seolah-olah kamu baru aja selesai ngoding tapi belum nambahin apa-apa ke staging area.

Command buat ngelakuin ini adalah git reset HEAD^.

bash
git reset HEAD^

Penjelasan singkat: HEAD^ itu ngacu ke commit sebelum commit yang lagi kamu injak sekarang (yaitu, commit fedcba9 itu). git reset (dengan mode default --mixed) akan:

Mindahin HEAD pointer ke commit yang dituju (HEAD^).
Ngereset staging area (index) biar isinya sama kayak commit HEAD^.

Tapi, ngebiarin perubahan di working directory* kamu apa adanya (yaitu, perubahan dari commit fedcba9 tetap ada di file-filemu, tapi statusnya 'unstaged').

Setelah jalanin git reset HEAD^, kalau kamu cek git status, kamu bakal liat semua perubahan yang tadinya ada di commit fedcba9 sekarang muncul sebagai "Changes not staged for commit".

Langkah 6: Stage dan Commit Perubahan Secara Bertahap

Nah, ini bagian serunya. Sekarang kamu bisa milih bagian-bagian perubahan dari working directory-mu buat dibikin commit baru yang lebih kecil dan fokus.

Cara paling canggih buat milih bagian perubahan per file atau bahkan per baris itu pake git add --patch atau disingkat git add -p.

bash
git add -p

Git akan nampilin "hunks" (blok-blok perubahan) satu per satu dan nanya kamu mau ngapain:

diff --git a/path/to/file.js b/path/to/file.js
index abcdef..fedcba 100644
--- a/path/to/file.js
+++ b/path/to/file.js
@@ -10,6 +10,8 @@
 console.log('Kode lama');
 +console.log('Ini fitur A'); // Perubahan fitur A
 +console.log('Ini fix bug X'); // Perubahan fix bug X
  console.log('Kode lain');

Pilihan-pilihan yang sering dipake:

y: Ya, stage hunk ini.
n: Tidak, jangan stage hunk ini.
q: Keluar dari git add -p tanpa nge-stage hunk-hunk berikutnya.
a: Ya, stage hunk ini dan semua hunk lainnya di file yang sama.
d: Tidak, jangan stage hunk ini dan semua hunk lainnya di file yang sama.
s: Split hunk ini jadi hunk-hunk yang lebih kecil (ini berguna kalau satu hunk berisi perubahan-perubahan yang beda logikanya).
e: Edit hunk ini secara manual (kamu bisa hapus baris + atau - di editor buat milih persis baris mana yang mau di-stage).
?: Nampilin help.

Pake y, s, atau e buat milih perubahan mana aja yang jadi bagian dari commit pertama yang mau kamu bikin. Stage perubahan-perubahan yang masuk akal kalau digabung dalam satu commit (misalnya, semua perubahan terkait 'Fitur A').

Setelah kamu selesai milih dan nge-stage bagian pertama, cek lagi pake git status buat mastiin perubahan mana aja yang udah di-stage.

Kalau udah yakin, bikin commit pertama dari hasil split-an ini:

bash
git commit -m "feat: Menambahkan bagian Fitur A"

Nah, sekarang kamu punya commit baru yang isinya hanya perubahan buat 'Fitur A'.

Langkah 7: Ulangi Sampai Semua Perubahan Ter-commit

Setelah commit pertama selesai, masih ada sisa perubahan dari commit asli yang belum di-stage/commit kan? Cek git status lagi. Perubahan-perubahan itu sekarang masih di "Changes not staged for commit".

Ulangi Langkah 6:

Jalanin git add -p lagi.
Pilih bagian perubahan berikutnya yang mau kamu bikin commit terpisah (misalnya, semua perubahan terkait 'Fix Bug X').
Commit perubahan tersebut dengan pesan yang sesuai: git commit -m "fix: Memperbaiki Bug X"

Lakukan ini terus-menerus sampai semua perubahan dari commit asli (fedcba9) habis dan udah jadi commit-commit baru yang lebih kecil. git status harusnya udah bersih (atau tinggal sisa file yang memang nggak mau kamu commit).

Langkah 8: Lanjutin Proses Rebase

Setelah kamu yakin semua perubahan dari commit fedcba9 udah berhasil di-split jadi commit-commit baru, saatnya nyuruh Git ngelanjutin proses rebase.

bash
git rebase --continue

Git akan ngasih tahu kalau dia udah selesai berhenti di commit itu dan bakal lanjutin rebase commit-commit berikutnya yang mungkin ada di daftar rebase-mu (kalau kamu tandai lebih dari satu commit pake edit, dia bakal berhenti di commit edit berikutnya). Kalau nggak ada lagi, rebase bakal selesai.

Penting: Hati-hati Saat Split Commit di Branch yang Udah Di-Push!

Proses git rebase -i itu mengubah history commit. Commit yang lama (fedcba9) itu dihapus dan diganti dengan commit-commit baru yang kamu bikin hasil split-an tadi.

Kalau branch tempat kamu ngelakuin rebase ini belum pernah di-push ke remote repository (misalnya GitHub, GitLab, Bitbucket), ini aman-aman aja. Nggak ada yang terpengaruh.

Tapi kalau branch ini sudah kamu push dan mungkin udah di-clone atau di-pull sama temen-temen setimmu, mengubah history kayak gini bisa bikin masalah. Commit-commit yang baru itu secara teknis berbeda dari commit-commit yang lama, meskipun isinya mirip. Git di komputermu dan di remote repository jadi beda.

Untuk meng-update remote repository setelah ngelakuin rebase yang mengubah history, kamu harus pake git push --force atau git push --force-with-lease.

bash
git push --force

ATAU

bash
git push --force-with-lease

--force itu kayak, "Pokoknya timpa aja history di remote sama history di komputermu, nggak peduli apa yang ada di sana." Ini berbahaya kalau ada orang lain yang udah nambahin commit baru ke branch yang sama di remote sebelum kamu push force. Commit mereka bakal hilang.--force-with-lease lebih aman karena dia cuma akan nge-force push kalau history di remote belum berubah sejak terakhir kali kamu pull/fetch. Kalau udah ada perubahan di remote, push-mu bakal gagal dan ngasih tahu kamu buat ngecek dulu. Ini lebih disarankan.

Aturan Emas: Hindari nge-rebase (termasuk split commit pake rebase) di branch main, master, atau branch penting lainnya yang dipake banyak orang, kecuali kamu bener-bener tahu apa yang kamu lakuin dan udah koordinasi sama tim. Paling aman itu nge-rebase branch yang cuma kamu pake (misalnya feature branch pribadi) sebelum di-merge atau di-push ke branch utama.

Tips Tambahan Biar Commitmu Rapi Dari Awal

Daripada sibuk split commit yang udah terlanjur gede, mendingan biasain bikin commit yang rapi dari awal. Gimana caranya?

Commit Sering Tapi Kecil: Begitu kamu selesai nambahin sedikit code yang mewakili satu unit kerja logis (misalnya, nambahin tombol, nambahin validasi input, ngerapihin satu fungsi), langsung commit. Jangan tunda sampe banyak perubahan numpuk.
Gunakan git status Secara Rutin: Sering-sering cek git status buat ngeliat perubahan apa aja yang udah kamu bikin. Ini bantu kamu ngerti kondisi working directory-mu.
Gunakan git add -p Untuk Nge-stage: Bahkan saat bikin commit pertama kali, biasain pake git add -p atau git add. Jangan pake git add . kalau kamu nggak yakin semua perubahan di semua file mau kamu masukin ke commit yang sama. Dengan git add -p, kamu bisa milih hunk-hunk mana yang mau di-stage buat commit pertama, terus sisanya bisa di-commit terpisah nanti. Ini cara proaktif buat nge-split kerjaanmu jadi commit-commit logis sebelum commit.
Pesan Commit yang Jelas dan Deskriptif: Jangan cuma nulis "update" atau "fix". Tulis pesan commit yang nyeritain apa yang kamu ubah dan kenapa. Format commit message yang umum itu: Baris pertama ringkasan (maks 50 karakter), baris kosong, lalu penjelasan detail kalau perlu. Contoh: feat: Menambahkan validasi email di form register.
Review Kerjaanmu Sebelum Commit: Sebelum ngetik git commit, liat lagi perubahan yang udah kamu stage pake git diff --staged. Pastiin isinya beneran cuma perubahan yang terkait sama satu unit kerja yang mau kamu commit.

Kesimpulan

Nge-split commit yang udah terlanjur campur aduk itu skill penting buat ngejaga history Git tetap rapi dan gampang dibaca. Alat utamanya adalah git rebase -i yang dikombinasikan sama git reset HEAD^, git add -p, dan git commit. Proses ini mungkin butuh latihan, terutama kalau kamu belum terbiasa sama interactive rebase dan git add -p.

Meskipun bisa dilakuin, cara terbaik tetep dengan membiasakan diri bikin commit yang kecil dan logis dari awal, mungkin dengan bantuan git add -p secara proaktif. History Git yang bersih bukan cuma soal estetika, tapi ngebantu banget dalam kolaborasi, debugging, dan ngertiin proyek dalam jangka panjang. Jadi, yuk mulai biasain bikin commit yang rapi biar kerjaan coding makin lancar!