Cara Menggunakan Git dengan Aplikasi yang Dibuat AI

Untuk menggunakan Git dengan aplikasi buatan AI, hubungkan proyek ke repositori Git, lakukan commit setelah setiap perubahan yang berhasil, tulis satu baris pesan yang menjelaskan apa yang berubah, dan jauhkan rahasia dengan .gitignore. Gunakan branch untuk pekerjaan yang berisiko, lakukan pull sebelum meminta lagi jika orang lain mengubah kode, dan saat AI merusak sesuatu, kembali ke commit terakhir yang baik alih-alih meminta lagi di atas kekacauan itu.

Git adalah version control: riwayat setiap versi kode yang tersimpan. GitHub adalah situs web yang menyimpan repositori Git secara online. Jika istilah-istilah ini masih baru bagi Anda, mulai dengan apa itu GitHub. Panduan ini membahas kebiasaan yang membuat Git berguna ketika AI menulis sebagian besar kodenya.

Mengapa Git lebih penting dengan AI

AI bisa mengubah dua puluh file dalam satu giliran. Itu cepat, tetapi juga berarti satu permintaan bisa diam-diam merusak sesuatu yang sudah Anda uji kemarin. Git memberi Anda:

• Jalan kembali. Versi mana pun yang sudah di-commit bisa dipulihkan.
• Catatan perubahan. Anda bisa melihat file dan baris mana yang disentuh oleh satu permintaan.
• Salinan di luar builder. Kode Anda tersimpan di tempat yang Anda kendalikan.
• Serah terima yang standar. Developer, host, atau alat apa pun bisa bekerja dari repositori Git.

Langkah 1: Hubungkan repositori

Buat repositori (biasanya privat) di GitHub atau layanan serupa, lalu hubungkan proyek Anda ke sana. Sebagian besar AI app builder yang mendukung Git melakukannya lewat halaman pengaturan dengan tombol "Connect GitHub". Jika builder Anda tidak punya, Anda bisa mengekspor kode dan mengunggahnya sendiri, atau meminta developer menyiapkannya sekali saja.

Sebelum push pertama, pastikan repositori mengabaikan hal-hal yang tidak seharusnya ada di sana:

Periksa file .gitignore. Pastikan ia mengecualikan file .env, node_modules, folder output build, dan file apa pun yang berisi rahasia. Beri tahu saya apa yang Anda tambahkan.

Langkah 2: Commit setelah setiap perubahan yang berhasil

Commit adalah snapshot tersimpan dengan sebuah pesan. Kebiasaan yang paling penting: commit saat sesuatu sudah berfungsi, sebelum Anda meminta hal berikutnya.

1. Minta satu perubahan.
2. Periksa di preview.
3. Jika berhasil, commit (atau sync) dengan sebuah pesan.
4. Lanjut.

Commit yang kecil berarti saat ada yang rusak, Anda tahu perubahan mana yang menyebabkannya, dan membatalkannya tidak membuang pekerjaan lain.

Langkah 3: Tulis pesan yang bisa dibaca nanti

Pesan yang baik menjelaskan apa yang berubah dan mengapa, dalam satu baris:

• Baik: Tambah ekspor CSV ke halaman pesanan
• Baik: Perbaiki formulir pemesanan yang menolak jam setelah pukul 18.00
• Tidak berguna: update, perubahan, benerin dikit

Anda bisa meminta AI untuk menulisnya:

Ringkas perubahan sejak commit terakhir dalam satu baris, diawali kata kerja, kurang dari 70 karakter.

Langkah 4: Gunakan branch untuk pekerjaan berisiko

Branch adalah jalur kerja terpisah. Anda bisa mencoba sesuatu di branch, dan jika tidak berhasil, meninggalkannya tanpa menyentuh versi utama.

Gunakan branch saat:

• Perubahannya besar (desain ulang, alur pembayaran baru, perubahan database).
• Ada orang lain yang mengerjakan aplikasi yang sama.
• Anda ingin seseorang meninjau perubahan sebelum tayang.

Saat pekerjaan selesai dan sudah diuji, ia di-merge kembali ke branch utama. Di GitHub, ini biasanya dilakukan lewat pull request, yaitu halaman yang menampilkan perubahan untuk ditinjau. Jika builder Anda hanya men-sync satu branch, developer bisa mengelola branch di sisi GitHub.

