Asisten AI untuk menulis kode kini makin lazim dipakai. Cukup ketik permintaan, lalu AI membaca berkas, mengubah beberapa baris, bahkan menjalankan perintah di terminal. Cepat dan praktis. Namun kecepatan itu membawa satu pertanyaan penting: kalau hasilnya keliru, bagaimana cara kembali ke kondisi semula dengan aman?
Jawaban paling sederhana adalah kebiasaan yang menjadi judul tulisan ini: commit dulu sebelum suruh AI. Artinya, sebelum memberi tugas kepada AI, simpan dulu semua perubahan kode yang sedang dikerjakan ke dalam riwayat git. Dengan begitu ada titik aman yang jelas untuk kembali.
Apa yang Dimaksud "Commit"?
Git adalah sistem pengelolaan versi (version control) yang mencatat riwayat perubahan berkas. Satu commit ibarat foto kondisi proyek pada satu saat, lengkap dengan catatan singkat tentang apa yang berubah.
Buku resmi Pro Git menyebut bahwa apa pun yang sudah di-commit di Git hampir selalu bisa dipulihkan, sedangkan perubahan yang belum pernah di-commit kemungkinan besar hilang begitu saja bila terhapus atau tertimpa (Pro Git, "Undoing Things"). Inilah inti alasannya: commit mengubah pekerjaan yang "rapuh" menjadi pekerjaan yang "tercatat".
Mengapa Harus Sebelum AI Bekerja?
Ada beberapa alasan praktis.
1. Memisahkan pekerjaan manusia dan pekerjaan AI. Jika masih ada perubahan buatan sendiri yang belum di-commit, lalu AI ikut mengubah berkas yang sama, keduanya bercampur. Saat hasil AI ternyata salah, sulit memilah mana baris yang harus dibuang dan mana yang harus dipertahankan. Dengan commit lebih dulu, semua perubahan setelah titik itu jelas berasal dari tugas yang diberikan kepada AI.
2. Membatalkan jadi mudah. Setelah ada commit, perubahan AI yang tidak diinginkan dapat dibuang dengan perintah bawaan git, misalnya git restore <berkas> untuk mengembalikan berkas ke versi terakhir yang tersimpan. Perlu dicatat, Pro Git sendiri mengingatkan bahwa git restore <berkas> termasuk perintah berbahaya karena perubahan lokal pada berkas itu akan hilang (Pro Git). Justru karena itu, perubahan milik sendiri sebaiknya sudah aman di commit sebelum perintah semacam ini dipakai.
3. Meninjau hasil AI jadi jelas. Dengan titik awal yang bersih, perintah git diff menampilkan persis apa saja yang diubah AI (dokumentasi git diff). Peninjauan tidak lagi bergantung pada ingatan atau penjelasan dari AI itu sendiri, tetapi pada catatan perubahan yang nyata.
Bukankah Alat AI Sudah Punya Fitur "Undo"?
Sebagian alat memang menyediakan fitur pembatalan. Namun dokumentasinya sendiri menunjukkan batas-batas fitur tersebut.
Claude Code, misalnya, punya fitur checkpoint yang otomatis merekam kondisi kode dan bisa dikembalikan lewat perintah /rewind. Dokumentasi resminya menjelaskan beberapa keterbatasan (Claude Code Docs, "Checkpointing"):
- Perubahan berkas yang dilakukan lewat perintah terminal (contohnya rm, mv, cp) tidak terekam dan tidak bisa dibatalkan lewat rewind.
- Perubahan manual di luar sesi, atau dari sesi lain yang berjalan bersamaan, umumnya tidak tertangkap.
- Suntingan oleh subagent pada umumnya tidak ikut dipulihkan, dan dokumentasi menyarankan memakai git untuk mengembalikannya.
- Cuplikan berkas dibersihkan otomatis, secara bawaan sekitar 30 hari setelah sesi terakhir menyimpannya.
Dokumentasi itu juga menegaskan bahwa checkpoint dirancang untuk pemulihan cepat di tingkat sesi, dan untuk riwayat versi permanen pengguna tetap disarankan memakai sistem pengelolaan versi seperti Git.
Alat lain, Aider, bahkan menjadikan git bagian dari cara kerjanya. Dokumentasi Aider menyebut bahwa sebelum mengedit berkas yang punya perubahan belum di-commit, Aider lebih dulu meng-commit perubahan tersebut, lalu setiap editannya sendiri juga di-commit dengan pesan yang deskriptif. Perintah /undo disediakan untuk membatalkan perubahan terakhir, dan /diff untuk melihat perubahan sejak pesan terakhir (Aider, "Git integration").
Dengan kata lain, pembuat alat AI sendiri memandang commit sebagai jaring pengaman yang penting. Kebiasaan commit sebelum menyuruh AI sejalan dengan prinsip itu dan tetap berlaku apa pun alat yang dipakai.
Langkah Praktis Sebelum Memberi Tugas ke AI
Berikut urutan sederhana yang bisa diterapkan:
- Cek kondisi proyek dengan git status. Lihat berkas apa saja yang berubah dan belum tersimpan.
- Commit perubahan yang ada dengan pesan yang jelas, misalnya git add <berkas> lalu git commit -m "simpan kondisi sebelum minta AI merapikan modul laporan". Sebaiknya tambahkan berkas yang memang dimaksud saja, agar berkas rahasia seperti .env tidak ikut tercatat.
- Beri tugas ke AI dengan permintaan yang spesifik.
- Tinjau hasilnya dengan git diff. Jalankan pengujian bila ada.
- Putuskan. Jika hasilnya baik, buat commit baru. Jika tidak, kembalikan berkas ke versi terakhir yang tersimpan, lalu perbaiki permintaan dan coba lagi.
Untuk percobaan yang lebih besar, bisa juga membuat cabang (branch) baru terlebih dahulu dengan git switch -c <nama-cabang> (dokumentasi git switch). Hasil kerja AI terisolasi di cabang itu dan cabang utama tetap utuh.
Bagaimana Jika Proyek Belum Memakai Git?
Proyek yang belum memakai git bisa memulainya dengan git init di folder proyek (dokumentasi git init). Setelah itu buat berkas .gitignore untuk mengecualikan berkas rahasia dan folder besar, lalu lakukan commit pertama. Sejak saat itu setiap perubahan, baik oleh manusia maupun AI, punya riwayat yang bisa ditelusuri.
Penutup
AI dapat mempercepat pekerjaan pemrograman, tetapi tanggung jawab atas kode tetap ada pada manusia yang memakainya. Commit sebelum menyuruh AI adalah langkah kecil yang hanya butuh beberapa detik, namun memberi tiga hal sekaligus: titik aman untuk kembali, batas yang jelas antara pekerjaan sendiri dan pekerjaan AI, serta catatan perubahan yang bisa diperiksa. Sebelum mengetik permintaan berikutnya ke AI, biasakan bertanya dulu: "Sudah commit belum?"