GitHub يضيف هوية ثالثة إلى الكوميتات: من نفّذ عملية push فعلياً

بدأ GitHub بتسجيل هوية المستخدم الموثَّق الذي نفّذ عملية push بشكل دائم، وعرض هذه الهوية في الواجهة وفي API إلى جانب الحقلين author وcommitter الموجودين أصلاً. تحمل الميزة اسم push attribution، وهي متاحة حالياً في limited public preview فقط. نُشر الإعلان في GitHub Changelog بتاريخ 12 أكتوبر 2026. وبذلك أصبح لكل كوميت ثلاث هويات بدل اثنتين، وإحداها مؤكَّدة من المنصة.

ما الذي تغيّر بالضبط

في git، يُعبَّأ الحقلان author وcommitter من جهة العميل. تُؤخذ قيمهما من الإعداد المحلي أو من متغيرات البيئة، ولا يمنع شيء من وضع اسم شخص آخر وبريده فيهما. يطابق GitHub هذه العناوين مع الحسابات، ويمكنه وسم الكوميت بـVerified إذا كان موقَّعاً، لكن التوقيع ليس موجوداً في كل كوميت، بل في قلة منها. أما حقيقة «من أرسل هذا إلى المستودع» فلم يكن ممكناً في السجل العام استنتاجها سابقاً إلا بشكل غير مباشر، مثلاً عبر أحداث المستودع أو سجلات التدقيق.

تسدّ push attribution هذه الثغرة. فالمنصة تعرف من صودق عليه عند عملية push، وتحفظ الآن هذه المعلومة جزءاً من بيانات الكوميت. يظهر الحقل pusher في الواجهة ويتوفر عبر API.

لماذا يهم ذلك في عصر الوكلاء

لا يشرح الإعلان الدافع بالتفصيل، لذلك ما يلي يتناول المنطق الهندسي لا تصريحات GitHub. يمرّ الكوميت النموذجي اليوم عبر عدة أيدٍ. قد يكون المؤلف مطوّراً، ويتغيّر committer عند rebase أو squash أو cherry-pick، ثم يدفع كل ذلك رمز خدمة أو وكيل ذكاء اصطناعي يعمل باسم المستخدم. وتقدّم الحقول الثلاثة ثلاث إجابات مختلفة عن سؤال «لمن يعود هذا الكود».

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

ما المعروف وما غير المعروف

• الحالة: limited public preview، والإعلان بتاريخ 12 أكتوبر 2026
• القيمة الجديدة: pusher، أي المستخدم الموثَّق الذي نفّذ عملية push
• أين تظهر: واجهة GitHub وAPI، إلى جانب author وcommitter
• مصدر البيانات: المصادقة على جانب الخادم، لا git config على جانب العميل
• لم يكشف عنه الإعلان: التعرفة، وقائمة الحسابات والمؤسسات المتاحة لها الميزة، وسلوكها مع الكوميتات القديمة، والصيغة الدقيقة للحقل في REST وGraphQL، وكيفية عرض GitHub Apps والبوتات

النقطة الأخيرة هي الأكثر إثارة للاهتمام. فالقيمة العملية للميزة، بالنسبة إلى من يبنون الأتمتة حول المستودعات، تتوقف على كيفية عرض الحقل للتطبيقات والوكلاء.

ما الذي ينبغي أن تتحقق منه الفرق الآن

ما دامت الميزة في مرحلة المعاينة، فمن المبكر إدخالها في العمليات الحرجة، لكن يمكن الاستعداد. أولاً، تحقق مما إذا كانت المعاينة متاحة لمؤسستك، وجرّبها على مستودع غير أساسي. ثانياً، افحص أي التكاملات تدفع إلى كودك: الرموز الشخصية، وGitHub Apps، ومشغّلات CI، والوكلاء. فما ستراه في الحقل pusher يعتمد على ذلك. ثالثاً، إذا كانت لديك سكربتات تدقيق تجمع الآن «من رفع» من الأحداث والسجلات، فقيّم إمكانية استبدالها باستعلامات API عندما تستقر صيغة الحقل. وأخيراً، لا تتخلَّ عن توقيع الكوميتات: فـpusher يبيّن من سلّم الكود، لكنه لا يثبت من كتبه.