من لا يعرف Git إطلاقاً إلى من يفتح طلب دمج حقيقيّاً على مستودع عامّ، في جلسة واحدة _لا تحتاج خبرة سابقة. تحتاج فقط أن تكتب كلّ أمر بيدك، وأن تُخطئ في ساحة آمنة قبل أن تلمس مستودعاً حقيقيّاً_

Cybersecurity Bootcamp، Phase 1: Red Team Foundations فصل مهاراتيّ يفتح الجزء الثاني من الكابستون. لا يفترض أيّ معرفة سابقة بـ Git. تُنجزه على جهازك وعلى حسابك في GitHub.

كيف تقرأ هذا المستند

هذا ليس فصلاً نظريّاً. كلّ قسم فيه أوامر تكتبها بنفسك في الطرفيّة، ونُريك المخرج المتوقّع بعد كلّ أمر لتُقارن. أمامك ساحتا تدريب: مستودع تجريبيّ محلّيّ تصنعه بـ git init وتُخطئ فيه بلا خوف لأنّه لا يُنشر لأحد، ثمّ نسختك من مستودع الـ keylogger الحقيقيّ، حيث تُنفّذ الجزء الثاني من الكابستون فعلاً.

كالعادة: النصّ عربيّ RTL، الأوامر إنجليزيّة LTR، والمصطلحات القصيرة (commit, branch, fork) داخل جمل عربيّة بين backticks. لا تنسخ الأوامر لصقاً: اكتبها حرفاً حرفاً، فالكتابة باليد تُرسّخ الأمر أعمق من قراءته.

جدول المحتويات

قبل أن تبدأ: ما تحتاجه جاهزاً

لا تحتاج أن تُتقن C++ لتُنجز الجزء الثاني من الكابستون: تحسين في README، أو تعليق أوضح، أو إضافة ملف .gitignore كلّها مساهمات مقبولة. المطلوب أن تُتقن الطريق إلى الـ Pull Request، لا أن تكتب رقعةً عبقريّة.

القسم 0القسم 0: ما Git وما GitHub، ولماذا يهمّان مهاجماً

قبل أوّل أمر، ثبّت الفكرتين، فالخلط بينهما هو أكثر ما يُربك المبتدئ.

Git أداة تعيش على جهازك: آلة زمن لملفّاتك. تلتقط لقطات (commits) لحالة مشروعك، فتستطيع أن تعود إلى أيّ لقطة، وأن ترى من غيّر ماذا ومتى ولماذا. تعمل بلا إنترنت تماماً، وهي منفصلة عن أيّ موقع.

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

ولماذا يهمّ هذا مهاجماً؟ لأنّ أدوات الفريق الأحمر الحقيقيّة تُطوّر وتُقرأ وتُراجَع مثل أيّ برمجيّة أخرى. من يقرأ تاريخ مستودع يفهم كيف نضجت الأداة وأين مواطن ضعفها. ومن يستطيع فتح Pull Request يستطيع أن يُصلح ويُساهم ويعمل داخل فريق. في هذا الفصل تنتقل من مهاجم يستهلك الأدوات إلى مهندس يبنيها. هذا نصف الكابستون الآخر.

جرّب: افتح طرفيّة، واسأل عن نسخة Git:

git --version

إن ظهر سطر مثل git version 2.43.0 فـ Git مثبّت، انتقل للقسم 2. وإن ظهر command not found أو is not recognized فلم يُثبّت بعد: القسم 1 يُثبّته.

✅ اختبر نفسك: القسم 0

1. بجملة واحدة لكلٍّ منهما: ما الفرق بين Git وGitHub؟
2. هل تستطيع استعمال Git بلا إنترنت؟ ولماذا؟
3. ما Pull Request بكلماتك أنت؟

القسم 1القسم 1: التثبيت والإعداد لأوّل مرّة

خطوتان: نُثبّت الأداة، ثمّ نُعرّفها بمن أنت وكيف تدخل إلى GitHub.

تثبيت Git

• Windows: الأسهل عبر winget install --id Git.Git، أو نزّل المثبّت من https://git-scm.com. أبقِ الخيارات الافتراضيّة.
• macOS: شغّل xcode-select --install، أو brew install git إن كان لديك Homebrew.
• Linux: sudo apt install git على دبيان وأوبنتو، أو ما يعادلها في توزيعتك.

افتح طرفيّة جديدة بعد التثبيت وأعِد git --version لتتأكّد.

