صار الموقع الشخصي على GitHub، وتصل التغييرات إلى main عبر الـ pull requests. يبقى سؤالان. كيف تتابع ما عليك فعله بعد ذلك، دون ورقة لاصقة على شاشتك؟ وكيف تساهم في مشروع لا تملكه، لا تستطيع فيه حتى رفع فرع؟ يجيب GitHub عن الأول بالـ issues والـ Projects، وعن الثاني بالـ forks.
الـ issue قطعة عمل متتبَّعة: خطأ، أو فكرة feature، أو سؤال. يحصل كل منها على رقم مشترك مع الـ pull requests (#12)، وسلسلة نقاش، وبيانات وصفية:
bug و enhancement و documentation و good first issue.في موقعك الشخصي، اكتب قائمة المهام على شكل 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/ ليملأ المبلِّغون هذه الأقسام تلقائيًا.
الـ GitHub Project عرض تخطيطي فوق الـ issues والـ pull requests، وقد تكون من عدة repositories. يبدأ جدولًا يشبه جداول البيانات؛ تضيف إليه حقولًا مخصّصة مثل Status و Priority و Size و Iteration، وتنتقل بين تخطيطات table (جدول) و board (لوحة بأعمدة بحسب Status، أي لوحة kanban المألوفة) و roadmap (العناصر على خط زمني). ويمكن لسير العمل المدمج (built-in workflows) أن ينقل العناصر تلقائيًا، مثلًا إلى Done حين تُغلق issue أو يُدمج pull request.
\nلموقع شخصي تعمل عليه وحدك، تكفي لوحة فيها Todo و In progress و Done. أما في الفريق، فالـ Project هو المكان الذي تجري فيه نقاشات التخطيط، والـ issues تحمل التفاصيل.
\nلنقل إنك وجدت خطأً إملائيًا في وثائق مكتبة ثيمات مفتوحة المصدر، open-themes/vite-themes. تستطيع استنساخها، لكنك لا تستطيع الرفع إليها: لست متعاونًا (collaborator) فيها، و git push يفشل بخطأ صلاحيات. هذا ما تحلّه الـ forks.
الـ fork نسختك الخاصة من الـ repository على GitHub، تحت حسابك: maya-okafor/vite-themes. تستطيع أن ترفع إليها أي شيء. وحين يجهز تغييرك، تفتح pull request من فرع في الـ fork الخاص بك إلى الـ repository الأصلي، الذي يُسمّى بحسب العُرف upstream.
هذا هو الروتين كاملًا:
\n# 1. Click Fork on github.com/open-themes/vite-themes, then clone YOUR fork\ngit clone git@github.com:maya-okafor/vite-themes.git\ncd vite-themes\n\n# 2. Remember where the original lives\ngit remote add upstream https://github.com/open-themes/vite-themes.git\ngit remote -v # origin = your fork, upstream = the original\n\n# 3. Work on a branch, never on main\ngit switch -c fix-readme-typo\ngit commit -am \"Fix typo in installation steps\"\ngit 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. هذا يسمح للمشرفين برفع إصلاحات صغيرة إلى فرعك بدل أن يطلبوا منك كل تعديل بسيط.
\nالأصل يواصل التقدّم. أدخِل تغييراته إلى الـ fork الخاص بك قبل أن تبدأ كل فرع جديد:
\ngit fetch upstream\ngit switch main\ngit merge --ff-only upstream/main\ngit 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 المركّز والموصوف جيدًا الذي يسهل قول «نعم» له هو أفضل تعريف بنفسك تستطيع تقديمه.
\nبهذا تكتمل أدوات التعاون. في القسم الأخير ستكتسب العادات التي تجعل كل هذا آمنًا: التراجع عن الأخطاء، وإبقاء الـ repository نظيفًا، وكتابة سجلّ يستطيع الناس قراءته، وترك الأتمتة تحرس main.
origin هو الـ fork الخاص بك و upstream هو الأصل؛ تنفّذ fetch من upstream وترفع إلى origin.","قبل المساهمة، اقرأ CONTRIBUTING.md، وابحث عن issue موجودة، وأبقِ التغيير صغيرًا وعلى فرعه الخاص."],"further":[{"title":"About issues","url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues"},{"title":"About Projects","url":"https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects"},{"title":"Fork a repository","url":"https://docs.github.com/en/pull-requests/how-tos/work-with-forks/fork-a-repo"},{"title":"Syncing a fork","url":"https://docs.github.com/en/pull-requests/how-tos/work-with-forks/syncing-a-fork"}],"quiz":[{"q":"استنسخت الـ fork الخاص بك من vite-themes. أيّ الأوامر تجلب أحدث main من المشروع الأصلي إلى main في الـ fork الخاص بك؟
git pull origin main","why":"origin هو الـ fork الخاص بك، وليست فيه الـ commits الجديدة بعد. ستسحب من النسخة المتأخّرة."},{"text":"git push upstream main","why":"لا تستطيع الرفع إلى الـ repository الأصلي، والرفع يرسل الـ commits الخاصة بك بدل أن يجلب الـ commits الخاصة بهم."},{"text":"git fetch upstream، ثم git switch main، ثم git merge --ff-only upstream/main، ثم git push origin main.","why":"صحيح. اجلب من الأصل، وقدّم main الخاص بك إليه بـ fast-forward، ثم حدّث الـ fork على GitHub. وزر Sync fork ينجز النصف الخاص بـ GitHub."},{"text":"استنسخ الأصل مرة أخرى بـ git clone في مجلد جديد.","why":"هذا ينجح لكنه يرمي إعدادك وفروعك. أما إضافة remote باسم upstream فتُبقي كل شيء في نسخة واحدة."}],"answer":2},{"q":"وجدت خطأً في مكتبة مفتوحة المصدر ولديك إصلاح في ذهنك يلمس ستة ملفات. ما الذي تفعله أولًا؟
","options":[{"text":"افتح pull request فورًا ليرى المشرفون كودًا يعمل.","why":"التغيير الكبير غير المعلَن قد يتصادم مع خطط لا تعرفها، وقد يُغلق دون أن يُقرأ."},{"text":"راسل المشرفين بالبريد على انفراد مرفقًا الـ patch.","why":"معظم المشاريع تنسّق في issues عامة ليراها الآخرون ويساعدوا. والبريد الخاص مخصّص لتقارير الأمان فقط، إن طلب المشروع ذلك."},{"text":"أنشئ fork للمشروع وانشر نسختك المُصلَحة باسم جديد.","why":"هذا يقسم المجتمع ويترك الجميع مع الخطأ. أما المساهمة بالإصلاح في الأصل فتفيد الجميع."},{"text":"اقرأ CONTRIBUTING.md وابحث في الـ issues؛ وإن لم تجد ما يغطّي المشكلة، افتح issue تصف الخطأ والإصلاح الذي تقترحه.","why":"صحيح. الاتفاق على الأسلوب أولًا يتجنّب العمل الضائع، وكثير من المشاريع تشترط وجود issue قبل الـ pull request."}],"answer":3},{"q":"ما الفرق بين الـ label والـ GitHub Project؟
","options":[{"text":"الـ labels تعمل على الـ pull requests فقط؛ والـ Projects تعمل على الـ issues فقط.","why":"الـ labels والـ Projects كلاهما يعملان مع الـ issues والـ pull requests."},{"text":"الـ label يوسم issue أو pull request منفردًا؛ أما الـ Project فعرض يشمل كثيرًا منها، بحقوله ولوحاته وتخطيطاته الخاصة.","why":"صحيح. الـ labels مثلbug تصنّف العناصر؛ والـ Project يرتّب العناصر (حتى من عدة repositories) في جدول أو لوحة أو خريطة طريق."},{"text":"إنهما الميزة نفسها باسمين مختلفين.","why":"الـ labels وسوم بسيطة على عناصر repository واحد. أما الـ Projects فتضيف حقولًا مخصّصة وطرق عرض وأتمتة عبر العناصر."}],"answer":1},{"q":"فتحت pull request من فرع main في الـ fork الخاص بك. وأثناء انتظار المراجعة، بدأت إصلاحًا لا علاقة له بالأول وسجّلته في commit على main أيضًا. ماذا يحدث؟
main الخاص بك.","why":"صحيح. الـ pull request يعرض كل commit على فرعه. أعطِ كل مساهمة فرعها الخاص لتبقى التغييرات منفصلة."},{"text":"لا شيء؛ فقد جمّد الـ pull request الـ commits الخاصة به حين فتحته.","why":"الـ pull requests تتبع فروعها، ولهذا يحدّثها الرفع إلى الفرع."},{"text":"يرفض GitHub الرفع لأن هناك pull request مفتوحًا.","why":"الـ pull requests المفتوحة لا تقفل فروعها. ينجح الرفع ويكبر الـ pull request."},{"text":"يذهب الـ commit الجديد إلى الـ repository الأصلي مباشرة.","why":"ليست لديك صلاحية الكتابة على الأصل. لا شيء يصل إليه إلا عبر pull request مدموج."}],"answer":0}],"exercise":{"kind":"choice","multiple":false,"options":["a","b","c","d"],"correct":["d"],"title":"ساهم بإصلاح لا تستطيع رفعه","prompt":"استنسخت open-themes/vite-themes مباشرة، وأصلحت خطأً إملائيًا على فرع اسمه fix-readme-typo، وشغّلت git push -u origin fix-readme-typo. فأجاب GitHub:
ERROR: Permission to open-themes/vite-themes.git denied to maya-okafor.\nfatal: Could not read from remote repository.ما الطريقة الصحيحة لإيصال إصلاحك إلى المشرفين دون إعادة العمل؟
\n","hints":["الخطأ لا يتعلّق بمفتاح SSH الخاص بك؛ فـ GitHub يعرف تمامًا من أنت.","تحتاج إلى نسخة من الـ repository على GitHub مسموح لك بالرفع إليها.","نسختك المحلية الحالية تستطيع التواصل مع أكثر من remote."],"explanation":"ليست لديك صلاحية الكتابة على open-themes/vite-themes، لذا لن تجعل أي بيانات اعتماد هذا الرفع ينجح. أنشئ له fork على GitHub، فيُنشأ maya-okafor/vite-themes. وفي نسختك المحلية الحالية، أعد تسمية origin الحالي إلى upstream (git remote rename origin upstream) وأضف الـ fork الخاص بك باسم origin (git remote add origin git@github.com:maya-okafor/vite-themes.git). ثم نفّذ git push -u origin fix-readme-typo وافتح pull request من فرع الـ fork إلى main في الأصل. ويُعاد استخدام الـ commit الخاص بك كما هو.
git push --force -u origin fix-readme-typo.","why":"القوة تغيّر طريقة الكتابة فوق الفرع، لا كونك مسموحًا لك بالكتابة. سيظل الرفع مرفوضًا."},"c":{"text":"راسل المشرفين واطلب منهم إضافتك كمتعاون لتستطيع رفع فرعك.","why":"لا يمنح المشرفون صلاحية الكتابة من أجل إصلاح خطأ إملائي. والـ forks موجودة لكي يستطيع أي شخص المساهمة دونها."},"d":{"text":"أنشئ له fork على GitHub، واجعل الأصل upstream والـ fork الخاص بك origin في هذه النسخة، وارفع الفرع إلى الـ fork، وافتح pull request إلى الأصل.","why":"صحيح. الـ fork الخاص بك repository تستطيع الرفع إليه، والـ pull request منه هو الطريقة التي تصل بها التغييرات إلى مشروع لا تملكه."}}},"words":747,"readMinutes":4}