Git 3.0 على الأبواب: SHA-256 وreftable وRust، فماذا يجب أن تجهّزه الآن؟
Git 3.0 سيجعل SHA-256 وreftable افتراضيين ويشترط Rust للبناء. دليل عملي لمن يتأثر ولتجربة التغييرات الآن قبل أن تكسر سكربتات الـ CI والإصدار لديك دون إنذار.
لم يتغيّر الأساس الذي يقوم عليه Git منذ سنوات طويلة: كل كائن يُعرَّف ببصمة SHA-1، وكل فرع جديد يحمل اسماً افتراضياً قديماً، وكل مرجع يُخزَّن كملف صغير داخل مجلد .git/refs. اليوم تتجه هذه الأسس كلها إلى التغيير دفعة واحدة. فبحسب ما نشره المشرف جونيو هامانو، لم يتبقَّ بعد الإصدار 2.56 سوى دورة واحدة قبل نهاية العام، والمرجّح أن يحمل ما بعدها اسم Git 3.0. الإصدار لم يصدر بعد ولا يوجد له تاريخ نهائي، لكن قائمة التغييرات صارت واضحة بما يكفي لتبدأ الاستعداد من الآن.
ما الذي سيتغيّر في Git 3.0؟
التغييرات المخطَّط لها ليست تجميلية، بل تمسّ طريقة تخزين البيانات وبناء الأداة:
- SHA-256 افتراضياً: المستودعات الجديدة ستستخدم SHA-256 بدل SHA-1، فتتحول معرّفات الكائنات من 40 خانة سداسية عشرية إلى 64.
mainاسماً افتراضياً للفرع الأول: بدلmasterفي المستودعات الجديدة.- Reftable افتراضياً لتخزين المراجع: بديل عن نظام الملفات القديم في
.git/refs. - Rust شرط لبناء Git: اكتُشف دعمه تلقائياً في 2.52، وفُعّل افتراضياً في 2.55، ويصبح إلزامياً في 3.0.
- قيمة أكثر أماناً لـ
safe.bareRepository: تنتقل منallإلىexplicit. - معرّفات كائنات أكثر صرامة: ستُرفض الأحرف الكبيرة في المعرّفات السداسية، ويُقبل الحرف الصغير فقط.
- إزالة أوامر قديمة: مثل
git whatchangedوgit pack-redundantوعمليات الـ grafts.
أهم ما في الأمر أن Git 3.0 لا يفرض ترحيلاً على المستودعات القائمة، لكنه يغيّر ما يحصل عليه كل من يبدأ مشروعاً جديداً.
لماذا SHA-256 الآن؟
بصمة SHA-1 لم تعد تُعدّ آمنة تشفيرياً منذ سنوات، وقد أثبتت هجمات التصادم العملية ذلك. في Git يُخفَّف الخطر بآليات كشف تصادم إضافية، لكن الحل الجذري هو الانتقال إلى دالة أقوى. المشكلة لم تكن تقنية فحسب، بل تتعلق بمنظومة كاملة: العقبة الرئيسية أمام التحول هي دعم المنصات. فبحسب ما ورد في التقارير، يدعم GitLab هذا الخيار منذ 2024 ويدعمه Forgejo أيضاً، بينما يظل غياب الدعم في GitHub هو العائق الأكبر أمام جعله الافتراضي.
هذا يعني عملياً أن مستودعاً بتنسيق SHA-256 قد لا يتعامل بسهولة مع بعض الأدوات والخدمات التي تفترض أن المعرّف 40 خانة. وإذا كانت أدوات الـ CI أو سكربتات الإصدار لديك تحلّل المعرّفات بتعبيرات نمطية صارمة، فهي أول ما سينكسر.
Reftable: لماذا يهمّ المستودعات الضخمة؟
نظام المراجع الحالي يخزّن كل فرع ووسم كملف مستقل أو في ملف مجمَّع. هذا يعمل جيداً في المشاريع المتوسطة، لكنه يتعثر حين تصل المراجع إلى مئات الآلاف، كما في مستودعات مثل Android. أما reftable فهو تنسيق ثنائي مضغوط يتيح قراءة أسرع وكتابة ذرّية أفضل. بالنسبة لفريق صغير لن يكون الفرق محسوساً، لكن المؤسسات الكبيرة ستلاحظ تحسناً واضحاً.
وماذا عن اشتراط Rust؟
اشتراط Rust في البناء يهمّ بالدرجة الأولى من يبني Git من المصدر أو يوزّعه: مشرفو الحزم في توزيعات لينكس، ومن يعتمد على أنظمة بناء مخصصة، ومن يعمل على معماريات نادرة قد لا تدعمها مترجمات Rust. المستخدم العادي الذي يثبّت Git من مدير الحزم لن يشعر بشيء.
جدول سريع: من يتأثر؟
| الفئة | مستوى التأثير | ما تفعله الآن |
|---|---|---|
| مطوّر يعمل على مستودعات قائمة | منخفض | لا شيء عاجل، تابع الإصدارات |
| فريق يبدأ مستودعات جديدة كثيراً | متوسط | اختبر SHA-256 في بيئة تجريبية |
| مسؤول CI وسكربتات الإصدار | مرتفع | راجع أي افتراض بطول المعرّف |
| مشرف حزم أو باني من المصدر | مرتفع | جهّز سلسلة أدوات Rust |
| مؤسسة بمستودعات ضخمة | متوسط | قيّم reftable لتحسين الأداء |
كيف تجرّب التغييرات اليوم؟
لا تحتاج إلى انتظار الإصدار لتختبر أثر هذه التغييرات على مشروعك:
- أنشئ مستودعاً تجريبياً بتنسيق SHA-256 عبر الأمر
git init --object-format=sha256. - لجعل SHA-256 افتراضياً على جهازك للتجارب:
git config --global init.defaultObjectFormat sha256. - شغّل خطوط الـ CI والسكربتات على هذا المستودع وراقب ما ينكسر.
- ابحث في شيفرتك عن أي تعبير نمطي أو عمود في قاعدة بيانات يفترض أن المعرّف 40 حرفاً.
- اضبط اسم الفرع الافتراضي صراحة في سكربتات الإعداد بدل الاعتماد على الافتراضي، فيعمل مع كل الإصدارات.
نصائح للاستعداد دون ذعر
أولاً، لا تُرحِّل مستودعاتك الحالية، فالتوافق مع SHA-1 مستمر بحسب الخطة المعلنة. ثانياً، وثّق في ملفات القوالب لديك الإصدار الأدنى من Git الذي يدعمه فريقك. ثالثاً، إذا كنت تستخدم وكلاء برمجة ينفّذون أوامر Git تلقائياً، فتأكد من أن تعليماتهم لا تفترض شكل المعرّف أو اسم الفرع، لأنها ستفشل بصمت حين يتغيّر الافتراضي.
سيناريو عملي: ما الذي قد ينكسر في فريقك؟
لنفترض فريقاً يدير عشرات الخدمات الصغيرة، وله سكربت إصدار يستخرج بصمة الالتزام الأخيرة بتعبير نمطي من 40 خانة ثم يضعها في اسم صورة الحاوية. عند أول مستودع جديد بتنسيق SHA-256 سيفشل هذا السكربت بصمت أو سيقتطع المعرّف، فتتشابه أسماء الصور أو تُرفض. وهناك مثال آخر: جدول في قاعدة بيانات داخلية يحفظ المعرّف في عمود طوله 40 حرفاً، فيرفض الإدخال أو يقصّه.
هذه المشكلات ليست خللاً في Git، بل افتراضات قديمة تسرّبت إلى أدوات الفريق. وأسهل طريقة لكشفها هي ما ذُكر أعلاه: مستودع تجريبي بتنسيق جديد وتشغيل خط الإنتاج كاملاً عليه مرة واحدة.
نقاط تفتيش سريعة
- ابحث في الشيفرة عن الرقم 40 والتعبيرات
[0-9a-f]{40}وما يشبهها. - راجع أطوال الأعمدة في قواعد البيانات التي تخزّن معرّفات الالتزامات.
- تحقّق من أن أدوات المراجعة والمنصات التي تستخدمها تدعم التنسيق الجديد قبل اعتماده في مشاريع حقيقية.
- حدّث وثائق الفريق لتذكر أن طول المعرّف قد يختلف بين مستودع وآخر.
أسئلة شائعة
هل سيتحوّل مستودعي الحالي إلى SHA-256 تلقائياً؟
لا. بحسب ما هو معلن، المستودعات القائمة بتنسيق SHA-1 لن تُرحَّل تلقائياً، والتغيير يخص المستودعات الجديدة فقط.
هل Git 3.0 صدر فعلاً؟
ليس بعد. لا يوجد تاريخ رسمي، والتقديرات تشير إلى قرب نهاية 2026، وقد تتغيّر التفاصيل قبل الإصدار النهائي.
هل سأحتاج إلى تثبيت Rust لاستخدام Git؟
فقط إن كنت تبني Git من المصدر. من يثبّته جاهزاً عبر مدير الحزم أو المثبّت الرسمي لن يحتاج شيئاً.
الخلاصة
Git 3.0 هو أكبر مراجعة لأسس الأداة منذ سنوات: SHA-256 وreftable وmain وRust. لا شيء من هذا يستدعي الذعر، لأن الحفاظ على التوافق مع المستودعات القديمة جزء من الخطة. لكن الفرق التي تتجاهل الأمر ستفاجأ حين تبدأ مستودعاتها الجديدة بسلوك مختلف يكسر سكربتاتها. خصّص ساعة لتجربة مستودع SHA-256 وفحص خطوط الـ CI الآن، فهذا أرخص بكثير من اكتشاف المشكلة في يوم الإصدار.
المصادر: DEV Community، byteiota، LWN.net
