Cara Guna Git dengan Aplikasi yang Dibina AI

Untuk menggunakan Git dengan aplikasi yang dibina AI, sambungkan projek ke repositori Git, commit selepas setiap perubahan yang berjaya, tulis mesej satu baris yang menerangkan apa yang berubah, dan simpan rahsia di luar dengan .gitignore. Gunakan cawangan (branch) untuk apa-apa kerja yang berisiko, pull sebelum anda beri arahan lagi jika orang lain menukar kod, dan apabila AI merosakkan sesuatu, kembali ke commit baik yang terakhir dan bukannya terus beri arahan di atas kekacauan itu.

Git ialah kawalan versi: sejarah setiap versi kod anda yang disimpan. GitHub ialah laman web yang menyimpan repositori Git secara dalam talian. Jika ini baharu kepada anda, mulakan dengan apa itu GitHub. Panduan ini tentang tabiat yang menjadikan Git berguna apabila AI menulis kebanyakan kod.

Mengapa Git lebih penting dengan AI

AI boleh menukar dua puluh fail dalam satu giliran. Itu pantas, tetapi ia juga bermakna satu arahan boleh diam-diam merosakkan sesuatu yang anda uji semalam. Git memberi anda:

• Jalan untuk kembali. Mana-mana versi yang di-commit boleh dipulihkan.
• Rekod apa yang berubah. Anda boleh melihat dengan tepat fail dan baris mana yang disentuh oleh satu arahan.
• Salinan di luar pembina. Kod anda berada di tempat yang anda kawal.
• Serahan yang piawai. Mana-mana pembangun, hos atau alat boleh bekerja daripada repositori Git.

Langkah 1: Sambungkan repositori

Cipta repositori (biasanya persendirian) di GitHub atau perkhidmatan yang serupa, dan sambungkan projek anda kepadanya. Kebanyakan pembina aplikasi AI yang menyokong Git melakukannya melalui halaman tetapan dengan butang "Connect GitHub". Jika pembina anda tidak mempunyai ciri ini, anda boleh mengeksport kod dan menolaknya (push) sendiri, atau minta pembangun menyediakannya sekali sahaja.

Sebelum push pertama, pastikan repositori mengabaikan perkara yang tidak sepatutnya berada di dalamnya:

Semak fail .gitignore. Pastikan ia mengecualikan fail .env, node_modules, folder output build dan mana-mana fail yang mengandungi rahsia. Beritahu saya apa yang anda tambah.

Langkah 2: Commit selepas setiap perubahan yang berjaya

Commit ialah snapshot yang disimpan dengan mesej. Tabiat yang penting: commit apabila sesuatu berfungsi, sebelum anda minta perkara seterusnya.

1. Beri arahan untuk satu perubahan.
2. Semak dalam pratonton.
3. Jika ia berfungsi, commit (atau sync) dengan mesej.
4. Kemudian teruskan.

Commit yang kecil bermakna apabila sesuatu rosak, anda tahu perubahan mana yang menyebabkannya, dan membatalkannya tidak membuang kerja lain.

Langkah 3: Tulis mesej yang boleh dibaca kemudian

Mesej yang baik menyatakan apa yang berubah dan sebabnya, dalam satu baris:

• Baik: Tambah eksport CSV pada halaman pesanan
• Baik: Betulkan borang tempahan yang menolak masa selepas 6 petang
• Tidak berguna: update, changes, fix stuff

Anda boleh minta AI menulisnya:

Ringkaskan perubahan sejak commit terakhir dalam satu baris, bermula dengan kata kerja, kurang daripada 70 aksara.

Langkah 4: Gunakan cawangan untuk kerja berisiko

Cawangan (branch) ialah barisan kerja yang berasingan. Anda boleh mencuba sesuatu pada cawangan, dan jika ia tidak menjadi, anda boleh meninggalkannya tanpa menyentuh versi utama.

Gunakan cawangan apabila:

• Perubahannya besar (reka bentuk semula, aliran pembayaran baharu, perubahan pangkalan data).
• Orang lain sedang bekerja pada aplikasi yang sama.
• Anda mahu seseorang menyemak perubahan sebelum ia dilancarkan.

Apabila kerja selesai dan diuji, ia digabungkan (merge) semula ke cawangan utama. Di GitHub, ini biasanya berlaku melalui pull request, iaitu halaman yang menunjukkan perubahan untuk semakan. Jika pembina anda hanya menyegerakkan satu cawangan, pembangun boleh menguruskan cawangan di pihak GitHub.

