Git و GitHub: الدليل الشامل لفهم نظام التحكم بالإصدارات وأسرار التعاون البرمجي

مقدمة: فك الغموض عن Git و GitHub

هل سبق لك أن شعرت بالحيرة حول كيفية عمل كل من Git و GitHub؟ لا تقلق، لست وحدك. قد يكون التعامل مع Git و GitHub معقدًا في بعض الأحيان، ولكن بنهاية هذا المقال، ستكون قد اكتسبت فهمًا عميقًا لكليهما. في البداية، قد يميل البعض إلى الاعتقاد بأن Git و GitHub هما الشيء نفسه، ولكن في الواقع، هما ليسا كذلك. بل من الممكن تمامًا استخدام Git دون الحاجة إلى GitHub! وفي نهاية المطاف، كل منهما يخدم أغراضًا مختلفة تمامًا.

سيبدأ هذا المقال باستعراض دقيق لأغراض كل من Git و GitHub. بعد ذلك، سنتعرف على الفروقات الرئيسية بين هاتين التقنيتين الحيويتين. دون مزيد من الإطالة، دعنا نبدأ مع Git.

ما هو Git؟

Git هو نظام تحكم بالإصدارات موزع (Distributed Version Control System - DVCS) يُستخدم لحفظ إصدارات مختلفة من ملف (أو مجموعة ملفات)، بحيث يمكن استرداد أي إصدار في أي وقت. يسهل Git أيضًا تسجيل ومقارنة إصدارات الملفات المختلفة. هذا يعني أن التفاصيل حول ما تغير، ومن قام بالتغيير، أو من بدأ مشكلة معينة، يمكن مراجعتها في أي وقت. ولكن إذا كان Git نظام تحكم بالإصدارات موزعًا، فماذا تعني هذه المصطلحات بالضبط؟

ماذا يعني مصطلح "موزع" (Distributed)؟

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

إذن، "موزع" يعني توزيع جميع إصدارات ملفات المشروع التي سجلها Git، وليس فقط عددًا قليلاً ومحددًا. ولكن ما هو نظام التحكم بالإصدارات بالضبط؟

ما هو نظام التحكم بالإصدارات (Version Control System)؟

يشير نظام التحكم بالإصدارات (VCS) إلى الطريقة المستخدمة لحفظ إصدارات الملفات للرجوع إليها مستقبلاً. بشكل بديهي، يقوم العديد من الأشخاص بالفعل بالتحكم في إصدارات مشاريعهم عن طريق إعادة تسمية الإصدارات المختلفة من نفس الملف بطرق متنوعة مثل blogScript.js، و blogScript_v2.js، و blogScript_v3.js، و blogScript_final.js، و blogScript_definite_final.js، وما إلى ذلك. ولكن هذا النهج عرضة للأخطاء وغير فعال لمشاريع الفرق. كما أن تتبع ما تغير، ومن قام بتغييره، ولماذا تم تغييره، هو مسعى شاق باستخدام هذا النهج التقليدي. وهذا يوضح أهمية نظام تحكم بالإصدارات موثوق وتعاوني مثل Git. ومع ذلك، للحصول على أفضل النتائج من Git، من الضروري فهم كيفية تعامله مع ملفاتك.

حالات الملفات في Git

في Git، هناك ثلاث حالات رئيسية (ظروف) يمكن أن يكون عليها الملف:

• حالة التعديل (modified state): ملف تم تعديله ولكنه لم يتم الالتزام به (تسجيله) بعد. بعبارة أخرى، الملفات في حالة التعديل هي ملفات قمت بتعديلها ولكنك لم توجه Git صراحة لمراقبتها.
• حالة التجهيز (staged state): ملفات معدلة تم اختيارها – في حالتها (إصدارها) الحالي – ويتم تحضيرها لحفظها (الالتزام بها) في مستودع .git خلال لقطة الالتزام التالية. بمجرد أن يتم تجهيز الملف، فهذا يعني أنك قد سمحت لـ Git صراحة بمراقبة إصدار هذا الملف.
• حالة الالتزام (committed state): ملفات تم تخزينها بنجاح في مستودع .git. وبالتالي، فإن الملف الملتزم به هو ملف قمت بتسجيل إصداره المجهز في دليل Git (المجلد).

ملاحظة: تحدد حالة الملف الموقع الذي سيضع فيه Git الملف.

مواقع الملفات في Git