الإعداد لأوّل مرّة: من أنت

كلّ التزام يحمل اسم صاحبه وبريده. عرّف نفسك مرّةً واحدةً لكلّ الجهاز:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --list          # تحقّق: يظهر اسمك وبريدك في القائمة

الدخول إلى GitHub ليعمل push

حتّى تستطيع الدفع إلى نسختك على GitHub، تحتاج طريقة استيثاق. اختر واحدة:

• الأسهل، أداة GitHub الرسميّة: ثبّت gh (على Windows: winget install GitHub.cli)، ثمّ:

gh auth login          # اختر: GitHub.com، ثمّ HTTPS، ثمّ الدخول عبر المتصفّح

• البديل، رمز وصول شخصيّ (PAT): أنشئ رمزاً من https://github.com/settings/tokens، وحين يطلب git كلمة المرور عند أوّل push، الصق الرمز مكانها.

ملاحظة أمان: الـ PAT كلمة مرور كاملة. لا تكتبه داخل كود، ولا ترفعه إلى مستودع، ولا تُشاركه. لو تسرّب، ألغِه فوراً من الصفحة نفسها.

✅ اختبر نفسك: القسم 1

1. لماذا يطلب Git اسمك وبريدك على كلّ التزام؟
2. ما الذي ينكسر لو لم تُعدّ الاستيثاق؟ في أيّ خطوة يظهر الخلل؟
3. أين تُخزَّن إعدادات --global، وهل تُطبَّق على كلّ مستودعاتك أم على واحد؟

القسم 2القسم 2: النموذج الذهنيّ، الدليل العامل ثمّ التجهيز ثمّ الالتزام ثمّ التاريخ

أكثر ما يُربك المبتدئ أنّه يظنّ الملفّ إمّا محفوظاً أو لا. في Git الملفّ يمرّ بأربع مناطق، وفهمها يُنهي نصف الحيرة:

• الدليل العامل (Working Directory): ملفّاتك كما تراها الآن، تُعدّل فيها بحرّيّة.
• منطقة التجهيز (Staging): ما اخترته ليدخل اللقطة القادمة. تُرقّي إليها بـ git add.
• التاريخ (Commits): لقطات مُثبّتة لا تتغيّر. تُنشئها بـ git commit.
• والأفعال التي تُحرّك الملفّ بين المناطق: status يُريك أين كلّ ملفّ، وadd يُجهّز، وcommit يُثبّت، وlog يعرض التاريخ.

لنُجرّب كلّ ذلك في مستودع تجريبيّ لا يُنشر لأحد، فالخطأ فيه بلا ثمن:

mkdir git-sandbox
cd git-sandbox
git init                   # أنشأنا مستودعاً فارغاً هنا
echo "أوّل سطر" > notes.txt
git status                 # تحقّق: notes.txt بالأحمر، غير متعقّب (Working Directory)
git add notes.txt
git status                 # تحقّق: أخضر الآن، مُجهّز (Staging)
git commit -m "إضافة ملفّ الملاحظات الأوّل"
git log --oneline          # تحقّق: التزامك الأوّل يظهر في التاريخ

لاحظ: الرسالة بعد -m تشرح لماذا لا ماذا. git يعرف أنّك عدّلت الملفّ، لكنّه لا يعرف سبب التعديل. الرسالة الجيّدة هدية لك بعد ثلاثة أشهر.

✅ اختبر نفسك: القسم 2

1. في أيّ منطقة يكون الملفّ بعد add وقبل commit؟
2. ماذا يحفظ commit بالضبط: الملفّ كلّه أم فرق التعديل؟
3. لماذا "fix" رسالة التزام سيّئة؟ اكتب بديلاً أفضل لتصحيح خطأ مطبعيّ.

القسم 3القسم 3: Clone مقابل Fork، ما الفرق ومتى

هنا المفهوم الذي يحتاجه الجزء الثاني من الكابستون بالضبط، فتمهّل فيه:

• Fork نسختك أنت من مستودع غيرك على GitHub. تحتاجها لأنّك لا تملك صلاحيّة الدفع إلى مستودع لا تملكه. الـ fork تُنشأ على الموقع بنقرة، وتصبح ملكك تدفع إليها كما تشاء.
• Clone تنزيل أيّ مستودع من GitHub إلى جهازك لتعمل عليه محلّيّاً.
• القاعدة الذهبيّة: افعل fork أوّلاً على الموقع، ثمّ clone لنسختك أنت، لا للأصل.

