سير العمل التعاوني

للعمل جماعة على مستودع، يوجد نموذجان كبيران للتعاون. الاختيار يعتمد أساساً على من له حق الكتابة في المستودع.

في الشركة نستخدم تقريباً دائماً الفرع المشترَك (رأيناه في الدروس 01–03). للمساهمة في مشروع مفتوح المصدر ولست عضواً فيه، نمرّ بـ fork.

الـ fork نسخة شخصية من مستودع على حسابك في GitHub. تملك فيه كل الحقوق، دون المساس بالأصل. أما الـ clone فينزّل مستودعاً على جهازك المحلي.

لا تخلط :

# 1. الـ fork عبر زر Fork على GitHub (أو CLI)
gh repo fork projet/app --clone

# المكافئ اليدوي بعد fork:
# 2. استنساخ الـ fork الخاص بك
git clone https://github.com/vous/app.git
cd app

# 3. التحقق من الـ remote
git remote -v
# origin  https://github.com/vous/app.git (fetch/push)

الـ fork «صندوق رمل» لك: يمكنك كسر كل شيء بلا خطر على المشروع الأصلي. عندما يصبح عملك جاهزاً، يقترحه طلب سحب على المشرف، الذي يقرر قبوله.

تمرين مصغّر — بـ gh، انسخ مستودع projet/app (fork) واستنسخه على جهازك بأمر واحد.

أثناء عملك، يتطوّر المستودع الأصلي. لا يتحدّث الـ fork وحده. يجب إضافة remote اسمه upstream يشير إلى الأصل، ثم استرجاع تغييراته بانتظام.

# 1. إعلان المستودع الأصلي باسم upstream
git remote add upstream https://github.com/projet/app.git

# 2. استرجاع آخر تغييراته
git fetch upstream

# 3. تحديث main المحلي
git switch main
git merge upstream/main

# 4. الدفع نحو الـ fork الخاص بك
git push origin main

المزامنة المبكرة والمتكررة مع upstream تمنع «انحراف» الـ fork عن المشروع. كلما انتظرت أكثر، كثرت التعارضات يوم طلب السحب.

تمرين مصغّر — اكتب الأمر لإعلان المستودع الأصلي https://github.com/projet/app.git كـ remote باسم upstream.

القضية (issue) تذكرة: مكان للإبلاغ عن خطأ، أو اقتراح ميزة، أو طرح سؤال. هو نظام المتابعة لمشروع GitHub.

ما نضعه في قضية خطأ جيدة :

# إنشاء قضية من الطرفية
gh issue create --title "انهيار عند النقر على تصدير" \
  --body "الخطوات: 1) افتح X 2) انقر تصدير ← يغلق التطبيق."

# سرد القضايا المفتوحة
gh issue list

# ربط طلب سحب بقضية: في وصف طلب السحب
#   Closes #42   ← يغلق القضية 42 تلقائياً عند الدمج

التسميات تنظّم القضايا: bug، enhancement، documentation، good first issue، help wanted…

تحوّل القضايا جملة «ينبغي تصحيح هذا يوماً» إلى مهام قابلة للتتبّع والنقاش. ربط طلب سحب بـ Closes #N يغلق القضية تلقائياً عند الدمج: صفر نسيان.

تمرين مصغّر — بـ gh، أنشئ قضية عنوانها «انهيار عند النقر على تصدير».

أبعد من الأوامر، يقوم التعاون الفعّال على اتفاقيات مشتركة. هذه التي تصنع الفرق.

معيار « Conventional Commits »، الشائع جداً :

git commit -m "feat: إضافة تصدير CSV"
git commit -m "fix: يصحّح انهيار تسجيل الدخول"
git commit -m "docs: تحديث README"
git commit -m "refactor: يبسّط خدمة الدفع"

فريق يتقاسم الاتفاقيات لا يحتاج إلى التشاور بلا توقف: الشفرة والإيداعات والفروع «تتكلم» اللغة نفسها. هذه سيولة التعاون.

