كيف تستخدم Git مع تطبيق بنيته بالذكاء الاصطناعي

لاستخدام Git مع تطبيق بُني بالذكاء الاصطناعي، اربط المشروع بمستودع Git، والتزم بعد كل تغيير ناجح، واكتب رسالة من سطر واحد تصف ما تغيّر، واحمِ الأسرار باستخدام ملف .gitignore. استخدم فرعًا لأي عمل محفوف بالمخاطر، واسحب التحديثات قبل أن تكتب طلبًا جديدًا إذا غيّر شخص آخر الكود، وحين يكسر الذكاء الاصطناعي شيئًا، ارجع إلى آخر نسخة سليمة بدلًا من أن تكتب طلبات فوق الفوضى.

Git نظام للتحكم في الإصدارات: سجلّ لكل نسخة محفوظة من كودك. وGitHub موقع يخزّن مستودعات Git على الإنترنت. إذا كانت هذه المفاهيم جديدة عليك، فابدأ بـما هو GitHub. يركّز هذا الدليل على العادات التي تجعل Git مفيدًا حين يكتب الذكاء الاصطناعي معظم الكود.

لماذا يصبح Git أهم مع الذكاء الاصطناعي

يستطيع الذكاء الاصطناعي تغيير عشرين ملفًا في دورة واحدة. هذا سريع، لكنه يعني أيضًا أن طلبًا واحدًا قد يكسر بهدوء شيئًا كنت قد اختبرته بالأمس. يمنحك Git:

• طريقة للعودة. يمكن استعادة أي نسخة ملتزَم بها.
• سجلًّا لما تغيّر. يمكنك أن ترى الملفات والأسطر التي لمسها كل طلب بالضبط.
• نسخة خارج أداة البناء. يعيش كودك في مكان تتحكم فيه.
• تسليمًا موحّدًا. يستطيع أي مطور أو مضيف أو أداة العمل من مستودع Git.

الخطوة 1: اربط مستودعًا

أنشئ مستودعًا (عادةً خاصًا) على GitHub أو خدمة مشابهة، واربط مشروعك به. معظم أدوات بناء التطبيقات بالذكاء الاصطناعي التي تدعم Git تفعل ذلك من صفحة إعدادات فيها زر «Connect GitHub». إذا لم تكن أداتك كذلك، يمكنك تصدير الكود ودفعه بنفسك، أو أن تطلب من مطور إعداده مرة واحدة.

قبل الدفع الأول، تأكد من أن المستودع يتجاهل الأشياء التي لا يجب أن تكون فيه:

تحقق من ملف .gitignore. تأكد من أنه يستبعد ملفات .env ومجلد node_modules ومجلدات مخرجات البناء وأي ملف يحتوي على أسرار. أخبرني بما أضفته.

الخطوة 2: التزم بعد كل تغيير ناجح

الالتزام (commit) هو لقطة محفوظة مع رسالة. العادة الأهم: التزم حين يعمل شيء ما، قبل أن تطلب الشيء التالي.

1. اطلب تغييرًا واحدًا.
2. تحقق منه في المعاينة.
3. إذا نجح، فالتزم (أو زامن) مع رسالة.
4. ثم انتقل إلى التالي.

الالتزامات الصغيرة تعني أنك حين يتعطل شيء ما تعرف أي تغيير تسبب فيه، والتراجع عنه لا يمحو عملًا آخر.

الخطوة 3: اكتب رسائل تفهمها لاحقًا

الرسالة الجيدة تقول ما تغيّر ولماذا، في سطر واحد:

• جيد: إضافة تصدير CSV إلى صفحة الطلبات
• جيد: إصلاح رفض نموذج الحجز للأوقات بعد السادسة مساءً
• غير مفيد: تحديث أو تغييرات أو إصلاح أشياء

يمكنك أن تطلب من الذكاء الاصطناعي كتابتها:

لخّص التغييرات منذ آخر التزام في سطر واحد يبدأ بفعل، وبأقل من 70 حرفًا.

الخطوة 4: استخدم الفروع للعمل المحفوف بالمخاطر

الفرع خط عمل منفصل. يمكنك تجربة شيء على فرع، فإن لم ينجح تتخلى عنه دون أن تمس النسخة الرئيسية.

استخدم فرعًا حين:

• يكون التغيير كبيرًا (إعادة تصميم، أو تدفق دفع جديد، أو تغيير في قاعدة البيانات).
• يعمل شخص آخر على التطبيق نفسه.
• تريد أن يراجع أحدهم التغيير قبل أن يصل إلى الإنتاج.

حين ينتهي العمل ويُختبر، يُدمج (merge) مرة أخرى في الفرع الرئيسي. على GitHub يحدث ذلك غالبًا عبر طلب سحب (pull request)، وهي صفحة تعرض التغييرات للمراجعة. إذا كانت أداتك لا تزامن إلا فرعًا واحدًا، فيمكن للمطور إدارة الفروع من جهة GitHub.

