طلبات الدمج المكدّسة في ⁨GitHub⁩: مراجعات أصغر ودمج واحد

أعلنت ⁨GitHub⁩ في 6 أكتوبر 2026 أن طلبات الدمج المكدّسة صارت متاحة للجميع. الفكرة بسيطة: بدل طلب دمج واحد ضخم، تقسّم التغيير إلى سلسلة طلبات صغيرة، كل واحد منها يُراجَع وحده، ثم تُدمج السلسلة معًا. قد يبدو هذا تفصيلًا في واجهة، لكنه يمسّ أضعف نقطة في المراجعة: ما يحدث لانتباه المراجِع حين يكبر الفرق بين النسختين.

لماذا يمرّ الطلب الكبير بلا مراجعة حقيقية

هذه قاعدة عامة يعرفها كل من راجع كودًا: الملف الأول يحظى بأسئلة جادة، وعند الملف الرابع عشر يكتفي المراجِع بالتأكد من أن ما أمامه يشبه الكود. الخطأ المهم نادرًا ما يكون في الملف الذي توقّع الجميع خطورته؛ يكون غالبًا في تعديل صغير على دالة مشتركة في منتصف الطريق، حيث لم يعد أحد ينظر. والكاتب يخسر أيضًا: وصف طلب من 1,500 سطر صعب الكتابة، فينتهي عادة بعبارة "راجع الفرق".

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

ما هي السلسلة، وما الذي أضافه الإطلاق العام

السلسلة فروع متتابعة، كل فرع مبني على الفرع الذي قبله، ولكل فرع طلب دمج خاص به. الأول يضيف تعديل قاعدة البيانات، والثاني الخدمة التي تستخدم العمود الجديد، والثالث نقطة الوصول التي تستدعي الخدمة.

المشكلة لم تكن في الفكرة، بل في لحظة يطلب فيها أحدهم تعديلًا في الطلب الأول بعد مراجعة الثاني والثالث. كان عليك إعادة بناء كل فرع فوقه يدويًا، وفي المستودعات التي تُسقط الموافقات القديمة تضيع مراجعات الطلبات العليا كذلك. هنا تحديدًا يتدخل الإطلاق العام بحسب ⁨GitHub⁩: زر ⁨Rebase stack⁩ يحفظ الموافقات على الكود الذي لم يتغيّر، حتى في تلك المستودعات. والإيداعات المعاد بناؤها تبقى موقّعة، لأن ⁨GitHub⁩ تنشئ إيداعات بديلة موقّعة وتحتفظ بالمؤلف الأصلي.

وبقية الإطلاق تخص لحظة الدمج. تدخل السلسلة طابور الدمج وتخرج منه مجموعة دمج واحدة، ومع طريقة إيداع الدمج تنشئ ⁨GitHub⁩ إيداع دمج لكل طلب. صلاحيات التجاوز تنطبق على أدنى طلب لم يُدمج بعد. وإذا تفرّعت السلسلة وحُذف فرعها الأساسي، يُعاد توجيه الطلبات تلقائيًا بدل إغلاق الطلب الأدنى. أما الدمج التلقائي للسلاسل، حيث تُدمج كل طلبات المجموعة المختارة معًا حين تجهز كلها، فيصل تدريجيًا خلال الأسابيع التالية. وللتنقل: السلسلة تظهر في رأس الطلب، والاختصاران ⁨Shift+J⁩ و⁨Shift+K⁩ ينقلانك بين طلباتها، ويسجّل الخط الزمني إضافة طلب أو إزالته، ويحمل حدث ⁨pull_request⁩ نوعًا جديدًا هو ⁨stacked⁩، وإضافة ⁨gh stack⁩ لأداة سطر الأوامر تعمل مع ⁨Git worktrees⁩.

ونشرت ⁨GitHub⁩ أرقامًا من فترة المعاينة: تقول إن المستودعات التي استخدمت السلاسل دمجت كودًا أكثر بنسبة 9% من نظيراتها، وإن أكثر من ثلثي أعلى 1% من المستودعات تستخدمها الآن وتحسّن عندها وقت الوصول إلى الدمج بنسبة 5%. هذه قياسات الشركة لميزتها هي، لا دراسة مستقلة.

حين تكون المراجِع الوحيد

كثير من العمل الحر لا يوجد فيه مراجِع ثانٍ أصلًا، ومع ذلك تبقى للسلسلة فائدة، لأسباب عامة لا علاقة لها بأرقام ⁨GitHub⁩. مراجعتك لفرق من 200 سطر صباح اليوم التالي تلتقط ما لن تلتقطه مراجعتك لفرق من 1,500 سطر. ويمكنك أن تُري العميل الخطوة الثانية تعمل قبل أن توجد الثالثة. وحين ينكسر شيء بعد شهر، يقف ⁨git bisect⁩ عند تغيير صغير له اسم، لا عند إيداع عملاق. وإذا تسلّم مطوّر العميل المشروع لاحقًا، يرث تاريخًا يستطيع قراءته.

متى لا تكدّس

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

في المرة القادمة التي يتجاوز فيها فرعك بضع مئات من الأسطر، توقّف قبل فتح الطلب واكتب الخطوات التي مرّ بها فعلًا. كل خطوة يستطيع المراجِع أن يوافق عليها وحدها طلب في السلسلة، والباقي يبقى معًا. المصدر: سجل تغييرات ⁨GitHub⁩ بتاريخ 6 أكتوبر 2026.