Git وGitHub: شبكة الأمان لمشروعك

في مقال جافاسكربت صار مشروعك كيانًا حيًّا يتفاعل مع المستخدم، فصارت له قيمةٌ حقيقية. ومع القيمة تأتي أسئلةٌ احترافية: ماذا لو أردت تجربة فكرةٍ جريئةٍ دون أن تخشى تدمير عملك؟ ماذا لو أخطأت وتمنّيت لو تعود بالزمن إلى إصدارٍ كان يعمل؟ وكيف تعرض تطوّر مهاراتك لأصحاب العمل لاحقًا؟ هنا يتوقّف دور الحرفيّ ويبدأ دور المهندس. وأداتانا لذلك هما Git وGitHub.

ما Git؟ آلة الزمن لمشروعك

Git «نظام تحكّمٍ بالإصدارات» (Version Control System).^[1] فكّر فيه سجلًّا دقيقًا لكل ملفٍّ في مشروعك. وخلافًا للحفظ التقليديّ الذي يبقي النسخة الأخيرة فقط، يحفظ Git «لقطةً» (snapshot) كاملةً لمشروعك في كل مرّةٍ تطلب منه، وكل لقطةٍ إصدارٌ كاملٌ تعود إليه متى شئت. إنه آلة زمنٍ تتنقّل بها بحرّيةٍ عبر تاريخ مشروعك.

وما يجعله ثوريًّا أنه نظامٌ «موزّع» (Distributed). الأنظمة القديمة كانت مركزية: خادمٌ واحدٌ يحمل تاريخ المشروع، وإن تعطّل توقّف العمل. أمّا في Git فيحمل حاسوبك نسخةً كاملةً مستقلّةً من تاريخ المشروع كلّه، فتحفظ الإصدارات وتنشئ الفروع وتراجع التاريخ دون اتّصالٍ بالإنترنت. كل مطوّرٍ يملك آلة زمنٍ خاصّةً به، ثمّ يزامنون خطوطهم الزمنية معًا. هذا ما يمنحك الثقة لتجرّب، لأن لديك دائمًا نقطة عودةٍ آمنة.

ولعلّك تسأل: ألا يكفي أن أحفظ ملفّاتي وأنسخ المجلّد كل حين؟ تأمّل الفوضى التي يقع فيها من يفعل ذلك: مجلّدٌ باسم «مشروع»، وآخر «مشروع نهائيّ»، وثالث «مشروع نهائيّ٢ الأخير فعلًا». لا تعرف ما الفرق بينها، ولا متى تغيّر ماذا ولماذا، وإذا أرسلت نسخةً لزميلٍ وعدّل فيها بينما عدّلت في نسختك صار دمج العملين كابوسًا يدويًّا. Git يحلّ هذا كلّه: سجلٌّ تاريخيٌّ يوضّح لماذا تغيّر كل شيء، وشبكة أمانٍ تعيدك إلى أيّ لحظةٍ كان المشروع يعمل فيها، وحرّية تجربةٍ عبر الفروع، وأساسٌ متينٌ للعمل الجماعيّ. هو الفرق بين العمل العشوائيّ الذي يخشى صاحبه كل تغيير، والممارسة الهندسية المنضبطة التي تتحرّك بثقة.

تاريخ Git: وُلد من رحم الحاجة

قصّة ولادته تفسّر قوّته. بطلها Linus Torvalds، صانع نظام التشغيل لينكس. كان مشروع نواة لينكس، أحد أكبر المشاريع مفتوحة المصدر، يعتمد على نظامٍ تجاريٍّ اسمه BitKeeper، فلمّا صار غير مجّانيٍّ سنة 2005 وجد Torvalds وفريقه العالميّ نفسه في مأزق: لا بديل يلبّي متطلّباتهم الصارمة من سرعةٍ فائقة، ونظامٍ موزّعٍ لا يعتمد على خادمٍ مركزيّ، وأمانٍ مطلقٍ للشيفرة. فقرّر أن يبني الأداة بنفسه، وطوّر النسخة الأولى من Git في أسبوعين فقط في أبريل 2005.^[2] لهذا تجده سريعًا كفؤًا قويًّا: لم يُصنَع في شركةٍ للربح، بل بناه أحد أعظم مهندسي البرمجيات لحلّ أصعب مشكلات التطوير التعاونيّ.

