تنظيم العمل الجماعي على مشروع التخرج باستخدام Git

قد يعدّل عضوان السطر نفسه لسببين مختلفين، وقد يندمج تعديلان دون تعارض نصي ثم تتعطل وظيفة يعتمد أحدهما عليها. لهذا يحتاج فريق المشروع إلى مهام محددة ومراجعة للمتطلبات والاختبارات، إلى جانب Git. سنتابع فرعين في نظام حجز قاعات، ونرى كيف يُحسم التعارض بحسب القاعدة المعتمدة وكيف يُفحص الدمج بعده.

اتفقوا على وحدة عمل قابلة للإنهاء

قسّموا المهمة بحسب سلوك يمكن تجربته: منع حجز متداخل، أو تصفية القاعات، أو عرض موعد الحجز. لكل مهمة وصف قصير ومعيار قبول ومسؤول واحد عن دمجها. يمكن أن يشارك أكثر من شخص في التنفيذ، لكن وضوح المسؤول يمنع بقاء تغييرات معلقة يفترض كل عضو أن الآخر راجعها.

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

ابدأ الفرع من حالة معروفة

git switch main
git pull --ff-only
git switch -c feature/booking-overlap
git status
# Edit the booking rule and its tests.
git add src/booking.js tests/booking.test.js
git commit -m "Reject overlapping room bookings"
git push -u origin feature/booking-overlap

الأسماء هنا افتراضية وتتكيف مع ملفات المشروع الفعلية. اقرأ git status قبل تبديل الفرع أو السحب. إذا وجدت تعديلات محلية لم تُحفظ، أكملها أو احفظها بطريقة واعية قبل متابعة الدمج. لا تستخدم reset --hard أو دفعًا قسريًا لمعالجة موقف لم تفهمه.

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

تعارض لا يُحل باختيار جانب آليًا

افترض أن السطر الأصلي هو const maxMinutes = 60;. غيّره فرع إلى 90 لطلب المستخدم، وغيّره آخر إلى 120 لاختبار واجهة. عند الدمج قد ترى:

<<<<<<< HEAD
const maxMinutes = 90;
=======
const maxMinutes = 120;
>>>>>>> feature/booking-feedback

الأرقام افتراضية، وليست سياسة جامعة. اقرأ تذكرة المتطلب: إذا كان الحد المعتمد 90، احتفظ به وحدّث اختبار الواجهة ليستخدم القيمة المعتمدة. لا تختَر الطرف الأحدث لمجرد أنه أحدث. أزل علامات التعارض، وابحث عن استخدام القيمة في الواجهة والخادم، ثم اختبر حجزًا يساوي الحد وحجزًا يتجاوزه.

git diff
git add src/booking.js
git commit
git status

إذا لم يكن القرار واضحًا، أوقف الدمج وناقش مالك المتطلب. ويمكن الرجوع من محاولة دمج لم تُستكمل باستخدام git merge --abort بعد التأكد من حالة المستودع. إلغاء المحاولة لا يغني عن فهم التعديلات المحلية التي كانت موجودة قبلها.

ما الذي يراجعه الزميل؟

1. هل يحقق التغيير معيار القبول المذكور، بما فيه مسار الفشل؟
2. هل يفرض الخادم قاعدة الحجز، أم اكتفت الواجهة بتعطيل زر؟
3. هل تغير عقد API أو مخطط البيانات ويتطلب تحديثًا متوافقًا؟
4. هل توجد أسرار أو ملفات تشغيل مولدة لا مكان لها في المستودع؟
5. هل يستطيع عضو آخر تشغيل الاختبار من README؟

لا يعني نجاح الدمج صحة النتيجة؛ Git يقارن النصوص ولا يقرر قواعد العمل. راجع أيضًا التعارضات المنطقية: فرع يغيّر اسم حقل وآخر يضيف تقريرًا يعتمد اسمه القديم قد يندمجان دون علامات، ثم يفشل التقرير أثناء التشغيل.

أعيد سيناريو التعارض في مستودع محلي مستقل باستخدام Git 2.51.0: بدأ حد الحجز بقيمة 60، ثم عدله الفرعان إلى 90 و120، فتوقف الدمج بتعارض. وبعد اعتماد 90 وإكمال الدمج عادت حالة المستودع نظيفة. هذا يختبر مسار Git النصي فقط؛ صحة قاعدة العمل واختبارات التطبيق تبقى مسؤولية المشروع الذي يطبقها.

حوّل سجل Git إلى دليل للتسليم

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