عمليات الـ commit والـ branches من خلال الوكيل
حتى الآن قام Claude Code بتحرير الملفات وإصلاح الشيفرة. في هذا الدرس سنرى ما يحدث عندما يحفظ التغيير أيضًا في git: فتح branch مخصّص بدلًا من المساس بـ main، واختيار الملفات التي تنتمي فعلًا إلى الـ commit بدلًا من رمي كل شيء بداخله، وكتابة رسالة commit تشرح لماذا أُجري التغيير — لا ما الذي تغيّر فقط
العمل الجيّد مع الوكيل يشبه إعطاء النجّار طاولة عمل جديدة لكل طلبية جديدة — فهو يُحضِر فقط الأدوات التي تحتاجها تلك الطلبية، ويلصق على كل قطعة منتهية ملاحظة تشرح لماذا صُنعت بهذه الطريقة، لا ما بداخلها فقط.
- branch (فرع)
- نسخة منفصلة من شيفرة المشروع يمكنك العمل فيها دون المساس بـ main، وتُدمَج مرة أخرى فقط عندما يصبح التغيير جاهزًا.
- منطقة الـ staging (git add)
- مجموعة التغييرات المختارة صراحةً لتُضمَّن في الـ commit التالي؛ فالملف الذي تغيّر لكنه لم يُمرَّر إلى git add يُترَك خارج الـ commit.
- رسالة commit
- النص الذي يوثّق لماذا أُجري التغيير، لا الأسطر التي تغيّرت فقط — كي يفهم السبب من يقرؤه بعد ستة أشهر.
- force-push
- دفعة (push) تدوس على تاريخ الـ branch البعيد بدلًا من الإضافة إليه؛ يمكن أن تمحو عمل الآخرين وتتطلّب موافقة صريحة مسبقة.
- تخطّي الـ hooks (--no-verify)
- تنفيذ commit مع تجاوز فحوصات الـ pre-commit المُعدّة لالتقاط المشكلات مسبقًا؛ هذا التخطّي يُعطّل شبكة الأمان تلك، ولذلك يتطلّب طلبًا صريحًا قبل القيام به.