كيف يعمل Git؟ المناطق الثلاث

يفكّر Git في بياناته سلسلة لقطاتٍ لا مجرّد «تغييرات». وقد تظنّ التقاط صورةٍ كاملةٍ في كل مرّةٍ مهدرًا للمساحة، لكنّ عبقريته أنه إن لم يتغيّر ملفٌّ بين لقطتين، لم يخزّنه ثانيةً بل خزّن رابطًا للنسخة السابقة، فصار سريعًا فعّالًا. ولإدارة هذه اللقطات يقسّم عملك ثلاث مناطق، وفهمها هو مفتاح إتقانه.

مجلّد العمل (Working Directory): مجلّد مشروعك الفعليّ على حاسوبك، ما تراه في مستكشف VS Code. هو أستوديو إبداعك حيث تنشئ الملفّات وتكتب وتجرّب، وحالته حيّةٌ متغيّرة، وقد تكون فوضويةً أحيانًا، وهذا طبيعيّ. ويراقب Git هذه المنطقة ليرى ما تغيّر منذ آخر لقطة.

منطقة التجهيز (Staging Area): أهمّ منطقةٍ وأقلّها فهمًا، وهي سرّ قوّة Git. لماذا خطوةٌ إضافيةٌ قبل الحفظ؟ لتصنع «التزاماتٍ ذرّية» نظيفة. تخيّل أنك خلال ساعةٍ أصلحت خطأً في script.js، وأضفت قسمًا في index.html، وصحّحت خطأً إملائيًّا في style.css. بلا منطقة التجهيز تحفظ هذا الخليط في لقطةٍ واحدةٍ برسالةٍ مربكةٍ مثل «عدّلت أشياء». أمّا بها فتختار بدقّة الجرّاح، عبر git add، تعديلات إصلاح الخطأ وحدها وتحفظها برسالةٍ واضحة، ثمّ تجهّز الباقي منفصلًا. إنها مسودّة لقطتك التالية، تصنع بها تاريخًا نظيفًا منطقيًّا.

المستودع (Repository): المجلّد المخفيّ .git داخل مشروعك، وهو قاعدة بياناتٍ كاملةٌ تحمل كل لقطةٍ حفظتها. وحين تلتزم (commit) لا تحفظ الملفّات فقط، بل لقطةً مع بياناتٍ وصفية: معرّفٌ فريد (hash)، والمؤلّف والتاريخ، ورسالتك الواصفة، ومؤشّرٌ للّقطة السابقة (وهذا ما يشكّل «التاريخ»). وكونه موزّعًا يعني أن هذا الأرشيف كلّه يُنسَخ على حاسوب كل مطوّر. فسير عملك خطواتٌ منظّمة: مجلّد العمل، ثمّ التجهيز عبر git add، ثمّ المستودع عبر git commit.

ما GitHub؟ منزل مشروعك على السحابة

إن كان Git محرّك السيّارة الذي يدير كل شيءٍ محليًّا، فإن GitHub هو مرآبها الآمن وحلبة سباقها وناديها الاجتماعيّ على الإنترنت. هو خدمةٌ تستضيف مستودعات Git، لكنه أكثر من تخزين، ووظائفه ثلاث.^[3] الأولى الخزنة الآمنة: حين «تدفع» (push) شيفرتك إليه تضع نسخةً احتياطيةً سحابيةً كاملة، فلو تعطّل حاسوبك أو سُرق بقي عملك آمنًا. والثانية مركز التعاون، وهو قوّته الحقيقية: يوفّر «طلبات السحب» (Pull Requests) التي تعرض بها عملك على الفريق لمراجعته قبل دمجه، و«إدارة المشكلات» (Issues) لتتبّع الأخطاء وتنظيم المهامّ. والثالثة معرض أعمالك: صار ملفّك على GitHub سيرتك الذاتية التقنية، وأوّل ما يطلبه مدير التوظيف غالبًا رابطُ حسابك ليرى مشاريعك وجودة شيفرتك وطريقة تفكيرك.

باختصار: Git أداتك التي تدير بها عملك، وGitHub منصّتك التي تحمي بها عملك وتعرضه. وللعلم، استحوذت مايكروسوفت على GitHub سنة 2018. وهو الأشهر، لكن له بدائل قويةً تؤدّي الدور نفسه مثل GitLab وBitbucket.