بعد الاستنساخ يصير عندك مرجعان بعيدان: origin يشير إلى نسختك (تدفع إليها)، وupstream يشير إلى المستودع الأصليّ (تسحب منه التحديثات). نُضيف upstream بأنفسنا.

جرّب: ادخل إلى https://github.com/HashHashBit/Keylogger4 واضغط زرّ Fork أعلى اليمين. بعد أن تصير النسخة في حسابك، انزل إلى الطرفيّة:

git clone https://github.com/<اسم-حسابك>/Keylogger4.git
cd Keylogger4
git remote -v                                                   # تحقّق: origin يشير إلى نسختك أنت
git remote add upstream https://github.com/HashHashBit/Keylogger4.git
git remote -v                                                   # تحقّق: upstream يشير إلى الأصل

انتبه: فرع هذا المستودع الافتراضيّ اسمه master لا main. ستستعمل master في أوامر الدفع والمزامنة في هذا الفصل. لكلّ مستودع فرعه الافتراضيّ، فاقرأ قبل أن تفترض.

✅ اختبر نفسك: القسم 3

1. لا تملك صلاحيّة الدفع إلى المستودع الأصليّ. كيف يحلّ الـ fork هذه المشكلة؟
2. ما الفرق بين origin وupstream؟
3. لو استنسختَ الأصل مباشرةً بدل نسختك، في أيّ خطوة لاحقة ستصطدم بالجدار؟

القسم 4القسم 4: دورة التعديل، تعديل ثمّ add ثمّ commit ثمّ push

هذه هي الحلقة اليوميّة، لكنّها الآن تدفع إلى مستودع حقيقيّ على GitHub (نسختك). لنبدأ بتعديل بسيط وآمن على README:

الخطوة أ: تأكّد أنّك على الفرع الافتراضيّ ومُحدَّث:

git switch master
git pull origin master     # اجلب آخر ما في نسختك

الخطوة ب: افتح README.md بمحرّرك، وأضف سطراً مفيداً أو أصلح خطأً واضحاً، ثمّ احفظ.

الخطوة ج: جهّز التعديل، ثبّته، وادفعه:

git add README.md
git commit -m "توثيق: توضيح خطوة التصريف في README"
git push origin master     # تحقّق: افتح نسختك على GitHub، سترى التزامك الجديد

ما لم تدفعه لا يراه أحد على GitHub. الالتزام وحده يبقى على جهازك حتّى يصل push.

✅ اختبر نفسك: القسم 4

1. ما الذي يظهر على GitHub بعد push فقط، ولم يكن ظاهراً بعد commit؟
2. لماذا نفصل add عن commit، ولا نجعلهما أمراً واحداً؟
3. نسيتَ -m. ماذا يحدث، وكيف تخرج من المحرّر الذي يفتحه Git؟

القسم 5القسم 5: الفروع، إنشاء وتبديل

لا تعمل مساهمتك على master مباشرةً. الفرع مسار جانبيّ آمن، تعمل فيه بمعزل، ثمّ يصير طلب دمج واحداً. لو أفسدتَ شيئاً، الفرع الرئيس سليم.

تحتاج ثلاثة أوامر فقط: git switch -c يُنشئ فرعاً وينتقل إليه، وgit switch ينتقل بين الفروع، وgit branch يعرضها ويُري أين أنت.

جرّب داخل نسختك من Keylogger4:

git switch -c fix/readme-typo    # أنشئ فرعاً جديداً وانتقل إليه دفعةً واحدة
git branch                       # تحقّق: النجمة (*) على الفرع الجديد
# عدّل ملفّاً واحفظه، ثمّ:
git add -A
git commit -m "إصلاح خطأ مطبعيّ في قسم الإعداد"
git switch master                # عُد إلى الرئيس: تعديلك ليس هنا
git switch fix/readme-typo        # ارجع إلى فرعك: تعديلك هنا

✅ اختبر نفسك: القسم 5

1. لماذا نفتح فرعاً بدل الالتزام على master مباشرةً؟
2. ماذا تعني النجمة * في مخرج git branch؟
3. بدّلتَ إلى master فاختفى تعديلك من الملفّات. هل ضاع؟ أين هو؟

القسم 6القسم 6: التدفّق الكامل، من fork إلى Pull Request مدموج

