استمع إلى هذا المقال
ربما استُخدم الذكاء الاصطناعي في إنتاج هذا الصوت.
اضغط مسافة أو K للتشغيل أو الإيقاف، وJ أو L للرجوع أو التقديم 15 ثانية.راجَعنا المصادر في 16 أكتوبر 2026.
في 13 أكتوبر 2026، شرحت أنثروبيك كيف استبدلت Git في مستودعها الموحّد بنظام Scion الذي طوّرته داخلياً، ثم حدّثت المقال في 15 أكتوبر. [1]
يظل Git خياراً ممتازاً لمعظم الفرق. يتيح للمطورين العمل باستقلالية، ويحفظ تاريخاً مفيداً إلى جانب الشيفرة، ويدعم التعاون من دون ربط كل مساهم بجهاز واحد. لا يحتاج فريق يبني تطبيقاً إلى التخلي عن هذه المزايا لأن شركة تطوّر نماذج ذكاء اصطناعي وجدت أن موازنة مختلفة بين التكاليف والمزايا تناسبها.
يساعد تاريخ Git على فهم هذا الاختيار: لماذا نجح تصميمه، ومتى تصبح بعض افتراضاته مكلفة، وكم يمكننا أن نغيّر في الأدوات المحيطة به قبل أن نحتاج إلى استبداله.
بدأ Git حين فقد لينكس أداته
تسجّل أنظمة إدارة الإصدارات كيف تتغير الملفات، حتى يستطيع الناس مقارنة النسخ، ودمج عملهم، والعودة إلى حالات سابقة. قبل انتشار Git، كانت الأنظمة المركزية مثل CVS وSubversion تنظّم العمل حول خادم. يحصل المطور على ملفات العمل، ويعدّلها، ثم يسجّل تغييراته في المستودع المشترك. ويحتفظ الخادم بالتاريخ المرجعي للمشروع. [2]
كان لينكس قد بدأ ينتقل إلى ترتيب مختلف. بعد سنوات من تبادل الرقع البرمجية والأرشيفات، بدأ مشروع النواة استخدام BitKeeper في 2002. لم يكن BitKeeper مفتوح المصدر، لكن نموذجه الموزّع أتاح للمطورين العمل بمستودعات محلية خاصة بهم. وفي 2005، تعثرت العلاقة وانتهى اتفاق الاستخدام المجاني. [3]
ارتبط الخلاف بمحاولة أندرو تريدجل فهم بروتوكول BitKeeper عبر الهندسة العكسية. وروى لينوس تورفالدس، منشئ لينكس، في مقابلة لاحقة أنه حاول التوسط قبل أن يقرر أنه لم يعد يستطيع الاستمرار بالأداة. ولم يكن راغباً في العودة إلى طريقة العمل السابقة. أما البدائل التي فحصها، فلم تحقق متطلباته في الأداء وسلامة البيانات والتطوير الموزّع. [4]
الشكل 1. تسلسل لاختيارات التصميم. أحداث 2005 محطات منفصلة، والمسافات ليست مقياساً زمنياً. المصادر [3] [5] [14] [1]
في 7 أبريل 2005، سجّل تورفالدس أول إيداع، أو commit، في Git. وكانت الأداة قادرة بالفعل على تسجيل تطورها هي نفسها. [5] وبعد نحو عشرة أيام، استخدمها لإيداع تغيير في نواة لينكس. تختصر الرواية الشائعة ذلك أحياناً بقولها إن Git «كُتب في عشرة أيام»، لكن النظام الأول كان نقطة بداية. وكان تورفالدس قد أمضى وقتاً يفكر في التصميم قبل أن يكتب الشيفرة. [4]
من الأفكار المفيدة التي أخذها من BitKeeper فكرة تتعلق بالصلاحية: حين يمتلك المطور مستودعه، يستطيع تسجيل عمله وتنظيمه قبل أن يمنحه أحد إذناً بالكتابة في الفرع الرئيسي المشترك. ويظل قرار قبول التغيير عند القائمين على المشروع. إنشاء التغيير وقبوله يصبحان قرارين منفصلين. [4]
يستحق الجزء التالي من القصة اهتماماً أكبر. تولّى جونيو سي. هامانو صيانة Git في نهاية يوليو 2005. وفي روايته لتلك الأشهر، كانت في المشروع فجوات كبيرة، وكان المساهمون يختبرون طرقاً مختلفة لمعالجتها. [6] تدين الأداة التي نستخدمها اليوم بالكثير لهذه الصيانة المستمرة. وفي مقابلة الذكرى العشرين، أكّد تورفالدس أن الوقت الذي أمضاه شخصياً في المشروع كان جزءاً صغيراً من تلك السنوات. [5]
أُطلق GitHub للجمهور في 10 أبريل 2008. [7] وجاءت مساهمته في طبقة أخرى: استضافة المستودعات، وتوفير مكان لاقتراح التغييرات ومناقشتها ومراجعتها. يجمع طلب السحب، أو pull request، الحوار والفحوص والفروق بين نسخ الشيفرة حول عملية دمج مقترحة. [8]
يساعد الفصل بين الطبقتين في فهم النقاش الحالي. يوفّر Git تاريخ الإصدارات وآليات تبادله. وتوفّر خدمة الاستضافة جزءاً كبيراً من تجربة الفريق حول ذلك التاريخ. يمكنك تغيير المراجعة أو الأتمتة أو المضيف من دون أن تغيّر بالضرورة نظام إدارة الإصدارات.
ماذا تكسب من مستودع محلي؟
يتعامل Git مع الإيداع باعتباره لقطة لحالة المشروع. ويمكن إعادة استخدام محتوى الملفات التي لم تتغير بين اللقطات؛ فلا يحتاج كل إيداع إلى نسخة فعلية جديدة من كل ملف. في النسخة المحلية الكاملة المعتادة، يتوافر تاريخ المشروع والكائنات اللازمة للعمل على جهازك. ولا يحتاج فحص التغييرات أو إنشاء إيداع عادةً إلى الاتصال بالخادم. [9]
الشكل 2. رسم توضيحي للإيداعات، من الأقدم إلى الأحدث. يستخدم المثال إيداع دمج؛ ويدعم Git طرقاً أخرى لدمج العمل. المصادر [9] [10]
الفرع مرجع خفيف يشير إلى إيداع. إنشاؤه لا ينسخ المشروع كله. وتسجّل الإيداعات مراجع إلى الإيداعات السابقة لها مباشرةً، فيستطيع Git تتبع موضع تفرّع التطوير والعثور على نقطة مشتركة عند دمج العمل مرة أخرى. [10]
هذه خصائص مفيدة في العمل اليومي. تخيّل فريقاً صغيراً يعدّل مسار إتمام الشراء: مطور يجرّب واجهة جديدة، وآخر يبحث في عطل بالدفع. يستطيع كل منهما الاحتفاظ بمسار مستقل، ثم مقارنة التغييرات قبل دمجها. يسجّل المستودع ما تغير، ويبقى على الفريق أن يقرر إن كان السلوك الناتج صحيحاً.
يجعل التاريخ المحلي بيئة العمل أقل هشاشة أيضاً. عندما تكون لديك نسخة كاملة من المستودع، لا يلزم أن يمنعك انقطاع مؤقت للشبكة من فحص تغييرات سابقة أو حفظ إيداعات جديدة. [9] ستظل بحاجة إلى الاتصال لنشر العمل والتنسيق مع الزملاء، لكن جزءاً كبيراً من التطوير يستطيع الاستمرار.
وفي ذلك قدر عملي من الاستقلالية. يمكن أن يبقى مستودع الشيفرة بعد انتهاء استخدام الخدمة التي تستضيفه. الانتقال لا ينقل تلقائياً كل مشكلة مسجلة أو تعليق مراجعة أو إعداد في المنصة، ولذلك يظل تغيير المضيف عملاً يحتاج إلى ترتيب. ومع ذلك، فإن الاحتفاظ بالشيفرة وتاريخها نقطة بداية مهمة، ويستحق أن يدخل في مقارنة تكلفة أي بديل.
المستودعات الكبيرة احتاجت دائماً إلى حلول خاصة
تتغير التكاليف عندما يكبر المستودع جداً، وتحتاج إليه آلاف المهام القصيرة العمر.
قارن بين جهاز مطور يعيد استخدام البيانات يوماً بعد يوم، ومهمة مؤقتة تبدأ من دون ذاكرة مؤقتة مفيدة. قد تقضي الثانية جزءاً كبيراً من عمرها في جلب الملفات والتاريخ قبل أداء وظيفتها. حين يهيمن هذا النوع من المهام، يصبح تقليل ما ينزّله كل عميل وما يحسبه هدفاً مهماً لفريق البنية التحتية. وتعالج خيارات الاستنساخ الجزئي والمحدود العمق في Git أجزاء من هذه المشكلة بالفعل. [11]
يتعلق الاختيار أيضاً بطريقة تنظيم الشيفرة. يجمع المستودع الموحّد، أو monorepo، مشاريع متعددة في مستودع واحد. قد يسهّل ذلك التغييرات المنسقة، لكنه يركّز تاريخاً ونشاطاً أكبر داخل نظام واحد.
وثّقت غوغل هذه الموازنة قبل ظهور موجة وكلاء البرمجة الحالية بسنوات. شرحت ورقة رايتشل بوتفين وجوش ليفنبرغ المنشورة في 2016 مستودع غوغل المخصص والأنظمة التي جعلت العمل على قاعدة شيفرة مشتركة عملياً لعشرات الآلاف من المطورين. [12]
واتخذت ميتا مساراً آخر. عندما أتاحت عميل Sapling مفتوح المصدر في نوفمبر 2022، تحدثت عن عشر سنوات من العمل عليه. جمعت منظومتها الداخلية بين عميل وخادم متوافق ونظام ملفات افتراضي لدعم مستودع يضم عشرات الملايين من الملفات والإيداعات. بدأ Sapling امتداداً لـMercurial، ثم طوّر صيغه وبروتوكولاته. وكان العميل المتاح للجمهور يستطيع العمل مع مستودعات Git أيضاً. [13]
إذن كانت المؤسسات الكبيرة تتخذ هذه القرارات بالفعل. تستطيع الفرق الأصغر أن تتعلم من تقنياتها، لكن حجم العمل وطبيعته يحددان أي تقنيات تستحق تكلفة تشغيلها.
ما الذي بنته أنثروبيك؟
تقول أنثروبيك إن متوسط التغييرات المدمجة يومياً ارتفع من نحو 2,500 في مايو إلى أكثر من 30,000 في سبتمبر. وتجاوز حجم نسخة العمل المضغوطة 25 غيغابايت، بينما نفّذت أنظمة التكامل المستمر نحو 25 مليون عملية تجهيز لنسخة من الشيفرة يومياً. وكانت الشركة قد جرّبت بالفعل أساليب الاستنساخ الجزئي والمحدود، ولقطات المستودع، ومئات خوادم Git المرآة. [1]
الشكل 3. قيم أعلنتها الشركة، وليست سلسلة يومية أعيد بناؤها. قيمة مايو تقريبية، وسبتمبر حد أدنى. المحطات الزمنية متساوية المسافات. المصادر [1] [14]
كان معظم العملاء وكلاء ومهام متصلة بالشبكة أصلاً. جعل Scion هذا الاتصال افتراضاً في التصميم. تتولى الخوادم الإيداعات والدمج واستعلامات التاريخ، ويطلب العميل البيانات اللازمة. ويمكن للمهام استخدام واجهات برمجية من دون الاحتفاظ بمستودع محلي. بنى سبعة مهندسين Scion وأداة المراجعة Antique والأنظمة المرتبطة بهما، وأكملوا الانتقال خلال خمسة أشهر. [1]
الشكل 4. توزيع مبسّط للمسؤوليات. يمثّل Git هنا نسخة كاملة تتوافر كائناتها المطلوبة محلياً. ويمثّل Scion تصميم أنثروبيك الذي يفترض اتصالاً دائماً. ليست هذه مقارنة أداء. المصادر [9] [1]
وتذكر أنثروبيك أن احتياجات المعالجة والذاكرة أصبحت جزءاً من مئتين من احتياجات بنيتها السابقة لمرايا Git. هذه نتيجة تشغيل النظام في بيئة أنثروبيك الداخلية، وليست مقارنة أداء عامة. ويتطلب التبني في مكان آخر تغييرات في المراجعة والبحث والتكامل المستمر. وتقول الشركة صراحةً إن Scion غير مناسب ليكون بديلاً عاماً لـGit. [1]
طفرة الذكاء الاصطناعي تظهر في حركة GitHub
يصف تقرير GitHub المنشور في 6 أكتوبر حجم النشاط وراء هذا التغيير. سجّل سبتمبر 2026 نحو 7.38 مليار إيداع، أي أكثر من خمسة أمثال العدد قبل عام. واقترب حجم طلبات السحب المدمجة من أربعة أمثال مستواه قبل عام. وهما مقياسان مختلفان: يسجّل الإيداع حالة، بينما يدمج طلب السحب عملاً مقترحاً. ويمكن أن يحتوي طلب واحد على إيداعات كثيرة. [14]
الشكل 5. النمو النسبي يجعل حجم العام السابق 1×. يشير السهم إلى حد أدنى، والتظليل المائل إلى قيمة تقريبية. لا يورد التقرير عدداً مطلقاً لطلبات السحب المدمجة. المصدر [14]
يربط GitHub هذا الضغط بعمل المطورين والوكلاء بالتوازي. لكن أرقامه لا تعزل الحصة التي سببها الذكاء الاصطناعي، ولا تقيس مقدار البرمجيات المفيدة الناتجة. قد تعني زيادة الإيداعات حفظ نقاط أكثر أثناء العمل، وقد تعني زيادة الدمج تقسيم العمل إلى تغييرات أصغر. النشاط حقيقي، لكنه ليس درجة للإنتاجية.
يحافظ الرسم على دقة الصياغة المنشورة. قيمة الإيداعات حد أدنى، وقيمة طلبات السحب تقريبية. ولا يورد التقرير عدداً دقيقاً لإيداعات العام السابق أو عدداً مطلقاً لطلبات السحب المدمجة. [14]
GitHub يغيّر ما يعمل خلف Git
يفصل التصميم الجديد لدى GitHub التخزين عن الحوسبة، وينقل البيانات المرجعية إلى Azure Blob Storage، ويقلل التنسيق المطلوب حول عمليات الكتابة. وتعتزم الشركة الحفاظ على قواعد عمل Git ومسارات التطوير الحالية. وما زال العمل جارياً. [14]
هذا فرق مفيد لمن يختار ما يتبناه. يمكن أن تتغير الخدمة كثيراً خلف واجهة مألوفة. وقد يتطلب تزايد النشاط الآلي بنية جديدة للتخزين وخدمة الطلبات، من دون أن يضطر كل مطور إلى تعلّم نموذج جديد لإدارة الإصدارات.
ويتيح ذلك لفريق منتج عادي الاستفادة من عمل في البنية التحتية لا يُعقل أن يموله بنفسه. والسؤال العملي هو ما إذا كانت الخدمة تلبي احتياجاته بتكلفة مقبولة، مع الضوابط والاعتمادية التي يعتمد عليها.
تحسينات تستطيع معظم الفرق إجراءها الآن
أمام الفريق الذي يستخدم وكلاء البرمجة خيارات داخل منظومة Git قبل أن يحتاج إلى بديل.
الشكل 6. تعمل هذه الخيارات على أجزاء مختلفة من مسار العمل. تحدد التجربة والقياس في بيئتك مدى فائدتها. المصادر [11] [15] [16] [17]
ابدأ بتسمية التأخير أو العطل المحدد. قد تعني عبارة «Git بطيء» تنزيلاً ضخماً، أو ملفات أكثر مما يحتاجه الجهاز، أو دمجاً صعباً، أو تغييراً ينتظر من يراجعه. ولكل منها معالجة مختلفة.
ما الذي يواجهه الفريق؟ | خيار يستحق الفحص | ما الذي يغيّره؟ |
|---|---|---|
مهام متزامنة تتداخل في ملفات العمل نفسها | أشجار عمل Git [15] | مجلدات عمل وفروع مستقلة مرتبطة بمستودع واحد |
التكامل المستمر يجلب تاريخاً لا يستخدمه | استنساخ محدود العمق [11] | يحدّ من التاريخ المنزّل؛ مع الانتباه للمهام التي تحتاج إيداعات أقدم |
الاستنساخ يجلب محتوى الملفات قبل الحاجة إليه | استنساخ جزئي [11] | يؤجّل جلب كائنات محددة حتى الحاجة إليها، بدعم من الخادم |
المطور يحتاج جزءاً من المستودع الموحّد | إخراج انتقائي للملفات [16] | يحدّ من الملفات الموجودة في مجلد العمل |
ملفات ثنائية كبيرة تضخّم المستودع | Git LFS [17] | يحتفظ بمؤشرات داخل Git ويخزّن المحتوى الكبير منفصلاً |
تعالج هذه الخصائص طبقات مختلفة. يتحكم الإخراج الانتقائي في ملفات العمل، بينما يتحكم الاستنساخ الجزئي في الكائنات التي تُجلب. وقد يفيدان معاً، لكن اختيار مجلدات أقل لا يعني وحده أن البيانات التاريخية للمستودع لم تُنزّل. [11][16]
تفيد أشجار العمل خصوصاً عند تشغيل مهام متعددة. يستطيع الوكيل العمل في مجلد، والمطور في آخر، وكلاهما مرتبط بالمستودع نفسه. يجنّب ذلك إعطاء كل مهمة نسخة مستقلة تماماً من المستودع. لكنه لا يحل التعارضات تلقائياً عندما تجتمع التغييرات. [15]
وتستحق المراجعة اهتماماً منفصلاً. التغيير الذي يبقى بلا قراءة يومين لن يصل إلى المستخدم أسرع بكثير لأن الاستنساخ أصبح أسرع ببضع ثوانٍ. تغييرات أصغر، ومسؤولية واضحة عن المراجعة، واختبارات تكتمل بصورة موثوقة: تحسينات معقولة لتجربتها قبل استبدال النظام الذي يحتفظ بالتاريخ.
كما أن واجهة أوامر Git ليست فوق النقد. إذا وجد الفريق واجهة أسهل، فليختبرها. يستخدم Jujutsu، مثلاً، مستودعات Git لتخزين الإيداعات والملفات، مع نموذج مختلف للتعامل مع التغييرات، ويستطيع تبادل العمل مع مستودعات Git البعيدة. [18] تجربة هذا النهج التزام أصغر كثيراً من تحمّل مسؤولية خدمة جديدة لإدارة الشيفرة وكل ما يحيط بها.
الإبقاء على Git يترك مساحة واسعة لتحسين طريقة استخدامه.
يحتاج الانتقال إلى مشكلة تخصك
عبارة «Git مثالي لـ99.999% منا» رأي، ومنازلها العشرية للتأكيد البلاغي. الادعاء الذي يمكن الدفاع عنه هو أن Git خيار افتراضي ممتاز لتطوير البرمجيات المعتاد. ويستحق الاستبدال عندما يحل نظام آخر مشكلة محددة بما يكفي لتغطية تكلفة الانتقال والتشغيل المستمر.
يشمل هذا التقدير العمل الذي لا يظهر في الإعلان. سيتولى أحد صيانة التكاملات، وتعليم طريقة العمل، وفحص الأتمتة المعطلة، والتعافي من الأخطاء. لا يلغي التنفيذ الأقل تكلفة هذه المسؤوليات.
يستحق الانتقال مكانه حين يزيل اختناقاً قِسته فعلاً.
لو كان فريق يفكر في الانتقال، لبدأت بجمع قياسات أسبوع من العمل الحالي. افصل الوصول إلى المستودع عن البناء والاختبار والمراجعة والنشر. سجّل الوقت الذي تقضيه المهام في جلب البيانات، وتكرار فشل عمليات المستودع، ومدة انتظار التغييرات المكتملة لقرار. وانظر إلى فترات الذروة إلى جانب المتوسطات.
ثم قدّر ما الذي سيزيله البديل المقترح فعلاً. إذا كان الوصول إلى المستودع يستهلك حصة كبيرة ومتزايدة من الحوسبة، أو يعطّل عملاً مفيداً، فاختبر بديلاً على ذلك الحمل. وأدخل في الحساب تكلفة تشغيله والأدوات التي ستحتاج إلى التغيير.
أما إذا كانت عمليات المستودع سريعة بالفعل، فسأُبقي Git وأقضي الأسبوع التالي في تقليل فشل البناء، والتغييرات المفرطة في الحجم، وانتظار المراجعة. قِس ما إذا كان مزيد من العمل المكتمل يصل إلى المستخدمين قبل الالتزام بمشروع أكبر للبنية التحتية.
المصادر
توثيق أصلي وإعلانات مباشرة ومقابلات. تحافظ الرسوم على تواريخ المصادر ووحداتها وصياغاتها التقريبية. تمت المراجعة في 16 أكتوبر 2026. أُبقيت عناوين المصادر بلغتها الأصلية.
Anthropic — Redesigning source control at Anthropic. 13 October 2026; updated 15 October.
Pro Git — About Version Control. Background on centralised and distributed version control.
Pro Git — A Short History of Git. Linux, BitKeeper and Git’s original design goals.
The Linux Foundation — 10 Years of Git: An Interview with Git Creator Linus Torvalds. 6 April 2015. Torvalds’s account of the dispute, early implementation and distributed workflow.
GitHub — Git turns 20: A Q&A with Linus Torvalds. 7 April 2025. First commit, early design and long-term maintenance.
GitHub — Celebrating 15 years of Git: An interview with Git maintainer Junio Hamano. 7 April 2020. Hamano’s account of taking over in July 2005.
GitHub — We Launched. Original public launch announcement, 10 April 2008.
GitHub Docs — Pull requests. Review, discussion and checks supplied by the hosting platform.
Pro Git — What is Git?. Snapshots, reused file contents and local operations.
Pro Git — Branches in a Nutshell. Commit ancestry and lightweight branch references.
Git reference — git-clone. Shallow history and partial-clone filters.
Google Research — Why Google Stores Billions of Lines of Code in a Single Repository. Rachel Potvin and Josh Levenberg, Communications of the ACM, 2016.
Meta Engineering — Sapling: Source control that’s user-friendly and scalable. 15 November 2022. Internal scale, development history and Git-compatible client.
GitHub — Building Git infrastructure for agent-scale development. Published 6 October 2026; updated 7 October. GitHub’s reported activity, growth comparisons, and infrastructure redesign in progress.
Git reference — git-worktree. Multiple working trees attached to one repository.
Git reference — git-sparse-checkout. Limiting the files materialised in a working tree.
GitHub Docs — About Git Large File Storage. Pointer files and separately stored large objects.
Jujutsu — Project README. Git storage, interoperability and a different version-control interface.
رسالة واحدة مع كل مقال جديد، فيها أبحاث وقرارات منتج وما تبلغنا به الفرق.
