موسوعة عربية للمعرفة التقنية والعلمية الموثقة
ما هو Git؟
خلاصة سريعة: Git نظام تحكم في الإصدارات يسجّل تاريخ ملفات المشروع في لقطات يمكن الرجوع إليها، ويتيح العمل على فروع متوازية ثم دمجها، ويعمل دون اتصال لأن التاريخ كامل على جهازك. هو الحافظ لتاريخ الشيفرة، لا منصة استضافة ولا خدمة نسخ احتياطي.
ما هو Git؟
Git نظام تحكم في الإصدارات الموزّع (Distributed Version Control System)، طوّره لينوس تورفالدس عام 2005 لإدارة شيفرة نواة لينكس بعد أن تخلى الفريق عن نظام تجاري سابق. والفكرة المركزية أن المشروع كله، بتاريخه الكامل، يوجد على جهاز كل مساهم، لا على خادم مركزي واحد. فالخادم نسخة أخرى من المستودع، وليس المصدر الوحيد.
ويحفظ Git حالة المشروع في لقطات (Snapshots) لا في قائمة تعديلات متتابعة. فكل التزام (Commit) يشير إلى شجرة الملفات كلها في تلك اللحظة، وإلى الالتزام السابق، وإلى بصمة تجزئة تحمي سلامة المحتوى. ويُخفّض الحجم الفعلي بضغط الكائنات المتشابهة في حزم، فلا يعني حفظ اللقطات تضاعف المساحة مع كل تعديل.
لماذا صار Git معيارًا في تطوير البرمجيات؟
لأنه سريع ومفتوح المصدر، ولأن الفروع فيه رخيصة جدًا: إنشاء فرع عملية فورية تقريبًا لأنه مؤشر إلى التزام، لا نسخة كاملة من الملفات. وقد أعفى هذا الفريق من الخوف من التجريب؛ فالميزة الجديدة تُبنى في فرع منفصل، ثم تُدمج أو تُهمل دون أن تمسّ الفرع الرئيسي. ويعمل معظم الفريق محليًا دون اتصال، ثم يزامن ما أنجزه حين تتوفر الشبكة.
ثم إن السلامة جزء من التصميم: كل كائن يحمل بصمة تجزئة تُحسب من محتواه، فأي تعديل في محتوى كائن يغيّر بصمته، ويغيّر معه بصمات الالتزامات التي تليه، فيُكشف العبث. ولهذا يعتمد Git في المشاريع المفتوحة والمغلقة على السواء، وتُبنى فوقه منصات المراجعة والتعاون. ولمن يريد معرفة المسار الذي تقطعه الملفات بين الجهاز والخادم، يفيد مقال كيف يعمل الإنترنت.
كيف يعمل Git: المناطق الثلاث والالتزامات
يعمل Git على ثلاث مناطق: مجلد العمل حيث تعدّل الملفات، ومنطقة التهيئة (Staging Area) حيث تختار ما سيدخل في الالتزام التالي، والمستودع حيث يُسجَّل التاريخ. وتمر دورة العمل المعتادة بهذا الترتيب:
git init
git add index.html
git commit -m "إضافة الصفحة الأولى"
git log --onelineالأمر git add يسجّل التغيير في منطقة التهيئة، وgit commit يثبته في التاريخ برسالة تشرح سببه. والالتزام الجيد يجيب عن سؤال «لماذا؟» لا «ماذا؟»؛ فقارئ التاريخ يرى الملفات المتغيرة من الفرق نفسه، ويحتاج إلى سبب التغيير. ويحمل كل التزام معرّفًا فريدًا، ويمكن الإشارة إلى الالتزام السابق بـHEAD~1 أو إلى فرع باسمه.
والملفات في مجلد العمل تمر بأربع حالات: غير متتبَّعة، أو متتبَّعة ومعدّلة، أو مهيّأة للالتزام، أو غير معدّلة. ويفيد فهم هذه الحالات في معرفة ما سيدخل الالتزام فعلًا؛ فكثير من الأخطاء سببها الظن أن git commit يأخذ كل شيء، بينما يأخذ ما هُيّئ وحده. ولهذا يُستحسن git status قبل كل التزام.
كيف تعمل الفروع والدمج؟
الفرع (Branch) مؤشر متحرك إلى التزام، وHEAD يشير إلى الفرع الحالي. وحين تلتزم على فرع، يتقدم مؤشره وحده، وتبقى الفروع الأخرى في مكانها. ويُنشأ الفرع بـgit switch -c feature، ثم يُدمج في الرئيسي بـgit switch main وgit merge feature. وحين لا يكون الرئيسي قد تقدم منذ تفرّع الميزة، يتحرك المؤشر إلى الأمام مباشرة، ويسمى ذلك دمجًا سريعًا (Fast-forward).
أما إذا تقدم الفرعان معًا، فيبني Git التزام دمج (Merge Commit) يجمع التاريخين. وحين تتعارض التعديلات في السطر نفسه، يتوقف الدمج ويطلب منك الحسم؛ فتظهر علامات التعارض في الملف، وتختار ما يبقى، ثم تهيّئ الملف وتكمل الدمج. والتعارض ليس خطأً في Git، بل إشارة إلى أن شخصين عدّلا الموضع نفسه، والحل قرار بشري لا آلي.
merge أم rebase؟
السؤال يتكرر لأنه لا جواب واحد صحيح له. الدمج يحفظ التاريخ كما جرى، ويضيف التزامًا يجمع الفرعين، فيبقى السياق واضحًا لكن الرسم يتشعب. أما إعادة الأساس (Rebase) فتنقل التزامات فرعك لتُبنى فوق آخر التزام في الفرع الهدف، فتنتج سلسلة خطية أنيقة، لكنها تعيد كتابة الالتزامات وتغيّر معرّفاتها.
| المعيار | merge | rebase |
|---|---|---|
| شكل التاريخ | يحفظ التفرع والالتزام الجامع | خطي ومتصل |
| معرّفات الالتزامات | تبقى كما هي | تُعاد كتابتها |
| الاستخدام الآمن | الفروع المشتركة | فرع محلي لم يُنشر بعد |
| أثر التعارض | يُحل مرة واحدة عند الدمج | قد يُحل مع كل التزام يُنقل |
والقاعدة الذهبية: لا تُعِد أساس فرعٍ شاركك فيه غيرك. فإعادة الكتابة تغيّر التاريخ الذي بنى عليه زملاؤك، ويصبح عليهم إصلاح مستودعاتهم يدويًا. أما تنظيف فرعك المحلي قبل إرساله للمراجعة فاستخدامه مشروع، بشرط ألا يكون قد دُفع إلى مستودع بعيد.
كيف تتعاون عبر المستودعات البعيدة؟
المستودع البعيد (Remote) نسخة على خادم، ويُسمّى الافتراضي عادة origin. وgit fetch يجلب الجديد دون دمجه في فرعك، بينما git pull يجلب ثم يدمج. والفرق مهم: من يريد رؤية ما وصل قبل أن يقرر يستخدم fetch، ومن يريد التحديث المباشر يستخدم pull. وgit push يرسل التزاماتك المحلية إلى البعيد.
وفي العمل الجماعي يُعتمد غالبًا نموذج طلب الدمج (Pull Request): ترفع فرعًا، وتفتح طلب مراجعة، ويناقش الفريق التغيير قبل دمجه. وقد بُني هذا النموذج على Git نفسه لا على خاصية فيه، ولهذا تعمل منصات مختلفة به، وتتيح واجهات برمجة التطبيقات فيها أتمتة الفحص والاختبار قبل الدمج. ومن هنا أيضًا أهمية رسائل الالتزام الواضحة، لأن المراجع يقرأ التاريخ قبل الشيفرة في كثير من الأحيان.
كيف تتراجع عن تغيير في Git؟
لأن Git لا يمحو الالتزامات فورًا، فالتراجع ممكن في معظم الحالات. وgit revert ينشئ التزامًا جديدًا يعكس أثر التزام سابق، وهو الخيار الآمن في الفروع المشتركة. وgit reset يحرّك مؤشر الفرع: بالوضع --soft يُبقي التغييرات مهيّأة، وبالوضع --mixed يعيدها إلى مجلد العمل، وبالوضع --hard يمحوها من الاثنين معًا، ولهذا يُتأنى فيه.
وإذا ضاع التزام أو فرع، فسجل المراجع (Reflog) يحتفظ بحركات HEAD الأخيرة على جهازك، ويمكن منه استعادة الحالة السابقة. أما الملفات غير المتتبعة فليست محفوظة في التاريخ أصلًا، ولهذا تُحفظ قبل التجارب الخطرة. ولمن يريد الاحتفاظ بنسخة كاملة بعيدًا عن المستودع، يفيد مقال وحدات التخزين في اختيار الوسيط المناسب.
ما حدود Git وأخطاؤه الشائعة؟
- ليس نسخة احتياطية: المستودع البعيد يحمي من عطل الجهاز، لكنه لا يحمي من حذف متعمد أو من اختراق الحساب؛ ويلزم نسخ مستقل ودوري.
- الأسرار في التاريخ: كلمة مرور دُفعت مرة تبقى في التاريخ ولو حُذفت من الملف؛ ويجب إلغاء السر نفسه لا الاكتفاء بحذف الملف.
- الملفات الثنائية الكبيرة: يصعب ضغطها ويتضخم المستودع؛ وتُستخدم أدوات تخزين مخصصة للملفات الكبيرة.
- الالتزامات العشوائية: «تعديلات» أو «إصلاح» لا تفيد أحدًا؛ والرسالة الجيدة تشرح الدافع.
- إهمال
.gitignore: يدفع المطور ملفات البناء والبيئة إلى المستودع، فتتضخم الفروق وتتسرب الإعدادات المحلية. - إعادة الأساس على فرع مشترك: تكسر تاريخ زملائك، وهي أشهر طريقة لإفساد تعاون الفريق.
وفي مسار تطوير الويب وبناء البرمجيات، يتكامل هذا الموضوع مع التكامل المستمر والتسليم المستمر (CI/CD) ومنهجية DevOps.
أسئلة شائعة
ما الفرق بين Git وGitHub؟
Git نظام تحكم في الإصدارات يعمل على جهازك، أما GitHub منصة استضافة تعرض مستودعات Git وتضيف المراجعة والمشكلات وأدوات التعاون. ويمكن استخدام Git دون GitHub، كما توجد منصات أخرى مثل GitLab وBitbucket.
ما الفرق بين merge وrebase؟
merge يجمع الفرعين ويثبت التاريخ كما جرى، مع التزام دمج. أما rebase فينقل التزامات فرعك لتبدأ من آخر التزام في الفرع الهدف، فينتج تاريخ خطي لكن بمعرّفات جديدة. استخدم rebase على فرع محلي لم تشاركه.
هل يمكن استعادة التزام محذوف في Git؟
غالبًا نعم، ما دام الالتزام موجودًا في سجل المراجع (Reflog). استخدم git reflog لمعرفة المعرّف، ثم أنشئ فرعًا منه أو أعد المؤشر إليه. لكن الملفات غير المتتبعة لم تدخل التاريخ أصلًا ولا يمكن استعادتها بهذه الطريقة.
ماذا يعني أن Git موزّع؟
يعني أن كل نسخة من المستودع تحمل التاريخ الكامل، لا آخر نسخة من الملفات فقط. فيستطيع المطور الالتزام والتفريع والبحث في التاريخ دون اتصال، ثم يزامن ما أنجزه مع المستودع البعيد حين تتوفر الشبكة.
هل يصلح Git نسخة احتياطية؟
لا، هو أداة إدارة إصدارات لا أداة نسخ احتياطي. يحمي التاريخ من الضياع عند عطل الجهاز إن كان المستودع البعيد سليمًا، لكنه لا يحمي من الحذف المتعمد أو اختراق الحساب أو فساد المستودع نفسه.
