التحكم بالإصدارات من السطر الأول - البرمجة بالإحساس، بمعايير احترافية

ماذا ستتعلّم

لماذا يهمّ التحكم بالإصدارات أكثر، لا أقلّ، حين يكتب الذكاء الاصطناعي الشيفرة
حلقة Git الأساسية وكيف تكتب رسائل إيداعٍ تستحقّ القراءة
أبقِ main يعمل دائمًا عبر فرعٍ لكل مرحلة
راجع كل تغييرٍ مولَّد كأنه طلب دمج — بقائمة تحقّق
تراجَع عن أيّ شيء: restore وrevert والاسترجاع الآمن
مختبر عملي: أضِف .gitignore، وافرَع لـM1، وابنِ الشريحة الأولى، وراجع التغيير، وادمج

المتطلبات المسبقة: الوحدة 3 — مستودع snippet-vault بملف SPEC.md مُودَع.

لماذا يهمّ Git أكثر مع الذكاء الاصطناعي

يستطيع المساعد إعادة كتابة عشرين ملفًّا في عشر ثوانٍ، وهو واثقٌ تمامًا من نفسه. تلك السرعة هي بالضبط سبب حاجتك لشبكة أمانٍ تحته. يمنحك Git ثلاث قوًى تحوّل «سريع وخطر» إلى «سريع وآمن»:

القوّة	ماذا تعني
نقطة حفظ	كل إيداعٍ نقطة عودة. تعديلٌ سيّئ من الذكاء الاصطناعي لن يكون دائمًا أبدًا.
عدسة مكبّرة	`git diff` يُظهر ما تغيّر بالضبط سطرًا سطرًا — فتراجع قبل أن تثق.
آلة زمن	انكسر شيء؟ `git log` و`revert` يحدّدان التغيير الجاني ويتراجعان عنه.

بدأت بالفعل في الوحدة 1

تُودِع منذ أوّل «إحساس» لك. هذه الوحدة تحوّل ذلك إلى انضباط: إيداعاتٌ صغيرة، وفروع، ومراجعة تغييرات — العادات التي تجعل التطوير بسرعة الذكاء الاصطناعي مستدامًا.

الحلقة الأساسية

تسعون بالمئة من Git اليومي خمسة أوامر، بإيقاعٍ تكرّره طوال اليوم:

الأمر	يفعل
`git status`	ما الذي تغيّر وما المُدرَج.
`git diff`	التغييرات الدقيقة سطرًا سطرًا — اقرأها قبل الإيداع.
`git add <file>`	أدرِج التغييرات التي راجعتها وتريد إبقاءها.
`git commit -m "…"`	احفظ نقطة تفتيشٍ برسالة.
`git log --oneline`	تاريخ نقاط الحفظ.

رسائل إيداعٍ تستحقّ القراءة

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

Add create + list endpoints for snippets

Implements milestone M1 from SPEC.md. In-memory store for now;
a real database comes in the deploy module. No validation yet (M4).

لا تُودِع النفايات — استخدم .gitignore

الملفات المولّدة والسرّية يجب ألّا تدخل Git أبدًا. ملف .gitignore يُبقي node_modules/ ومخرجات البناء (dist/) وخاصّةً أسرار .env خارج تاريخك. إيداع سرٍّ مرّةً يعني بقاءه في التاريخ للأبد — والوقاية خيرٌ من التنظيف.

فرعٌ لكل مرحلة

ينبغي أن يعمل فرع main دائمًا. لذا لا تبني عليه مباشرةً — بل تفرَع لكل مرحلةٍ من SPEC.md، وتعمل هناك، ثم تدمج عند الاكتمال والمراجعة.

# start milestone M1 on its own branch
git checkout -b feature/m1-create-list

# ...build, review, commit on the branch...

# merge the finished milestone back into main
git checkout main
git merge feature/m1-create-list

لماذا يؤتي هذا ثماره مع الذكاء الاصطناعي

إن أخذ المساعد مرحلةً في اتجاهٍ سيّئ، تحذف الفرع فحسب — وmain سليم. الفروع تجعل التجارب رخيصة والأخطاء قابلةً للتخلّص، وهي بالضبط الحرّية التي تحتاجها البرمجة بالإحساس.

راجع كل تغييرٍ كأنه طلب دمج

عامِل المساعد كزميلٍ يفتح طلب دمج: أنت المراجِع. قبل أن تُدرِج أيّ شيء، شغّل git diff واقرأ كل جزءٍ وفق هذه القائمة:

اسأل	لماذا
هل يطابق المواصفة؟	القصّة التي تبنيها فقط — لا شيء زائد.
أيّ أسرارٍ أو مفاتيح؟	لا تدع بيانات اعتمادٍ تدخل إيداعًا أبدًا.
أيّ تغييراتٍ غير متعلّقة؟	كثيرًا ما «يساعد» الذكاء الاصطناعي فيعدّل ملفاتٍ لم تقصدها.
هل أفهم كل سطر؟	إن عجزت عن شرحه، عجزت عن صيانته — اطلب شرحًا أو تبسيطًا.
هل هو صغيرٌ بما يكفي للمراجعة؟	إن كان التغيير ضخمًا، قسّم المهمّة وأعد المحاولة.

