الـ Issues والـ Projects والـ Forks والمصادر المفتوحة

صار الموقع الشخصي على GitHub، وتصل التغييرات إلى main عبر الـ pull requests. يبقى سؤالان. كيف تتابع ما عليك فعله بعد ذلك، دون ورقة لاصقة على شاشتك؟ وكيف تساهم في مشروع لا تملكه، لا تستطيع فيه حتى رفع فرع؟ يجيب GitHub عن الأول بالـ issues والـ Projects، وعن الثاني بالـ forks.

الـ Issues: عمل يمكنك الإشارة إليه

الـ issue قطعة عمل متتبَّعة: خطأ، أو فكرة feature، أو سؤال. يحصل كل منها على رقم مشترك مع الـ pull requests (#12)، وسلسلة نقاش، وبيانات وصفية:

• Labels (الوسوم) تصنّفها: bug و enhancement و documentation و good first issue.
• Assignees (المكلَّفون) يبيّنون من يعمل عليها.
• Milestones (المحطّات) تجمع الـ issues نحو هدف، مثل “Launch v1”.

في موقعك الشخصي، اكتب قائمة المهام على شكل issues: “Projects page: filter by tag (#12)” و “Footer overlaps content on mobile (#13)”. ثم يسمّي كل pull request الـ issue الخاصة به بـ Closes #12، فيُغلقها الدمج، وبعد ستة أشهر يستطيع أي شخص أن يتتبّع الأثر من سطر كود إلى الـ commit، فالـ pull request، فالنقاش، فالسبب الأصلي.

تقرير الخطأ الجيد فيه خطوات لإعادة إنتاجه، وما كنت تتوقّعه، وما حدث، والمتصفّح أو الإصدار. ويمكن للـ repositories أن تضيف قوالب issues في .github/ISSUE_TEMPLATE/ ليملأ المبلِّغون هذه الأقسام تلقائيًا.

الـ Projects: اللوحة فوق الـ issues

الـ GitHub Project عرض تخطيطي فوق الـ issues والـ pull requests، وقد تكون من عدة repositories. يبدأ جدولًا يشبه جداول البيانات؛ تضيف إليه حقولًا مخصّصة مثل Status و Priority و Size و Iteration، وتنتقل بين تخطيطات table (جدول) و board (لوحة بأعمدة بحسب Status، أي لوحة kanban المألوفة) و roadmap (العناصر على خط زمني). ويمكن لسير العمل المدمج (built-in workflows) أن ينقل العناصر تلقائيًا، مثلًا إلى Done حين تُغلق issue أو يُدمج pull request.

لموقع شخصي تعمل عليه وحدك، تكفي لوحة فيها Todo و In progress و Done. أما في الفريق، فالـ Project هو المكان الذي تجري فيه نقاشات التخطيط، والـ issues تحمل التفاصيل.

الـ Forks: المساهمة دون صلاحية كتابة

لنقل إنك وجدت خطأً إملائيًا في وثائق مكتبة ثيمات مفتوحة المصدر، open-themes/vite-themes. تستطيع استنساخها، لكنك لا تستطيع الرفع إليها: لست متعاونًا (collaborator) فيها، و git push يفشل بخطأ صلاحيات. هذا ما تحلّه الـ forks.

الـ fork نسختك الخاصة من الـ repository على GitHub، تحت حسابك: maya-okafor/vite-themes. تستطيع أن ترفع إليها أي شيء. وحين يجهز تغييرك، تفتح pull request من فرع في الـ fork الخاص بك إلى الـ repository الأصلي، الذي يُسمّى بحسب العُرف upstream.

هذا هو الروتين كاملًا:

# 1. Click Fork on github.com/open-themes/vite-themes, then clone YOUR fork
git clone git@github.com:maya-okafor/vite-themes.git
cd vite-themes

# 2. Remember where the original lives
git remote add upstream https://github.com/open-themes/vite-themes.git
git remote -v    # origin = your fork, upstream = the original

# 3. Work on a branch, never on main
git switch -c fix-readme-typo
git commit -am "Fix typo in installation steps"
git push -u origin fix-readme-typo

بعدها يعرض GitHub خيار “Compare & pull request” على الـ fork الخاص بك. تحقّق من أن الـ repository الأساسي هو open-themes/vite-themes وأن الفرع الأساسي هو main الخاص بهم. واختصار الخطوتين 1 و 2 في الـ CLI هو gh repo fork open-themes/vite-themes --clone، وهو يُعدّ لك أيضًا الـ remote المسمّى upstream.

اترك “Allow edits by maintainers” محدَّدًا حين تفتح الـ pull request. هذا يسمح للمشرفين برفع إصلاحات صغيرة إلى فرعك بدل أن يطلبوا منك كل تعديل بسيط.

إبقاء الـ fork محدَّثًا

الأصل يواصل التقدّم. أدخِل تغييراته إلى الـ fork الخاص بك قبل أن تبدأ كل فرع جديد:

git fetch upstream
git switch main
git merge --ff-only upstream/main
git push origin main

لأنك لا تنشئ commits أبدًا على main في الـ fork، فهذا دائمًا fast-forward. زر Sync fork في صفحة الـ fork على GitHub، أو gh repo sync maya-okafor/vite-themes، يحدّث النسخة الموجودة على GitHub؛ ولا يزال عليك أن تسحبها محليًا. (أما gh repo sync دون وسيط فيحدّث نسختك المحلية بدلًا من ذلك.)

أن تكون مساهمًا مرحَّبًا به

قبل كتابة الكود، اقرأ ملف README الخاص بالمشروع وملف CONTRIBUTING.md (الإعداد، والاختبارات، والأسلوب، وهل تُشترط issue أولًا) ومدوّنة السلوك. ابحث في الـ issues والـ pull requests الموجودة؛ فربما يكون خطؤك معروفًا أو مُصلَحًا. ولأي شيء أكبر من خطأ إملائي، افتح issue أو علّق على واحدة، واتّفق مع المشرفين على الأسلوب قبل كتابة الكود. والـ issues التي تحمل الوسم good first issue مختارة عمدًا كنقاط بداية.

ثم أبقِ الـ pull request صغيرًا، واتبع أعراف المشروع حتى حيث كنت ستختار خلافها، وتأكّد من نجاح اختباراته، وأجب عن تعليقات المراجعة بصبر. المشرفون متطوّعون في الغالب. والـ pull request المركّز والموصوف جيدًا الذي يسهل قول «نعم» له هو أفضل تعريف بنفسك تستطيع تقديمه.

بهذا تكتمل أدوات التعاون. في القسم الأخير ستكتسب العادات التي تجعل كل هذا آمنًا: التراجع عن الأخطاء، وإبقاء الـ repository نظيفًا، وكتابة سجلّ يستطيع الناس قراءته، وترك الأتمتة تحرس main.