هناك ثلاثة أماكن رئيسية قد توجد فيها إصدارات الملف أثناء التحكم بالإصدارات باستخدام Git:

• مجلد العمل (working directory): هو مجلد محلي لملفات المشروع. هذا يعني أن أي مجلد يتم إنشاؤه في أي مكان على النظام هو مجلد عمل.

ملاحظة: الملفات في حالة التعديل (modified state) توجد في مجلد العمل. يختلف مجلد العمل عن دليل .git. أي أنك تقوم بإنشاء مجلد عمل بينما يقوم Git بإنشاء دليل .git.

• منطقة التجهيز (staging area): تُسمى تقنيًا "الفهرس" (index) في مصطلحات Git، وهي ملف، عادةً ما يكون موجودًا في دليل .git، ويخزن معلومات حول الملفات التالية التي سيتم الالتزام بها في دليل .git.

ملاحظة: الملفات في حالة التجهيز (staged state) توجد في منطقة التجهيز.

• دليل Git (Git directory): هو المجلد (ويُسمى أيضًا "المستودع" repository) الذي ينشئه Git داخل مجلد العمل الذي وجهته لمراقبته. كما أن مجلد .git هو المكان الذي يخزن فيه Git قواعد بيانات الكائنات والبيانات الوصفية للملف (الملفات) التي وجهته لمراقبتها.

ملاحظة: دليل .git هو روح Git – إنه العنصر الذي يتم نسخه عند استنساخ مستودع من جهاز كمبيوتر آخر (أو من منصة عبر الإنترنت مثل GitHub). الملفات في حالة الالتزام (committed state) توجد في دليل Git.

سير عمل Git الأساسي

العمل مع نظام التحكم بالإصدارات Git يبدو كالتالي:

1. تعديل الملفات في مجلد العمل: لاحظ أن أي ملف تقوم بتعديله يصبح ملفًا في حالة التعديل (modified state).
2. تجهيز الملفات بشكل انتقائي: اختر الملفات التي تريد الالتزام بها في دليل .git. لاحظ أن أي ملف تقوم بتجهيزه (إضافته) إلى منطقة التجهيز يصبح ملفًا في حالة التجهيز (staged state). كن على دراية أيضًا بأن الملفات المجهزة ليست بعد في قاعدة بيانات .git. التجهيز يعني أن المعلومات حول الملف المجهز يتم تضمينها في ملف (يُسمى "الفهرس" index) في مستودع .git.
3. الالتزام بالملف (الملفات) الذي قمت بتجهيزه في دليل .git: أي، تخزين لقطة من الملف (الملفات) المجهزة بشكل دائم في قاعدة بيانات .git. لاحظ أن أي إصدار ملف تلتزم به في دليل .git يصبح ملفًا في حالة الالتزام (committed state).

خلاصة القول من كل النقاش حتى الآن هي أن Git هو نظام تحكم بالإصدارات رائع لتحديد الإصدارات وإدارة وتوزيع الملفات بكفاءة.

فك الغموض عن GitHub

GitHub هي منصة قائمة على الويب حيث يمكن للمستخدمين استضافة مستودعات Git. تساعدك على تسهيل المشاركة والتعاون السهل في المشاريع مع أي شخص في أي وقت. يشجع GitHub أيضًا على المشاركة الأوسع في مشاريع المصدر المفتوح من خلال توفير طريقة آمنة لتعديل الملفات في مستودع مستخدم آخر.

لاستضافة (أو مشاركة) مستودع Git على GitHub، اتبع الخطوات التالية:

الخطوة 1: التسجيل للحصول على حساب GitHub

الخطوة الأولى لبدء الاستضافة على GitHub هي إنشاء حساب شخصي. قم بزيارة صفحة التسجيل الرسمية للتسجيل.

الخطوة 2: إنشاء مستودع بعيد (Remote Repository) في GitHub

بعد التسجيل للحصول على حساب، قم بإنشاء مكان (مستودع) في GitHub لمستودع Git الذي تريد مشاركته.

الخطوة 3: ربط دليل Git للمشروع بالمستودع البعيد

بمجرد إنشاء مستودع بعيد لمشروعك، قم بربط دليل .git للمشروع – الموجود محليًا على نظامك – بالمستودع البعيد على GitHub. للاتصال بالمستودع البعيد، انتقل إلى الدليل الجذر للمشروع الذي تريد مشاركته عبر الطرفية المحلية، وقم بتشغيل الأمر التالي:

