الوحدة الرابعة: التعاون الاحترافي وطلبات السحب والتسميات (PRs)

في هذه الوحدة، ننتقل لما هو أبعد من مجرد "كود" وندخل عالم التطوير الاجتماعي. منصة GitHub ليست مجرد مخزن ملفات؛ إنها منصة تواصل، والقلب النابض لهذه المنصة هو طلب السحب (Pull Request - PR).

1. اتفاقيات التسمية الاحترافية (Conventional Commits)

تتبع معظم الفرق الاحترافية مواصفات Conventional Commits. يوفر هذا النمط مجموعة بسيطة من القواعد لإنشاء تاريخ "التزامات" (commits) واضح ومنظم.

هيكل الرسالة:

<النوع>(<نطاق-اختياري>): <الوصف>

[جسم الرسالة - اختياري]

[التذييل - اختياري]

أشهر أنواع الـ Commits

يجب عليك استخدام هذه الأنواع لتصنيف تغييراتك:

النوع	متى تستخدمه؟	مثال
feat	ميزة جديدة للمستخدم	feat(api): add jwt authentication
fix	إصلاح خطأ (Bug)	fix(ui): resolve login button overlap
docs	تغييرات في التوثيق فقط	docs: update readme with setup guide
style	تغييرات في تنسيق الكود (فراغات، فاصلة منقوطة...) دون تغيير المعنى	style: run prettier on all files
refactor	تعديل الكود لتحسين جودته دون إصلاح خطأ أو إضافة ميزة	refactor: simplify database connection logic
perf	تغيير في الكود لتحسين الأداء (أسرع، ذاكرة أقل)	perf: reduce image load time by 40%
test	إضافة اختبارات (tests) أو تصحيحها	test: add unit tests for user service
build	تغييرات تؤثر على نظام البناء أو المكتبات الخارجية	build: upgrade vite to version 5.0
ci	تغييرات في ملفات وإعدادات الـ CI (مثل GitHub Actions)	ci: add github actions for linting
chore	تغييرات عامة لا تعدل في الكود البرمجي أو الاختبارات	chore: update .gitignore
revert	للتراجع عن commit سابق	revert: feat: add social login

---

2. تسمية الفروع (Branches) باحترافية

لا تستخدم أبداً أسماء مثل test أو fix أو my-branch. الفرق الاحترافية تستخدم هيكلية تشبه المجلدات:

• feature/: للميزات الجديدة، مثل feature/user-profiles
• bugfix/: لإصلاح الأخطاء البرمجية، مثل bugfix/sidebar-mobile-glitch
• hotfix/: للإصلاحات العاجلة جداً في النظام الفعلي (Production)
• docs/: لتعديلات التوثيق، مثل docs/api-documentation
• refactor/: لتعديلات تحسين جودة الكود، مثل refactor/clean-up-utils

---

3. تشريح طلب السحب المثالي

في الفرق الاحترافية، "مجرد فتح طلب سحب" لا يكفي. الـ PR هو العرض التقديمي لعملك.

أ. العنوان (The Title)

يجب أن يتبع عنوان الـ PR نمط Conventional Commits (تماماً مثل رسائل الالتزام الخاصة بك).

• ✅ feat(auth): add google oauth2 provider
• ❌ تعديل الدخول

ب. الوصف (لماذا فعلت ذلك؟)

المبرمجون مشغولون دائماً، لا تجعلهم يحزرون ما قمت به. الوصف الجيد يشمل:

• الملخص: ما هي المشكلة التي يحلها هذا الكود؟
• كيفية الاختبار: خطوات محددة للمراجع ليجرب الكود بنفسه.
• المرئيات: إذا كان التغيير في الواجهة (UI)، فإنه من الضروري إرفاق صور أو صور متحركة (GIFs)!
• الربط: اربط الـ PR بالمهمة التي يحلها (مثلاً: Closes #123).

---

4. عملية مراجعة الكود (Code Review)

مراجعة الكود ليست "بحثاً عن الأخطاء" فحسب؛ بل هي تبادل للمعرفة وحفاظ على الجودة.

للمؤلف (أنت):

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

للمراجع (زملاؤك في الفريق):

1. كن لطيفاً: استخدم صيغة الجمع "نحن" بدلاً من "أنت" (مثلاً: "هل يمكننا تغيير اسم هذا المتغير؟" بدلاً من "لقد سميت هذا المتغير خطأ").
2. حدد الأهمية: هل ملاحظتك هي مجرد "تدقيق بسيط" (Nitpick) أم "مانع للدمج" (Blocker) بسبب مشكلة أمنية أو منطقية؟
3. الثناء: إذا كان الكود ممتازاً، قل ذلك! "عمل رائع" أو استخدام الرموز التعبيرية (Emojis) مهم جداً للروح المعنوية.

---

5. التعامل مع التعديلات المطلوبة

بعد المراجعة، قد تجد حالة "Requested Changes".

1. أضف commits جديدة: لا تحمل هماً، لا تحتاج لفتح PR جديد. فقط قم بعمل commits إضافية على نفس الفرع وارفعها، وسيتحدث الـ PR تلقائياً.
2. إنهاء المحادثات: بمجرد إصلاح التغيير المطلوب، قم بوضع علامة "Resolved" على المحادثة في GitHub.

---

6. المسودات (Draft Pull Requests)

أحياناً تريد الحصول على رأي فريقك قبل أن تنتهي تماماً من العمل.

• استخدم خاصية Draft Pull Request على GitHub.
• هذا يخبر فريقك: "أنا أعمل على هذا، لا تترددوا في إلقاء نظرة، لكن لا تدمجوه بعد".

---

7. استراتيجيات الدمج (Merging)

بعد الموافقة على الـ PR، كيف ينضم لفرع main؟

• Create a Merge Commit: يحافظ على التاريخ الكامل لكل خطوة قمت بها.
• Squash and Merge: يدمج كل الـ commits التجريبية الخاصة بك في commit واحد نظيف. (الفرق الاحترافية تفضل هذا للحفاظ على نظافة تاريخ الفرع الرئيسي).
• Rebase and Merge: ينقل التزاماتك إلى قمة الفرع الرئيسي دون إنشاء commit دمج.

IMPORTANT

قاعدة اجتماعية: لا تقم أبداً بدمج الـ PR الخاص بك بنفسك إلا إذا كنت تعمل وحيداً. انتظر دائماً الموافقة أو كلمة "LGTM" (تبدو جيدة بالنسبة لي) من زميلك.

---

ماذا بعد؟

أنت الآن تعرف كيف تتعاون كالمحترفين. في الوحدة الأخيرة، سنلخص كل شيء ونلقي نظرة على "سكين الجيش السويسري" لأوامر Git لإصلاح الأخطاء.