«لقد اشتغل» ليس «راجعته»

تشغيل التطبيق يثبت أنه يفعل شيئًا، لا أنه يفعل الشيء الصحيح بأمان. مراجعة التغيير هي حيث تلتقط الثغرة الأمنية، والقيمة المكتوبة صراحةً، وتسلّل النطاق — قبل دخولها تاريخك.

تراجَع عن أيّ شيء

لأنك تُودِع كثيرًا، الاسترجاع سهل. الثلاثة التي ستستخدمها فعلًا:

الموقف	الأمر
تجاهل تغييراتٍ غير مُودَعة على ملف	`git restore <file>`
التراجع عن إيداعٍ سيّئ مع إبقاء التاريخ أمينًا	`git revert <hash>`
التخلّي عن فرعٍ تجريبيٍّ كاملًا	`git checkout main` ثم `git branch -D <branch>`

الثقة التي يمنحها هذا

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

مختبر عملي: افرَع، ابنِ شريحة، راجع كطلب دمج

ستُعِدّ سير عمل Git سليمًا وتستخدمه لبناء الشريحة الأولى الرفيعة من مرحلة M1 من مواصفتك — مراجعًا تغيير الذكاء الاصطناعي كأنه طلب دمج قبل أن يستقرّ.

ما تحتاجه

مستودع snippet-vault من الوحدة 3 (الهيكل، وملف السياق، وSPEC.md)، ومساعدك.

1

أضِف .gitignore

اطلب من المساعد توليد .gitignore لـmonorepo يعمل بـNode (يتجاهل node_modules/ وdist/ و.env). راجعه، ثم أودِعه على main:

git add .gitignore
git commit -m "Add .gitignore for node monorepo"

2

افرَع لمرحلة M1

git checkout -b feature/m1-create-list

3

اطلب الشريحة الأولى فقط

وجّه المساعد إلى مواصفتك وأبقِ النطاق صغيرًا:

Implement only M1 from SPEC.md: a Snippet type and two API endpoints —
POST /snippets (create) and GET /snippets (list) — using an in-memory
array for now (no database yet). No search, no delete, no UI. Small diff.

4

راجع التغيير كطلب دمج

قبل إدراج أيّ شيء، اقرأه وفق القائمة:

git status
git diff

هل يطابق المواصفة؟ لا أسرار؟ لا ملفاتٍ غير متعلّقة؟ أتفهم كل سطر؟ اعترض على ما يسقط — اطلب من المساعد الإصلاح أو الشرح قبل القبول.

5

أودِع برسالةٍ حقيقية، ثم ادمج

git add .
git commit -m "Add create + list endpoints for snippets (M1)"
git checkout main
git merge feature/m1-create-list

6

تأمّل

في REFLECTION.md: الصق git log --oneline، ودوّن شيئًا واحدًا التقطته وأنت تقرأ التغيير كان تشغيل التطبيق سيخفيه. ثم أودِعه.

ما الذي تسلّمه

مستودع snippet-vault. تحقّق من نفسك قبل التسليم:

ملف .gitignore مُودَع (لا node_modules/ في المستودع)
بُنيت M1 على فرع feature/ ودُمجت في main
رسائل الإيداع تقول لماذا، لا مجرّد «تحديث»
REFLECTION.md يدوّن شيئًا التقطته مراجعة التغيير

مسرد مصغّر

المصطلح	المعنى المبسّط
الإيداع (Commit)	نقطة حفظٍ لمشروعك في لحظةٍ زمنية.
الفرع (Branch)	خطّ عملٍ منفصل لا يؤثّر في `main` حتى يُدمج.
التغيير (Diff)	الأسطر المضافة والمحذوفة بالضبط في تغيير.
طلب الدمج (PR)	تغييرٌ مقترح يراجعه غيرك قبل دمجه — هنا، تراجع أنت تغيير الذكاء الاصطناعي.
.gitignore	قائمة ملفاتٍ يجب ألّا يتتبّعها Git (أسرار، مخرجات بناء).
Revert	إيداعٌ جديد يتراجع عن سابقٍ مع إبقاء التاريخ سليمًا.

الخلاصة وما التالي

صار لديك الآن

سير عمل Git نظيف — .gitignore، وفرعٌ لكل مرحلة، وإيداعاتٌ صغيرة أمينة، ومراجعة التغيير كطلب دمج — مع الشريحة الأولى من M1 (إنشاء + عرض) مبنيّةً ومُراجَعةً ومدموجةً في main يعمل.

التالي: الوحدة 5 — برمجة التطبيق بالإحساس. مع سير العمل جاهزًا، نُجري حلقة البناء الحقيقية — محوّلين بقيّة مراحلك إلى ميزاتٍ تعمل، مع التكرار السريع ومعرفة متى تُمسك زمام الأمور من المساعد بالضبط.