git remote add origin https://github.com/yourusername/yourreponame.git

ملاحظة: استبدل yourusername في الكود أعلاه باسم مستخدم GitHub الخاص بك. وبالمثل، استبدل yourreponame باسم المستودع البعيد الذي تريد الاتصال به. يعني الأمر أعلاه أن git يجب أن يضيف عنوان URL المحدد إلى المشروع المحلي كمرجع بعيد يمكن لدليل .git المحلي التفاعل معه. الخيار origin في الأمر أعلاه هو الاسم الافتراضي (اسم قصير) الذي يمنحه Git للخادم الذي يستضيف مستودعك البعيد. أي، بدلاً من عنوان URL الخاص بالخادم، يستخدم Git الاسم القصير origin. ليس إلزاميًا الالتزام بالاسم الافتراضي للخادم. إذا كنت تفضل اسمًا آخر بدلاً من origin، فما عليك سوى استبدال اسم origin في أمر git remote add أعلاه بأي اسم تفضله. تذكر دائمًا أن الاسم القصير للخادم (على سبيل المثال، origin) ليس شيئًا خاصًا! إنه موجود – محليًا – فقط لمساعدتك في الإشارة بسهولة إلى عنوان URL الخاص بالخادم. لذا لا تتردد في تغييره إلى اسم قصير يمكنك الإشارة إليه بسهولة.

لإعادة تسمية أي عنوان URL بعيد موجود، استخدم أمر git remote rename كالتالي:

git remote rename theCurrentURLName yourNewURLName

كلما قمت باستنساخ (تنزيل) أي مستودع بعيد، يقوم Git تلقائيًا بتسمية عنوان URL الخاص بهذا المستودع بـ origin. ومع ذلك، يمكنك تحديد اسم مختلف باستخدام أمر git clone -o yourPreferredName. لمعرفة عنوان URL الدقيق المخزن للأسماء المستعارة مثل origin، قم بتشغيل أمر git remote -v.

الخطوة 4: تأكيد الاتصال

بمجرد ربط دليل Git الخاص بك بالمستودع البعيد، تحقق مما إذا كان الاتصال ناجحًا عن طريق تشغيل git remote -v في سطر الأوامر. بعد ذلك، تحقق من الإخراج لتأكيد أن عنوان URL المعروض هو نفسه عنوان URL البعيد الذي تنوي الاتصال به.

