Agen coding AI sangat bagus menulis kode dan sangat buruk melakukan commit. Minta agen untuk commit dua perubahan secara terpisah, dan ia tidak bisa melakukan apa yang dilakukan manusia secara naluriah: membuka prompt interaktif, memilih beberapa hunk, dan membiarkan sisanya. Perkakas interaktif git mengasumsikan ada orang yang duduk di keyboard, dan agen bukan orang. Git-surgeon memperbaiki ketidakcocokan itu. Ia adalah CLI open source yang memberi agen AI kendali bedah atas perubahan git tanpa prompt interaktif, dan per 26 Oktober 2026, repo raine/git-surgeon memiliki 186 bintang dan 7 fork di GitHub dengan lisensi MIT.
Poin Penting
>
Git-surgeon menggantikan prompt interaktif git dengan perintah non-interaktif yang bisa dijalankan agen AI dengan aman: daftar hunk, stage, commit, atau buang hunk berdasarkan ID.
Setiap hunk mendapat ID 7 karakter yang stabil, diturunkan dari path file dan isi hunk, sehingga agen bisa merujuk perubahan secara presisi, bukan menebak nama file.
Ia bisa memecah commit yang mencampur banyak hal, melipat perbaikan ke commit lama, mengubah atau menyusun ulang commit, dan commit ke branch lain tanpa checkout.
Instalasinya hanya satu perintah lewat skrip shell, Cargo, atau Homebrew, ditambah skill agen untuk Claude Code, OpenCode, atau Codex.
Batas yang jujur: penulisan ulang riwayat tetap memakai rebase di balik layar, jadi konflik tetap butuh manusia, dan
discardmenghapus perubahan yang belum di-commit secara permanen.Ia adalah perkakas kecil dan fokus, bukan pengganti git, dan fokus itulah yang membuatnya bekerja untuk agen.
Masalahnya: agen tidak bisa memakai git add -p
Masalah intinya sederhana, dan README git-surgeon menyatakannya dengan jelas. Agen AI tidak bisa memakai perintah git interaktif seperti git add -p (README git-surgeon). Saat diminta commit perubahan secara terpisah, agen tidak punya langkah yang bagus. Ia bisa commit semuanya sekaligus, menghasilkan commit berantakan yang mencampur perubahan tak terkait, atau mencoba jalan pintas yang merusak, seperti reset dan checkout file, yang berisiko menghancurkan pekerjaan. README menunjukkan persis kegagalan itu: agen yang hampir menjalankan git checkout pada sebuah file untuk memisahkan dua perubahan, perintah yang akan membuang perubahan yang justru sedang coba ia rapikan.
Ini bukan kasus pinggiran. Agen rutin menyentuh banyak file dalam satu sesi: fitur di sini, sedikit logging di sana, perbaikan format di tempat lain. Manusia meninjau diff, memilih hunk, dan menulis commit yang fokus. Agen yang hanya bisa commit per file utuh berakhir dengan commit berjudul "berbagai perubahan" atau, lebih buruk, riwayat yang tidak bisa ditinjau siapa pun. Riwayat yang bersih bukan kosmetik. Riwayat adalah cara reviewer memahami apa yang berubah, cara bisect menemukan regresi, dan cara revert tetap aman. Saat agen menulis sebagian besar kode, langkah commit menjadi penghambat keterbacaan.
Tonton sinyal repo 30 detik: Fix messy AI commits with git surgeon.
Apa sebenarnya git-surgeon itu
Git-surgeon adalah CLI Rust yang dibangun di atas satu ide: beri setiap hunk ID yang stabil, lalu biarkan agen beroperasi pada ID tersebut. Hunk adalah blok baris berubah yang berurutan dalam sebuah diff. Jalankan git-surgeon hunks dan Anda mendapat daftar seperti ac34353 internal/bot/listing_handler.go (+6 -3), satu baris per hunk, dengan file, konteks fungsi, dan jumlah baris yang ditambah dan dihapus. Dari sana, agen bisa memeriksa, stage, commit, atau membuang tepat hunk itu.
ID adalah bagian yang cerdas. Setiap ID adalah string hex 7 karakter yang diturunkan dari hash SHA-1 atas path file dan isi hunk, yaitu baris yang ditambah, dihapus, dan konteks, bukan header diff. Itu membuat ID stabil saat baris bergeser di atas hunk, dan deterministik, sehingga isi yang sama selalu menghasilkan ID yang sama. Jika dua hunk identik bertabrakan, hunk berikutnya mendapat akhiran -2 atau -3. Agen karena itu bisa berkata "commit ac34353 dan 15baf94" dan maksudnya presisi, bukan mendeskripsikan perubahan dengan prosa dan berharap perkakas menafsirkannya dengan benar.
Perkakas ini dikirim sebagai satu binary, bisa dipasang lewat tiga cara: skrip install shell, cargo install git-surgeon, atau Homebrew lewat brew install raine/git-surgeon/git-surgeon. Ia juga memasang skill agen untuk Claude Code, OpenCode, atau Codex, sehingga agen mempelajari perintahnya dan memakainya sendiri. Syaratnya sederhana: Git 2.0 atau lebih baru, plus Rust hanya jika Anda membangun dari source.
Perintahnya, dalam bahasa sederhana
Perintah git-surgeon terbagi ke empat kelompok yang mencerminkan alur kerja git normal.
Kelompok | Perintah | Yang bisa dilakukan agen |
|---|---|---|
Periksa | hunks, show | Daftar hunk dengan ID, atau tampilkan diff lengkap satu hunk dengan nomor baris |
Stage dan commit | stage, commit, commit-to, unstage, discard | Stage hunk berdasarkan ID, commit dalam satu langkah, commit ke branch lain tanpa checkout, unstage, atau discard |
Tulis ulang riwayat | fold, amend, squash, reword, split, move, undo | Lipat commit ke commit lama, gabungkan rentang, ubah pesan, pecah commit campuran, susun ulang commit, atau terapkan balik hunk |
Perawatan | update | Perbarui ke rilis terbaru, dengan pemeriksaan checksum SHA-256 |
Perintah periksa adalah fondasinya. hunks mendaftar hunk yang belum di-stage secara default, dengan flag untuk hunk yang sudah di-stage, satu file, atau hunk dari commit tertentu, plus mode --blame yang menunjukkan commit mana yang memperkenalkan tiap baris dan mode --full untuk diff lengkap. show mencetak satu hunk dengan nomor baris berbasis 1, yang penting karena langkah berikutnya sering butuh rentang baris: stage a1b2c3d --lines 5-30 hanya men-stage sebagian hunk, untuk kasus ketika git mengelompokkan dua perubahan tak terkait ke satu hunk.
Perintah commit adalah tempat perkakas ini membuktikan namanya. commit men-stage hunk yang disebut dan melakukan commit dalam satu langkah, dan jika commit gagal, ia mengembalikan hunk ke keadaan semula. Ia menolak berjalan jika index sudah berisi perubahan yang di-stage, yang mencegah kebingungan setengah stage. commit-to melangkah lebih jauh: ia melakukan commit hunk langsung ke branch lain tanpa checkout, memakai git plumbing, yang berguna dalam setup worktree ketika branch target sedang di-checkout di tempat lain. Jika patch tidak bisa diterapkan dengan bersih, ia gagal tanpa mengubah apa pun.
Perintah riwayat menangani bersih-bersih yang biasanya dilewati agen. split memecah commit yang mencampur banyak hal menjadi commit yang fokus, bahkan secara retroaktif, memakai kelompok --pick berisi ID hunk dengan pesan dan --rest-message opsional untuk sisanya. fold menggabungkan commit yang ada ke commit lama, sementara amend melipat perubahan yang di-stage ke commit lama. squash menggabungkan rentang menjadi satu commit, reword mengubah pesan tanpa menyentuh isi, move menyusun ulang posisi commit, dan undo menerapkan balik hunk terpilih dari commit sebelumnya ke working tree.
Alur kerja agen yang tipikal
Alur kerja tipikal dari README cukup singkat untuk diringkas: agen membuat perubahan di banyak file, menjalankan git-surgeon hunks untuk meninjau, melakukan commit hunk untuk fitur A dengan satu perintah, lalu commit sisanya untuk fitur B. Itulah seluruh loop, dan ia menggantikan satu paragraf penalaran agen dengan tiga perintah.
Contoh yang lebih realistis dari README menunjukkan mengapa rentang baris penting. Sebuah file punya dua perubahan yang dikelompokkan ke satu hunk: pagination untuk satu fungsi dan filter soft-delete untuk fungsi lain. Agen menjalankan show untuk melihat nomor baris, men-stage hanya baris 1-11 untuk pagination, melakukan commit itu, lalu commit sisanya secara terpisah. Tanpa kendali level baris, kedua perubahan itu akan tetap dalam satu commit selamanya, karena tidak ada operasi level hunk utuh yang bisa memisahkannya.
Kasus retroaktif sama bergunanya. Agen melakukan commit dua perubahan tak terkait sekaligus, manusia memintanya dipisah setelah kejadian, dan split HEAD dengan kelompok --pick dan --rest-message menghasilkan dua commit bersih. Inilah alur kerja yang membuat riwayat buatan agen bisa ditinjau setelah kejadian, bukan hanya saat commit, dan inilah yang paling mungkin menyelamatkan code review nyata.
Git-surgeon versus git biasa
Penting untuk jelas soal apa yang bukan git-surgeon. Ia bukan pengganti git, layanan hosting, atau sistem version control baru. Setiap operasi berjalan lewat git sendiri, dan penulisan ulang riwayat memakai rebase secara internal. Tabel di bawah menjaga perbandingan tetap jujur.
Aspek | Git biasa untuk agen | Git-surgeon |
|---|---|---|
Staging interaktif |
| ID hunk non-interaktif yang bisa dilewatkan agen sebagai argumen |
Commit parsial | Per file utuh, atau jalan pintas reset dan checkout yang berisiko | Hunk, atau rentang baris di dalam hunk |
Memecah commit campuran | Rebase interaktif manual |
|
Melipat perbaikan ke commit lama | Rebase manual atau amend dengan hati-hati | Perintah |
Commit ke branch lain | Checkout, commit, kembali |
|
Pengaman | Sedikit, secara default | Menolak saat index kotor, mengembalikan keadaan saat commit gagal |
Yang tidak bisa dilakukan | N/A | Menyelesaikan konflik rebase untuk Anda, atau membatalkan |
Pengaman layak ditekankan. Perkakas yang membiarkan agen menulis ulang riwayat harus gagal dengan aman, dan git-surgeon melakukannya: ia menolak saat index berisi perubahan yang di-stage, ia menyimpan sementara working tree yang kotor selama rebase dan mengembalikannya, dan ia gagal tanpa mengubah apa pun saat patch tidak bisa diterapkan ke branch lain. Itulah perilaku yang membuatnya aman diserahkan ke agen otonom, dan mudah terlewat dalam daftar fitur.
Peringatan yang jujur
Tiga batas layak diketahui sebelum Anda menyerahkan ini ke agen.
Pertama, konflik rebase tetap butuh manusia. Saat fold, split, move, atau amend menemui konflik, repo dibiarkan dalam keadaan konflik untuk diselesaikan manual dengan git rebase --continue atau git rebase --abort. Git-surgeon membuat bedah riwayat bisa diskrip, bukan bebas konflik, dan agen yang menulis ulang riwayat bersama masih bisa membuat kekacauan yang hanya bisa dibereskan manusia. Jangan biarkan agen menulis ulang commit yang sudah ditarik orang lain.
Kedua, discard bersifat permanen. Ia menerapkan balik hunk ke working tree, yang merupakan padanan non-interaktif dari git checkout -p, dan README memperingatkan bahwa ia menghapus permanen perubahan yang belum di-commit itu. Itu perilaku yang benar untuk perintah discard, tapi artinya agen dengan akses discard bisa menghapus pekerjaan. Batasi izin agen, atau setidaknya tinjau panggilan discard-nya, seperti Anda meninjau perintah merusak lainnya.
Ketiga, proyek ini muda dan kecil. Ia dibuat pada Januari 2026, punya 99 commit dan 18 rilis, dan 186 bintang terbilang sederhana dibanding puluhan ribu di balik perkakas git mapan. Itu wajar untuk perkakas agen yang khusus, dan lisensi MIT plus basis kode Rust yang kecil membuatnya mudah diaudit, tapi artinya komunitasnya kecil dan perawatan jangka panjangnya bergantung pada satu penulis dan segelintir kontributor. Coba dulu di repo percobaan, dan jaga keterampilan git normal Anda tetap tajam, karena git-surgeon adalah lapisan di atas git, bukan pengganti pemahaman git.
Mengapa repo ini penting
Git-surgeon penting karena ia memperlakukan masalah nyata dan terus tumbuh sebagai masalah perkakas, bukan masalah prompting. Memberi tahu agen "buat commit yang bersih" dalam system prompt tidak berhasil saat agen secara harfiah tidak punya cara non-interaktif untuk men-stage setengah file. Memberinya ID hunk, rentang baris, dan perintah commit satu langkah berhasil, karena ia mengubah instruksi samar menjadi operasi konkret dengan hasil yang bisa diprediksi.
Ia juga cocok dengan pergeseran yang lebih luas. Saat agen menulis lebih banyak kode, penghambat bergeser dari menulis ke meninjau, dan riwayat yang bisa ditinjau menjadi infrastruktur, bukan kebersihan. Perkakas yang membuat keluaran agen bisa ditinjau, entah itu commit level hunk di sini atau isolasi worktree di tempat lain, adalah perkakas yang memungkinkan tim benar-benar menggabungkan pekerjaan agen dalam skala besar. Jika Anda sudah menjalankan agen coding dan riwayat commit Anda terbaca seperti draf kasar, git-surgeon adalah instalasi kecil dengan hasil langsung: jalankan hunks, pilih ID-nya, dan biarkan agen commit seperti manusia yang teliti.
Repo ini layak dibaca selengkapnya, terutama bagian contohnya: raine/git-surgeon.
Baca artikel ini dalam bahasa Inggris: Git-Surgeon: Give Your AI Coding Agent Surgical Control Over Git History.
Jika Anda baru dalam version control itu sendiri, postingan Git Dijelaskan kami membahas cara kerja commit, branch, dan riwayat sebelum Anda menyerahkannya ke agen.
FAQ
Apa itu git-surgeon?
Ia adalah CLI Rust open source di github.com/raine/git-surgeon yang memberi agen coding AI kendali non-interaktif atas perubahan git: daftar, stage, commit, pecah, lipat, dan buang hunk berdasarkan ID yang stabil, tanpa prompt interaktif.
Mengapa agen tidak bisa memakai git add -p saja?
Karena git add -p bersifat interaktif: ia mengajukan pertanyaan di prompt dan menunggu manusia menjawab. Agen tidak bisa menjawab prompt itu, sehingga ia commit semuanya sekaligus atau memakai jalan pintas merusak seperti reset dan checkout file.
Bagaimana cara kerja ID hunk?
Setiap ID adalah string hex 7 karakter yang diturunkan dari hash SHA-1 atas path file dan isi hunk, tanpa header diff. ID tetap stabil saat baris bergeser di atas hunk, isi yang sama selalu memberi ID yang sama, dan tabrakan mendapat akhiran -2 atau -3.
Bagaimana cara memasang git-surgeon?
Pakai skrip install shell dari README, cargo install git-surgeon, atau Homebrew dengan brew install raine/git-surgeon/git-surgeon. Lalu pasang skill agen dengan git-surgeon install-skill --claude, --opencode, atau --codex.
Bisakah git-surgeon memecah commit yang sudah ada?
Ya. git-surgeon split memecah commit yang ada menjadi beberapa commit memakai kelompok --pick berisi ID hunk dengan pesan, dan bekerja pada HEAD secara langsung atau pada commit lama lewat rebase.
Apakah git-surgeon aman diberikan ke agen otonom?
Sebagian besar aman, dengan dua peringatan. Ia menolak saat index kotor, mengembalikan keadaan saat commit gagal, dan gagal dengan bersih saat patch tidak bisa diterapkan. Tapi discard menghapus permanen perubahan yang belum di-commit, dan konflik rebase tetap butuh manusia untuk menyelesaikan, jadi jangan biarkan agen menulis ulang riwayat bersama.