Langkah 5: Buat asal dengan selamat

Apabila arahan merosakkan aplikasi, tahan diri daripada memberi lima arahan lagi di atasnya. Kembali ke versi baik yang terakhir dan cuba arahan yang lebih jelas.

• Dalam pembina: guna ciri checkpoint atau pulihkan (restore), jika ada.
• Dalam Git: git revert mencipta commit baharu yang membatalkan commit lama, dengan sejarah kekal utuh. Ia pilihan yang selamat untuk kod yang mungkin telah ditarik oleh orang lain.
• Elakkan git push --force pada cawangan yang dikongsi melainkan anda tahu dengan tepat sebabnya. Ia menulis semula sejarah untuk semua orang.

Jika anda tidak pasti, tanya:

Perubahan terakhir merosakkan halaman log masuk. Tunjukkan fail mana yang ia ubah berbanding commit sebelumnya, dan terangkan apa yang setiap perubahan lakukan. Jangan ubah apa-apa lagi.

Langkah 6: Pull sebelum anda beri arahan

Jika pembangun atau alat lain menukar kod di GitHub, pembina AI tidak tahu sehingga anda pull perubahan tersebut. Memberi arahan pada kod lama menyebabkan konflik dan kerja yang hilang.

• Pull pada permulaan setiap sesi.
• Bersetuju siapa mengedit apa, dan elakkan kedua-dua pihak mengedit fail yang sama pada masa yang sama.
• Jika anda mendapat merge conflict (dua perubahan pada baris yang sama), minta pembangun atau AI menyelesaikannya dan menerangkan pilihan itu.

Contoh arahan

Sebelum kita mula: apa yang berubah dalam repositori sejak sesi terakhir saya? Ringkaskan commit-commit tersebut.

Buat perubahan seterusnya secara berasingan: tambah butang "Duplicate" pada setiap invois. Jangan ubah apa-apa lagi, supaya saya boleh commit secara berasingan.

Semak bahawa tiada kunci API, kata laluan atau fail .env yang dijejak dalam Git, termasuk dalam commit lama. Laporkan nama fail sahaja, bukan nilainya.

Kesilapan biasa

• Commit rahsia. Sebaik sahaja kunci berada dalam sejarah Git, ia terdedah, walaupun anda memadam fail itu kemudian. Tukar kuncinya.
• Satu commit besar seminggu sekali. Anda tidak boleh membatalkan satu perubahan tanpa membatalkan semuanya.
• Mesej seperti "update". Sejarah menjadi tidak berguna untuk mencari apa yang rosak.
• Memberi arahan pada kod lapuk. Pull dahulu apabila orang lain sedang mengedit.
• Force-push untuk membetulkan kesilapan. Ia boleh memadam kerja orang lain. Gunakan revert sebaliknya.
• Commit node_modules. Ia besar dan dicipta semula daripada fail lock juga.

Senarai semak

• Projek disambungkan ke repositori persendirian.
• .gitignore mengecualikan .env, node_modules, output build dan rahsia.
• Saya commit selepas setiap perubahan yang berjaya.
• Mesej commit menerangkan apa yang berubah dalam satu baris.
• Perubahan besar atau berisiko pergi ke cawangan dan disemak.
• Saya pull sebelum beri arahan apabila orang lain mengedit kod.
• Saya buat asal dengan checkpoint atau git revert, bukan force-push.
• Mana-mana kunci yang pernah di-commit telah ditukar.

Git di Mythex

Mythex menyimpan checkpoint git selepas setiap giliran ejen yang berjaya, dan Revert to this point memulihkan projek kepada titik itu — iaitu cara membuat asal di pihak pembina seperti yang diterangkan dalam langkah 5. Lihat Ulang dan ubah tanpa membina semula.

Pada Pro, GitHub sync menyambungkan repositori dari tetapan projek supaya anda boleh push dan pull padanya, dan export memuat turun projek dengan rahsia dan node_modules dikecualikan. Lihat GitHub, eksport dan import. Menyambungkan GitHub sebelum menyerahkan projek kepada pembangun memudahkan serahan — lihat cara bekerja dengan pembangun pada aplikasi yang dibina AI dan cara mengeksport dan self-host aplikasi yang dibina AI.

Soalan lazim