هذا القسم يجمع كلّ ما سبق في التسليم الحقيقيّ: مساهمة فعليّة في مستودع الـ keylogger عبر طلب دمج. أيّ تحسين حقيقيّ، ولو بسيطاً، يجتاز الجزء الثاني من الكابستون.

الخطوة أ: انطلق من فرع نظيف باسم يصف فكرتك:

git switch master
git fetch upstream
git merge upstream/master        # ابدأ من أحدث نسخة من الأصل
git switch -c improve/clearer-usage

الخطوة ب: اصنع تحسيناً حقيقيّاً صغيراً. أفكار آمنة لا تتطلّب خبرة عميقة بـ C++:

• تعليق أوضح يشرح ماذا يفعل جزء من keylogger_edu.cpp.
• إضافة ملفّ .gitignore يتجاهل مخرجات التصريف (*.exe, *.o).
• تصحيح أو توسيع README.md بخطوات التصريف والتشغيل.
• راجع تبويب Issues في المستودع: فيه مشكلة مفتوحة قد تكون نقطة انطلاقك.

الخطوة ج: ثبّت التحسين وادفعه إلى فرعك على نسختك:

git add -A
git commit -m "تحسين: وصف أوضح لوسائط التشغيل في README"
git push origin improve/clearer-usage

الخطوة د: على GitHub سيظهر زرّ Compare & pull request. اضغطه، تأكّد أنّ الوجهة هي HashHashBit/Keylogger4 فرع master، اكتب عنواناً ووصفاً يشرحان ماذا غيّرت ولماذا، ثمّ Create pull request.

الخطوة هـ، الردّ على المراجعة: حين يُعلّق المُشرف طالباً تعديلاً، لا تفتح طلباً جديداً. عدّل على الفرع نفسه، ثمّ:

git add -A
git commit -m "مراجعة: تسمية المتغيّر أوضح كما طُلب"
git push origin improve/clearer-usage   # يتحدّث طلب الدمج نفسه تلقائيّاً

الخطوة و، مزامنة نسختك مع الأصل قبل أيّ عمل جديد، حتّى لا تبني فوق نسخة قديمة:

git switch master
git fetch upstream
git merge upstream/master        # تحقّق: نسختك صارت محدّثةً مع الأصل
git push origin master

هذا هو الجزء الثاني من الكابستون فعلاً. حين يُفتح طلب الدمج ويظهر رابطه، انسخ الرابط لتسليمه. المطلوب أن تُثبت إتقان التدفّق: fork ثمّ branch ثمّ commit ثمّ push ثمّ Pull Request. عبقريّة الرقعة ليست الهدف.

✅ اختبر نفسك: القسم 6

1. بعد فتح طلب الدمج، كيف تُضيف تعديلاً طلبه المُراجع دون فتح طلب جديد؟
2. لماذا نُزامن مع upstream قبل بدء عمل جديد؟
3. ما الذي يجب أن يتضمّنه وصف طلب الدمج الجيّد؟

القسم 7القسم 7: الخلاصة وورقة الأوامر والجسر إلى الكابستون

وصلتَ من صفر إلى طلب دمج مفتوح على مستودع عامّ. راجع ما أتقنتَه:

• ثبّتَ Git وعرّفت نفسك، وأعددتَ الدخول إلى GitHub.
• فهمتَ المناطق الأربع: الدليل العامل، التجهيز، الالتزام، التاريخ.
• فرّقتَ بين clone وfork، وأضفتَ origin وupstream.
• فرّعتَ، والتزمتَ، ودفعتَ، وفتحتَ طلب دمج، وحدّثتَه بعد المراجعة، وزامنتَ نسختك.

ورقة الأوامر السريعة

لكنّك ما زلت في البداية

هذا الفصل هو الحدّ الأدنى لتُساهم بثقة، لا خريطة Git الكاملة. تركنا عمداً rebase وcherry-pick وstash وtags وحلّ التعارضات المعقّدة، لأنّها ليست ضروريّةً لأوّل طلب دمج. حين تحتاجها ستعرف أنّك تحتاجها، وتتعلّمها حينها.

🧭 ما التالي

الآن نفّذ الجزء الثاني من الكابستون: افتح الكابستون، ثمّ اذهب إلى مستودع الـ keylogger، اعمل fork، وافتح طلب دمج حقيقيّاً بتحسين تختاره أنت. سلّم رابط الطلب.

وتذكّر القاعدة نفسها التي تحكم كلّ ما تتعلّمه هنا: تعلّم الطريق حتّى تستطيع إغلاقه.