الخطوة 5: تراجع بأمان

حين يكسر طلب التطبيق، قاوم الرغبة في كتابة خمسة طلبات أخرى فوقه. ارجع إلى آخر نسخة سليمة وجرّب طلبًا أوضح.

• في أداة البناء: استخدم ميزة نقطة الحفظ (checkpoint) أو الاستعادة، إن وُجدت.
• في Git: ينشئ git revert التزامًا جديدًا يلغي التزامًا قديمًا، فيبقى السجل سليمًا. وهو الخيار الآمن للكود الذي ربما سحبه آخرون.
• تجنب git push --force على فرع مشترك إلا إذا كنت تعرف السبب تمامًا، لأنه يعيد كتابة السجل للجميع.

إذا لم تكن متأكدًا، فاسأل:

أدى التغيير الأخير إلى كسر صفحة تسجيل الدخول. اعرض الملفات التي غيّرها مقارنةً بالالتزام السابق، واشرح ما فعله كل تغيير. لا تغيّر أي شيء بعد.

الخطوة 6: اسحب التحديثات قبل أن تكتب طلبًا

إذا غيّر مطور أو أداة أخرى الكود على GitHub، فلن يعلم منشئ التطبيق بذلك حتى تسحب تلك التغييرات (pull). الكتابة على كود قديم تسبب تعارضات وفقدانًا للعمل.

• اسحب في بداية كل جلسة.
• اتفقا على من يعدّل ماذا، وتجنبا تعديل الملفات نفسها في الوقت ذاته.
• إذا حدث تعارض دمج (merge conflict) (تغييران على الأسطر نفسها)، فاطلب من المطور أو من الذكاء الاصطناعي حله وشرح الاختيار الذي تم.

أمثلة على الطلبات

قبل أن نبدأ: ما الذي تغيّر في المستودع منذ جلستي الأخيرة؟ لخّص الالتزامات.

نفّذ التغيير التالي وحده: أضف زر «Duplicate» إلى كل فاتورة. لا تغيّر أي شيء آخر، حتى أتمكن من التزامه منفصلًا.

تحقق من أن لا مفاتيح API أو كلمات مرور أو ملفات .env مُتتبَّعة في Git، بما في ذلك الالتزامات السابقة. أبلغ عن أسماء الملفات فقط، لا عن القيم.

أخطاء شائعة

• التزام الأسرار. بمجرد دخول مفتاح إلى سجل Git يصبح مكشوفًا، حتى لو حذفت الملف لاحقًا. أعد توليد المفتاح.
• التزام كبير واحد كل أسبوع. لا يمكنك التراجع عن تغيير واحد دون التراجع عن الكل.
• رسائل مثل «update». يصبح السجل عديم الفائدة في معرفة ما الذي تعطّل.
• الكتابة على كود قديم. اسحب أولًا حين يعدّل شخص آخر.
• الدفع القسري لإصلاح خطأ. قد يمحو عمل الآخرين. استخدم revert بدلًا منه.
• التزام node_modules. حجمه ضخم، ويُعاد إنشاؤه من ملف القفل على أي حال.

قائمة التحقق

• المشروع مربوط بمستودع خاص.
• يستبعد .gitignore الملفات .env وnode_modules ومخرجات البناء والأسرار.
• أقوم بالالتزام بعد كل تغيير ناجح.
• رسائل الالتزام تصف ما تغيّر في سطر واحد.
• التغييرات الكبيرة أو المحفوفة بالمخاطر تذهب إلى فرع وتُراجَع.
• أسحب التحديثات قبل الكتابة حين يعدّل غيري الكود.
• أتراجع بنقاط الحفظ أو بـ git revert، لا بالدفع القسري.
• أي مفتاح سبق التزامه تم تدويره.

Git على Mythex

يحفظ Mythex نقطة Git بعد كل دورة ناجحة للوكيل، وزر Revert to this point يعيد المشروع إلى تلك النقطة، وهو التراجع من جهة الأداة الذي وصفناه في الخطوة 5. راجع Iterate without rebuilding.

في خطة Pro، تربط مزامنة GitHub مستودعًا من إعدادات المشروع فتدفع وتسحب عليه، وتنزّل export المشروع دون الأسرار وnode_modules. راجع GitHub, export, and import. ربط GitHub قبل تسليم المشروع إلى مطور يجعل التسليم أسهل بكثير. راجع كيف تعمل مع مطور على تطبيق بُني بالذكاء الاصطناعي وكيف تصدّر تطبيقًا بناه الذكاء الاصطناعي وتستضيفه بنفسك.

الأسئلة