تمرين مصغّر — أضفت للتو تصدير CSV. اكتب رسالة الإيداع بصيغة Conventional Commits.

السؤال 1: ما الـ fork؟

a) دمج فرعين

b) نسخة شخصية من مستودع على حسابك في GitHub

c) نوع تعارض

d) حذف السجل

السؤال 2: ما الفرق بين origin و upstream في نموذج fork و pull؟

a) لا فرق، هما مترادفان

b) origin هو الـ fork الخاص بك، و upstream هو المستودع الأصلي

c) origin محلي، و upstream على قرصك

d) upstream يُستخدم لحذف الفروع

السؤال 3: لماذا تُستخدم القضية؟

a) لتجميع الشفرة

b) للإبلاغ عن خطأ، أو اقتراح ميزة، أو مناقشة مهمة

c) لدمج الفروع تلقائياً

d) لاستنساخ مستودع

السؤال 4: ماذا يفعل Closes #42 في وصف طلب سحب؟

a) يحذف الإيداع 42

b) يغلق القضية #42 تلقائياً عند دمج طلب السحب

c) يفتح قضية جديدة

d) يلغي طلب السحب

السؤال 5: ماذا تعني بادئة الإيداع fix: في Conventional Commits؟

a) ميزة جديدة

b) تصحيح خطأ

c) توثيق

d) اختبار

المطلوب

تريد المساهمة في مشروع مفتوح المصدر projet/app ولست عضواً فيه. نفّذ دورة نموذج fork و pull كاملة :

1. انسخ المستودع (fork) واستنسخه.
2. أضف الـ remote upstream وزامن main.
3. أنشئ فرعاً، نفّذ إيداعاً (يصحّح القضية #8) وادفعه نحو الـ fork.
4. افتح طلب سحب نحو المستودع الأصلي مع ربط القضية.

التصحيح

# 1. fork + استنساخ
gh repo fork projet/app --clone
cd app

# 2. إضافة upstream والمزامنة
git remote add upstream https://github.com/projet/app.git
git fetch upstream
git switch main
git merge upstream/main
git push origin main

# 3. التفريع، الإيداع، الدفع
git switch -c fix/correction-typo-readme
# ... تصحيح ملف README ...
git commit -am "fix: يصحّح خطأ في README"
git push -u origin fix/correction-typo-readme

# 4. فتح طلب سحب نحو المستودع الأصلي
gh pr create --repo projet/app \
  --base main --head vous:fix/correction-typo-readme \
  --title "fix: خطأ مطبعي في README" \
  --body "يصحّح زلة. Closes #8"

النتيجة المتوقعة :

$ git remote -v
origin    https://github.com/vous/app.git (push)
upstream  https://github.com/projet/app.git (fetch)

ينطلق طلب السحب من فرعك (vous:fix/...) نحو main للمستودع الأصلي. يراجعه المشرف ويقرر الدمج: ساهمت في المصدر المفتوح دون أن تملك يوماً حق كتابة على المشروع.

النقاط التي يجب تذكّرها

1. نموذجان: الفرع المشترَك (فريق داخلي) و fork و pull (مصدر مفتوح).
2. Fork = نسخة على حسابك؛ clone = نسخة على جهازك.
3. origin = الـ fork الخاص بك؛ upstream = المستودع الأصلي للمزامنة المنتظمة.
4. القضايا تتتبّع الأخطاء والأفكار والمهام؛ Closes #N يربط ويغلق عند الدمج.
5. ممارسات جيدة: إيداعات واضحة، فروع قصيرة، طلبات صغيرة، main مستقر.
6. Conventional Commits (feat:، fix:، docs:…) توحد الرسائل.

ما يلي

انتهت الوحدة 02: تعرف الآن التفريع والدمج وفتح طلبات السحب والتعاون على نطاق واسع. الوحدة 03 تواصل مسار DevOps مع التكامل المستمر (CI/CD)، الذي سيؤتمت الاختبارات والنشر انطلاقاً من طلبات السحب نفسها.