Langkah 5: Batalkan dengan aman

Saat sebuah permintaan merusak aplikasi, tahan dorongan untuk meminta lima kali lagi di atas kerusakan itu. Kembali ke versi terakhir yang baik dan coba lagi dengan permintaan yang lebih jelas.

• Di builder: gunakan fitur checkpoint atau restore-nya, jika ada.
• Di Git: git revert membuat commit baru yang membatalkan commit lama, sehingga riwayat tetap utuh. Ini pilihan yang aman untuk kode yang mungkin sudah di-pull orang lain.
• Hindari git push --force pada branch bersama kecuali Anda benar-benar tahu alasannya. Perintah itu menulis ulang riwayat untuk semua orang.

Jika Anda tidak yakin, tanyakan:

Perubahan terakhir merusak halaman login. Tunjukkan file apa saja yang diubah dibanding commit sebelumnya, dan jelaskan apa yang dilakukan setiap perubahan. Jangan ubah apa pun dulu.

Langkah 6: Pull sebelum meminta

Jika developer atau alat lain mengubah kode di GitHub, AI builder tidak tahu sampai Anda pull perubahan itu. Meminta di atas kode lama menyebabkan konflik dan pekerjaan yang hilang.

• Lakukan pull di awal setiap sesi.
• Sepakati siapa mengedit apa, dan hindari dua pihak mengedit file yang sama secara bersamaan.
• Jika muncul merge conflict (dua perubahan pada baris yang sama), minta developer atau AI untuk menyelesaikannya dan menjelaskan pilihannya.

Contoh permintaan

Sebelum kita mulai: apa saja yang berubah di repositori sejak sesi terakhir saya? Ringkas commit-nya.

Buat perubahan berikutnya secara terpisah: tambahkan tombol "Duplicate" di setiap faktur. Jangan ubah yang lain, supaya saya bisa commit-kan sendiri.

Periksa apakah ada API key, password, atau file .env yang dilacak di Git, termasuk di commit lama. Laporkan hanya nama file, bukan nilainya.

Kesalahan umum

• Meng-commit rahasia. Begitu sebuah key masuk ke riwayat Git, ia terekspos, bahkan setelah file-nya dihapus. Ganti key tersebut.
• Satu commit besar seminggu sekali. Anda tidak bisa membatalkan satu perubahan tanpa membatalkan semuanya.
• Pesan seperti "update". Riwayat jadi tidak berguna untuk mencari apa yang rusak.
• Meminta di atas kode yang sudah usang. Lakukan pull dulu jika ada orang lain yang sedang mengedit.
• Force-push untuk memperbaiki kesalahan. Itu bisa menghapus pekerjaan orang lain. Gunakan revert.
• Meng-commit node_modules. Ukurannya besar dan toh akan dibuat ulang dari lock file.

Daftar periksa

• Proyek terhubung ke repositori privat.
• .gitignore mengecualikan .env, node_modules, output build, dan rahasia.
• Saya melakukan commit setelah setiap perubahan yang berhasil.
• Pesan commit menjelaskan apa yang berubah dalam satu baris.
• Perubahan besar atau berisiko masuk ke branch dan ditinjau.
• Saya melakukan pull sebelum meminta jika orang lain mengedit kode.
• Saya membatalkan dengan checkpoint atau git revert, bukan force-push.
• Setiap key yang pernah ter-commit sudah diganti.

Git di Mythex

Mythex menyimpan checkpoint Git setelah setiap giliran agen yang berhasil, dan Kembali ke titik ini memulihkan proyek ke titik tersebut. Ini adalah undo di sisi builder seperti dijelaskan di langkah 5. Lihat Iterasi tanpa membangun ulang.

Di Pro, sinkronisasi GitHub menghubungkan repositori dari pengaturan proyek sehingga Anda bisa push dan pull, dan ekspor mengunduh proyek dengan rahasia serta node_modules dikecualikan. Lihat GitHub, ekspor, dan impor. Menghubungkan GitHub sebelum menyerahkan proyek ke developer membuat serah terima jauh lebih mudah. Lihat cara bekerja dengan developer pada aplikasi buatan AI dan cara mengekspor dan self-host aplikasi buatan AI.

Pertanyaan