تثبيت Git وضبط هويتك

على ويندوز نزّل المثبّت الرسميّ من git-scm.com واترك الإعدادات الافتراضية كما هي (هي ممتازة)، ثمّ افتح Git Bash. وعلى ماك يأتي Git مثبّتًا غالبًا، وإلّا فسيعرض النظام تثبيت «أدوات سطر الأوامر» حين تكتب أوّل أمر، أو ثبّته بـbrew install git. وعلى لينكس من الطرفية مباشرةً:

sudo apt install git      # دِبيان/أوبونتو
sudo dnf install git      # فيدورا

تحقّق من التثبيت في كل الأنظمة بكتابة git --version في الطرفية؛ فإن ظهر لك رقم الإصدار فقد نجح التثبيت وصار Git جاهزًا للعمل. وثمّة خطوةٌ يغفلها كثيرٌ من الشروحات لكنّها إلزاميةٌ مرّةً واحدة: عرّف Git بهويتك، فهو يضع اسمك وبريدك على كل التزامٍ تحفظه. اكتب مرّةً على جهازك:

git config --global user.name "اسمك"
git config --global user.email "[email protected]"

إعداد حساب GitHub

التسجيل مجّانيٌّ وسريع: توجّه إلى github.com، وانقر «Sign up»، وأدخل بريدًا صالحًا وكلمة مرورٍ قوية، واختر اسم مستخدمٍ احترافيًّا (سيصير جزءًا من سيرتك التقنية، فاختر ما يعكس هويتك). ثمّ أكّد بريدك عبر رابط التحقّق الذي يصلك. وبهذا صار لك منزلٌ على السحابة وبوّابةٌ إلى مجتمع المطوّرين العالميّ، حيث تستطيع لاحقًا أن تطّلع على شيفرة مشاريع كبرى مفتوحة المصدر، وأن تساهم فيها بنفسك، وهي من أنفع طرق التعلّم على الإطلاق: أن تقرأ كيف يكتب المحترفون.

التطبيق العملي: مشروعك تحت إدارة Git