ملاحظة: راجع مقال "الاتصال باستخدام SSH" (Connecting with SSH) إذا كنت ترغب في الاتصال باستخدام عنوان URL الخاص بـ SSH بدلاً من عنوان URL الخاص بـ HTTPS. ومع ذلك، إذا لم تكن متأكدًا من عنوان URL البعيد الذي يجب استخدامه، فراجع مقال "أي عنوان URL بعيد يجب أن أستخدمه؟" (Which remote URL should I use?). هل ترغب في تغيير عنوان URL البعيد الخاص بك؟ "تغيير عنوان URL الخاص بالبعيد" (Changing a remote's URL) هو دليل ممتاز.

الخطوة 5: دفع مستودع Git محلي إلى المستودع البعيد

بعد ربط دليلك المحلي بالمستودع البعيد بنجاح، يمكنك بعد ذلك البدء في دفع (رفع) مشروعك المحلي إلى المصدر (upstream). كلما كنت جاهزًا لمشاركة مشروعك في أي مكان، على أي مستودع بعيد، ما عليك سوى توجيه Git لدفع جميع التزاماتك (commits) وفروعك (branches) وملفاتك في دليل .git المحلي إلى المستودع البعيد.

بناء جملة الكود المستخدم لتحميل (دفع) دليل Git محلي إلى مستودع بعيد هو git push -u remoteName branchName. أي، لدفع دليل .git المحلي الخاص بك، وبافتراض أن الاسم القصير لعنوان URL البعيد هو "origin"، قم بتشغيل:

git push -u origin master

ملاحظة: يعني الأمر أعلاه أن git يجب أن يدفع فرع master المحلي الخاص بك إلى فرع master البعيد الموجود في عنوان URL المسمى origin. من الناحية الفنية، يمكنك استبدال الخيار origin بعنوان URL الخاص بالمستودع البعيد. تذكر، الخيار origin هو مجرد اسم مستعار لعنوان URL الذي سجلته في دليل .git المحلي الخاص بك. العلم -u (علم مرجع المصدر/التتبع upstream/tracking reference flag) يربط تلقائيًا الفرع المحلي لدليل .git بالفرع البعيد. وهذا يسمح لك باستخدام git pull بدون أي وسائط.

الخطوة 6: تأكيد الرفع

أخيرًا، عد إلى صفحة مستودع GitHub الخاص بك لتأكيد أن Git قد دفع دليل Git المحلي الخاص بك إلى المستودع البعيد بنجاح.

ملاحظة: قد تحتاج إلى تحديث صفحة المستودع البعيد لكي تظهر التغييرات. يحتوي GitHub أيضًا على مرفق اختياري مجاني لتحويل مستودعك البعيد إلى موقع ويب وظيفي. دعنا نرى "كيف" أدناه.

نشر موقع الويب الخاص بك باستخدام GitHub Pages

بعد دفع مشروعك إلى مستودعك البعيد، يمكنك نشره بسهولة على الويب باتباع هذه الخطوات:

الخطوة 1: اسم ملف HTML

تأكد من أن اسم ملف HTML الرئيسي لمشروعك هو index.html.

الخطوة 2: الذهاب إلى علامة تبويب الإعدادات (Settings)

على منصة GitHub على الويب، انتقل إلى مستودع المشروع الذي تريد نشره وانقر على علامة تبويب الإعدادات (settings tab) الخاصة بالمستودع.

الخطوة 3: الذهاب إلى علامة تبويب الصفحات (Pages)

انتقل للأسفل إلى قسم GitHub Pages.

الخطوة 4: تغيير المصدر (Source)

هناك، قم بتغيير الفرع المصدر (Source branch) من none إلى master.

الخطوة 5: شاهد موقعك على الهواء مباشرة!

بعد ذلك، ستظهر رسالة إشعار تقول: "تم نشر موقعك على https://your-username.github.io/your-github-repo-name/".

الآن يمكنك عرض مشروعك – والترويج له – على عنوان URL المحدد. هذا القسم لم يخدش سوى سطح نشر مشروعك باستخدام GitHub. لمعرفة المزيد حول GitHub Pages، راجع وثائق "العمل مع GitHub Pages" (Working with GitHub Pages).

باختصار، GitHub هي منصة عبر الإنترنت لاستضافة (أو مشاركة) مستودعات Git. تساعدك على إنشاء وسيلة للتعاون بسهولة في المشاريع مع أي شخص، في أي مكان، في أي وقت.

ما زلت في حيرة؟ الفروقات الجوهرية بين Git و GitHub

هل ما زلت في حيرة بشأن الخط الفاصل بين Git و GitHub؟ لا تقلق – لقد قمت بتغطيتك. فيما يلي خمسة فروقات رئيسية بين Git و GitHub:

• الفرق 1: Git مقابل GitHub – الوظيفة الأساسية

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

• الفرق 2: Git مقابل GitHub – منصة التشغيل

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

• الفرق 3: Git مقابل GitHub – المخترعون

  بدأ لينوس تورفالدس (Linus Torvalds) تطوير Git في أبريل 2005. أسس كريس وانستراث (Chris Wanstrath)، بي. جيه. هايت (P. J. Hyett)، توم بريستون-ويرنر (Tom Preston-Werner)، وسكوت تشاكون (Scott Chacon) موقع GitHub.com في فبراير 2008.

• الفرق 4: Git مقابل GitHub – القائمون على الصيانة

  في يوليو 2005، سلم لينوس تورفالدس صيانة Git إلى جونيو سي. هامانو (Junio C. Hamano) – الذي كان كبير القائمين على الصيانة منذ ذلك الحين. واستحوذت مايكروسوفت على GitHub في أكتوبر 2018.

• الفرق 5: Git مقابل GitHub – المنافسون

  البدائل الشائعة لـ Git هي Mercurial، و Team Foundation Version Control (TFVC)، و Perforce Helix Core، و Apache Subversion، و IBM Rational ClearCase. أقرب منافسي GitHub هم GitLab، و Bitbucket، و SourceForge، و Cloud Source Repositories، و AWS CodeCommit.

بشكل عام، Git و GitHub هما كيانان مختلفان يساعدانك في إدارة واستضافة الملفات. بعبارة أخرى، يخدم Git للتحكم في إصدارات الملفات بينما GitHub هي منصة لاستضافة مستودعات Git.

الخلاصة التقنية

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