لنضع مشروعك (index.html وstyle.css وscript.js) تحت إدارةٍ احترافية. افتح مجلّد المشروع في VS Code، ثمّ افتح الطرفية المدمجة بـCtrl+`؛ فوجودها داخل المحرّر يجعل سير العمل سلسًا.

أوّلًا، أخبر Git أن يبدأ بتتبّع هذا المجلّد بـgit init، فينشئ المجلّد المخفيّ .git (عقل مشروعك؛ لا تعدّله يدويًّا أبدًا). ثمّ افحص الحالة بأهمّ أمرٍ تشخيصيّ، git status، فتجد ملفّاتك «غير متتبّعة» (Untracked) بالأحمر، أي «أراها لكنّي لا أتتبّعها بعد».

للحفظ الأوّل خطوتان: جهّز كل الملفّات بـgit add . (النقطة تعني «أضِف كل شيءٍ هنا»؛ ولو أعدت git status لرأيتها خضراء جاهزة)، ثمّ احفظ اللقطة دائمًا برسالةٍ واصفة:

git init
git add .
git commit -m "Initial commit: HTML, CSS, and JavaScript files"

ورسالة الالتزام ليست تفصيلًا شكليًّا. اكتبها واضحةً تصف ما فعله الالتزام، بصيغة الأمر القصيرة (مثل «أصلح خطأ زرّ الدخول» لا «أصلحت بعض الأشياء»)؛ فبعد ستّة أشهرٍ ستشكر نفسك حين تتصفّح تاريخك فتفهم كل خطوةٍ من رسالتها. ولتستعرض هذا التاريخ في أيّ وقتٍ، اكتب git log، فيعرض لك كل التزامٍ بمعرّفه ومؤلّفه وتاريخه ورسالته، فترى مسار مشروعك كاملًا.

وتذكّر فلسفة منطقة التجهيز: لست مضطرًّا إلى git add . دائمًا. تستطيع تجهيز ملفٍّ بعينه بكتابة اسمه (git add index.html)، فتجمع في كل التزامٍ التغييرات المترابطة وحدها. وقبل أن تجهّز، يريك git diff بالضبط ما تغيّر في ملفّاتك سطرًا سطرًا منذ آخر لقطة، فتراجع عملك قبل أن تحفظه. هذه العادة، أن تنظر إلى ما تغيّر قبل أن تلتزم به، تميّز المطوّر المنضبط.

وقبل أن نرفع: لا تتتبّع كل شيء. بعض الملفّات لا مكان لها في المستودع، كمجلّد node_modules الضخم الذي مرّ بك في مقال تجهيز البيئة، أو ملفّات الإعدادات السرّية. تنشئ لذلك ملفًّا اسمه .gitignore تكتب فيه أسماء ما تريد أن يتجاهله Git، فلا يرفعه ولا يتتبّعه.

الآن أنشئ المستودع البعيد: في GitHub انقر «New»، وسمّ المستودع (مثل my-first-website)، واتركه عامًّا (Public) ليكون جزءًا من معرضك، ولا تضِف README أو gitignore الآن، ثمّ «Create repository».

يعرض GitHub الآن أوامر «بناء الجسر» بين مستودعك المحلّيّ والبعيد. انسخها أو اكتبها: الأوّل يضيف اتّصالًا بالمستودع البعيد ويسمّيه origin (الاسم المتعارف عليه)، والثاني يرفع التزاماتك من فرعك المحلّيّ main إلى ذلك الاتّصال:

git remote add origin https://github.com/YourUsername/my-first-website.git
git push -u origin main

حدّث صفحة مستودعك على GitHub، فتجد كل ملفّاتك هناك. لقد وضعت مشروعك على منصّةٍ عالمية، وصار له تاريخٌ موثّق. وهذا المستودع البعيد يصير لاحقًا مصدرًا للنشر أيضًا: كثيرٌ من منصّات الاستضافة الحديثة تسحب شيفرتك من مستودع Git مباشرةً لتبنيها في بيئة اختبارٍ قبل دفعها إلى الموقع الحيّ.

دورة العمل اليومية

الإعداد الأوّل هو الأصعب، أمّا العمل اليوميّ فحلقةٌ بسيطةٌ من ثلاث خطواتٍ تصير طبيعةً لك. تعدّل ملفًّا (غيّر نصّ <h1> مثلًا وتحفظ)، ثمّ تجهّز وتحفظ اللقطة محليًّا، ثمّ ترفعها:

git add .
git commit -m "Update main heading in header"
git push

لاحظ أن الرفع صار git push وحده، لأنك ربطت الفرع بالمستودع البعيد في الإعداد الأوّل. هذه الدورة (تعديل، ثمّ commit محلّيّ، ثمّ push سحابيّ) هي جوهر سير العمل اليوميّ لأيّ مطوّرٍ يستعمل Git.

الاتّجاه الآخر: الاستنساخ والجلب

رفعتَ من المحلّيّ إلى البعيد، لكن العمل يسير في الاتّجاهين. حين تريد نسخ مشروعٍ موجودٍ على GitHub إلى جهازك (مشروعك من جهازٍ آخر، أو مشروعٌ مفتوح المصدر تشارك فيه)، تستعمل git clone متبوعًا برابط المستودع، فينزّله بكل تاريخه. وحين تعمل في فريقٍ ويرفع زميلٌ تغييراتٍ إلى المستودع البعيد، تجلبها إلى جهازك بـgit pull، فيدمج عملهم في نسختك. هكذا تكتمل دورة التعاون: تدفع عملك بـpush، وتجلب عمل غيرك بـpull.

وأوّل ملفٍّ يراه زائر مستودعك هو README.md: صفحةٌ تعرّف بمشروعك، تشرح ما يفعل وكيف يُشغَّل. اعتد على كتابة README واضحٍ لكل مشروع، فهو واجهة عملك ومن أوّل ما ينظر إليه من يقيّم مهاراتك.

وكتبتُ هذه الأوامر في الطرفية لأنها تعلّمك ما يجري فعلًا، لكن اعلم أن لها بديلًا رسوميًّا: قسم «التحكّم بالمصادر» في VS Code (مرّ بك في مقاله) يتيح التجهيز والالتزام والدفع والتبديل بين الفروع بالنقر، ويعرض تغييراتك بصريًّا. كثيرٌ من المحترفين يخلطون بينهما: الطرفية للدقّة والأوامر المتقدّمة، والواجهة الرسومية للعمليات اليومية السريعة. أتقن الأوامر أوّلًا لتفهم ما تفعله الواجهة، ثمّ استعمل ما يريحك.

آلة الزمن عمليًّا: التراجع وإصلاح الأخطاء

وصفتُ Git آلة زمنٍ وشبكة أمان، لكن كيف تستعملها فعلًا حين تخطئ؟ هذه أكثر اللحظات التي يخاف منها المبتدئ، وفيها يظهر معنى الأمان. لنأخذ ثلاث حالاتٍ شائعة.

الأولى: عبثت بملفٍّ في مجلّد العمل وتريد إلغاء تعديلاتك غير المحفوظة والعودة إلى آخر لقطة. يردّ git restore <اسم الملفّ> الملفّ إلى حالته في آخر التزام، فكأن عبثك لم يكن. والثانية: جهّزت ملفًّا بـgit add ثمّ غيّرت رأيك قبل الالتزام؛ يخرجه git restore --staged <اسم الملفّ> من منطقة التجهيز دون أن يمسّ محتواه. والثالثة، وهي الأهمّ: التزامٌ قديمٌ أفسد شيئًا وتريد التراجع عنه. هنا git revert آمنٌ وأنيق: لا يمحو التاريخ، بل ينشئ التزامًا جديدًا يلغي أثر القديم، فيبقى سجلّك صادقًا يحكي ما جرى فعلًا.

وحين تريد فقط أن «تنظر» كيف كان مشروعك في لحظةٍ ماضية، يأخذك git checkout <معرّف الالتزام> إلى تلك اللقطة لتتصفّحها، ثمّ تعود إلى حاضرك بـgit switch main. هذه هي آلة الزمن التي وعدتُك بها: لا تفقد شيئًا، بل تتنقّل في تاريخك بثقة. والدرس الأعمق: مع Git قلّما يكون الخطأ نهائيًّا، وهذا بالضبط ما يحرّرك لتجرّب.

وملاحظةٌ عملية أوّل مرّةٍ ترفع فيها: سيطلب منك GitHub إثبات هويتك. لم يَعُد يقبل كلمة المرور العادية عند الرفع، بل تستعمل إمّا «رمز وصولٍ شخصيًّا» (Personal Access Token) بدل كلمة المرور، أو تُعِدّ «مفتاح SSH» مرّةً واحدةً فيتعرّف عليك جهازك تلقائيًّا في كل رفعٍ بعده. الثاني أريح على المدى الطويل، وستلتقي بـSSH بتوسّعٍ حين تصل إلى إدارة الخوادم.

القوة الحقيقية: الفروع

حتى الآن كان العمل كلّه على خطٍّ زمنيٍّ واحد. لكن ماذا لو أردت العمل على ميزةٍ كبيرةٍ لست واثقًا من نجاحها؟ أتخاطر بإفساد مشروعك المستقرّ؟ هنا يأتي سحر Git الحقيقيّ: «التفريع» (Branching).^[4] الفرع عالمٌ موازٍ من مشروعك: نسختك الرسمية تعيش على فرعٍ اسمه main، وحين تنشئ فرعًا جديدًا تنسخ مشروعك في تلك اللحظة لتجرّب فيه بحرّيةٍ دون أن تمسّ main بشيء. (وقد ترى الفرع الرئيسيّ باسم master في مشاريع أقدم؛ هو الاسم القديم نفسه، وقد صار main الافتراضيّ في GitHub والأدوات الحديثة).

وسير العمل الاحترافيّ ثلاث خطوات. أوّلًا فرّع: قبل مهمّةٍ جديدةٍ أنشئ فرعًا وصفيًّا وانتقل إليه. ثانيًا احفظ: نفّذ عملك والتزاماتك على هذا الفرع بينما يبقى main نظيفًا. ثالثًا ادمج: إذا اكتملت الميزة واختبرتها، دمجت الفرع في main فصارت جزءًا من المشروع الرسميّ. والأوامر:

git switch -c feature/contact-form   # أنشئ فرعًا وانتقل إليه
# ... عملك والتزاماتك هنا ...
git switch main                       # عُد إلى الفرع الرئيسيّ
git merge feature/contact-form        # ادمج الميزة فيه

وقد تسمع عن «تعارض الدمج» (merge conflict): يحدث حين يعدّل فرعان السطر نفسه تعديلين مختلفين، فلا يعرف Git أيّهما يبقي، فيتوقّف ويطلب منك أن تقرّر. لا تَخَف منه؛ هو ليس خطأً بل سؤالٌ من Git يحدّد لك موضعه بدقّةٍ في الملفّ لتختار بين النسختين أو تدمجهما يدويًّا. مع الممارسة يصير حلّه روتينًا عاديًّا.

ولماذا هذا مهمٌّ إلى هذا الحدّ؟ لأنه يمنحك التجربة الآمنة: إن فشلت فكرةٌ حذفت فرعها وكأنّ شيئًا لم يكن. وهو أساس التعاون الجماعيّ: خمسة مطوّرين يعملون على المشروع نفسه، كلٌّ على ميزةٍ في فرعه، دون أن يتدخّل أحدٌ في عمل الآخر، ثمّ تُدمَج الفروع. بهذا صار لديك صندوق أدوات المطوّر الحديث الكامل: تحفظ التاريخ، وتدير خطوطًا زمنيةً متعدّدة، وتطوّر الميزات بأمانٍ ونظام.

وعلى هذه الأركان يقوم سير عمل المصادر المفتوحة الذي مرّ ذكره. حين تريد المساهمة في مشروعٍ لا تملكه، «تستنسخ نسخةً» منه إلى حسابك (تُسمّى Fork)، فتصير لك نسختك الكاملة. تعمل فيها على فرعٍ خاصّ، ثمّ تفتح «طلب سحبٍ» (Pull Request) إلى المشروع الأصليّ يقول لصاحبه: «أضفت هذا، فهل تراجعه وتدمجه؟». فيراجع مشرفو المشروع تغييرك ويناقشونه، وإن قبلوه صار جزءًا من المشروع وحُسبت لك مساهمتك. هكذا يتعاون آلاف الغرباء على مشروعٍ واحدٍ بنظامٍ لا فوضى فيه، وهكذا بُنيت أعظم البرمجيات الحرّة في العالم، ومنها لينكس نفسه.

صار لمشروعك سجلّ، فكيف يكلّم غيره؟

بوصولك إلى هنا اكتسبت مهارةً تفصل المحترف عن الهاوي. مشروعك لم يعد ملفّاتٍ على حاسوبك، بل كيانًا مُدارًا محميًّا له تاريخٌ كامل، يعيش على المنصّة التي يستعملها ملايين المطوّرين. وتعلّمت ليس كيف تستعمل Git وGitHub فحسب، بل لماذا هما لا غنى عنهما: شبكة أمانٍ تمنحك ثقة التجربة، وأساسٌ للتعاون في مشاريع أكبر. صارت بين يديك حلقة العمل كلّها: init وadd وcommit وpush، وlog وdiff لمراجعة عملك، وclone وpull للتعاون، والفروع للتجربة الآمنة. لا تحتاج إتقانها كلّها اليوم؛ ستترسّخ بالتكرار في كل مشروعٍ تبنيه.

ومشروعك الآن لا يعيش وحده. التطبيقات الحديثة تتحدّث مع خدماتٍ أخرى باستمرار: تجلب بيانات الطقس، وتعرض خريطة، وتسجّل دخولك بحسابٍ آخر. كيف تتفاهم هذه البرامج المختلفة فيما بينها؟ عبر «واجهات برمجة التطبيقات». وهذا موضوع مقالنا التالي: «واجهة برمجة التطبيقات (API): كيف تتحدّث البرامج بعضها إلى بعض».

المصادر

1. Pro Git: ما هو Git (الكتاب الرسميّ). نظام تحكّمٍ موزّعٌ يخزّن لقطاتٍ لا فروقات.
2. Pro Git: تاريخ Git. نشأته على يد لينوس تورفالدس سنة 2005 بعد أزمة BitKeeper.
3. GitHub Docs: عن GitHub وGit. الاستضافة والتعاون عبر طلبات السحب والمشكلات.
4. Pro Git: الفروع في Git. مفهوم التفريع وسير عمل فرّع-احفظ-ادمج.