ما المقصود بطلب السحب؟

طلب السحب (PR) هو طريقة لاقتراح التغييرات على قاعدة التعليمات البرمجية. ويقوم مطورو البرامج بنسخ مستودع التعليمات البرمجية الرئيسي (المسمى أيضًا repo) إلى فرع منفصل، ويضيفون التعليمات البرمجية إلى هذا الفرع أثناء عملهم، ثم يقومون بإنشاء طلب سحب للإشارة إلى التغييرات المقترحة لـ تقييمات التعليمات البرمجية قبل سحب التغييرات أو دمجها من الفرع إلى قاعدة التعليمات البرمجية الرئيسية.

طلبات السحب هي آليات شائعة في مستودعات Git مثل Bitbucket وGitHub. يستخدم GitLab مصطلح "طلب الدمج" بدلاً من طلب السحب للعملية نفسها.

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

تسمح طلبات السحب للمطورين بصياغة مصدر الرمز واختباره محليًا. ونظرًا لأن تغييرات التعليمات البرمجية معزولة عن الفرع الرئيسي، فلا داعي للقلق بشأن كسر قاعدة التعليمات البرمجية بأكملها.

تتضمن منهجية طلب السحب ثلاثة أدوار حيوية تنطبق غالبًا على المشاريع ذات المصدر المفتوح، ولكن يمكن أيضًا اعتمادها من قبل المشاريع المملوكة أو مغلقة المصدر:

• المشرفون على الصيانة: يدير مشرفو المشروع (وغالبًا ما يمتلكونه) المشروع ولديهم السلطة للموافقة على طلبات السحب ودمجها أو رفضها.

• المراجعون: يراجع أعضاء الفريق هؤلاء (الذين يمكن أن يكونوا هم أنفسهم مشرفين أو مساهمين نشطين آخرين لديهم تجربة كبيرة في المشروع) التغييرات المقترحة لجودة التعليمات البرمجية ويقترحون التحسينات التي يرونها مناسبة.

• المساهمون: يتم تكليف هؤلاء المطورين بإجراء التغييرات وفتح طلبات السحب.

يتطلب إنشاء طلبات السحب عمومًا إجراءً مكون من سبع خطوات:

1. يقوم المساهم بتقسيم المستودع الرئيسي لإنشاء فرع جديد (باستخدام الأمر git checkout أو واجهة الويب) ويقوم باستنساخ هذا الفرع إلى جهازه المحلي.
   
   
2. يعمل المساهم على تغييراته ويلتزم بالتعليمات البرمجية محليًا للفرع.
   
   
3. بمجرد انتهاء المساهم من التعليمات البرمجية واختبارها، يقوم أولاً بسحب آخر التحديثات من المستودع الرئيسي لتجنب أية تغييرات متضاربة قبل دفع التعليمات البرمجية الخاصة به.
   
   
4. يفتح المساهم طلب سحب جديد لدمج التغييرات المقترحة في الفرع الرئيسي.
   
   
5. يتلقى المراجعون إشعارات عند إرسال طلبات السحب. ويقومون بفحص طلبات السحب لمقارنة الفروقات بين فرع المساهم والفرع الرئيسي، ويراجعون التعليمات البرمجية ويعلقون على المجالات التي تحتاج إلى تحسين أو تطوير.
   
   
6. يقدم المساهمون التزامات إضافية بناءً على اقتراحات المراجعين وطلبات التغيير.
   
   
7. عندما يتم تنفيذ جميع التغييرات، يقوم المراجع بإخطار المسؤول عن الصيانة، الذي يوافق على طلب السحب، ثم يتم دمج طلب السحب في المستودع الرئيسي.

يمكن لفرق تطوير البرمجيات اختيار عدد من خيارات سير عمل طلبات السحب حسب احتياجاتهم. تتضمن عمليات سير عمل طلب السحب الشائعة ما يلي:

• سير العمل فرعي للميزات

• سير العمل المتفرع

• git-flow

• سير عمل مكدس

كل ميزة جديدة تحصل على فرع مخصص مع اسم وصفي لتسليط الضوء على هدف الميزة. وبمجرد اكتمال الميزة، يمكن للمطورين دفع فرع الميزة إلى الفرع الرئيسي وإنشاء طلب سحب.

يحافظ سير العمل هذا على استقرار الفرع الرئيسي حيث يعمل المساهمون بشكل منفصل على الميزات. لكن إدارة فروع الميزات المتعددة قد تصبح عملية معقدة.

يتوافق الإجراء المكون من سبع خطوات الموضح في القسم السابق حول إنشاء طلبات السحب مع سير عمل متفرع. وغالبًا ما تستخدم مشاريع المصدر المفتوح سير العمل هذا، الذي يكمل أيضًا ممارسات التكامل المستمر/التسليم المستمر (CI/CD). يتبع تدفق GitHub عملية مشابهة لسير العمل المتفرع.

قام مهندس البرمجيات Vincent Driessen بصياغة git-flow في عام 2010. ويتم استخدامه عادةً لبناء البرامج ذات جداول الإصدار الصارمة أو تلك التي تدعم الإصدارات المختلفة.

يتبع سير العمل هذا نموذجًا فرعيًا يتكون من هذه الفروع:

• main يحمل أحدث إصدار مستقر

• develop يكون بمثابة فرع تكامل لإصلاح الأخطاء، والميزات، والتغييرات البرمجية الأخرى التي تضمنها الإصدار التالي

• feature يستخدم التطوير كفرع المصدر والفرع المستهدف، مع دمج الميزات في التطوير عندما تكون جاهزة

• release يتم تفريعه من الفرع التطوير وتمييزه برقم الإصدار للإصدار التالي، ثم يتم دمجه في كل من الفرع التطوير والفرع الرئيسي بمجرد أن يصبح جاهزًا للإطلاق

• hotfix يتم تفريعه مباشرةً من الفرع الرئيسي لإصلاح أية مشكلات ذات أولوية عالية أو عالية الخطورة في الإنتاج، ثم يتم دمجه في كل من الفرع التطوير والفرع الرئيسي بمجرد الانتهاء من الإصلاحات

يقوم المطورون بإنشاء طلبات سحب لـ hotfix ، وfeature وrelease من الفروع التي تحتاج إلى مراجعتها.

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

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

توفر طلبات السحب هذه المزايا:

• تعزيز التعاون

• تحسين جودة التعليمات البرمجية

• زيادة الشفافية

• تعزيز مهارات البرمجة

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

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

تسمح طلبات السحب للفرق بمعرفة التغييرات التي تم تنفيذها، ومن قام بها، ومكان تطبيقها والأسباب الكامنة وراءها. وتوفر هذه الرؤية رؤى أفضل لحالة قاعدة التعليمات البرمجية والمشروع نفسه.

يمكن لكل من المراجعين والمساهمين التعلم من بعضهم البعض، والتقاط تقنيات جديدة على طول الطريق واكتشاف أساليب جديدة للمشكلات. ويمكن للمبتدئين وأعضاء الفريق الجدد أيضًا دراسة طلبات السحب السابقة لفهم قاعدة التعليمات البرمجية بشكل أفضل والتعرف على معايير البرمجة وأفضل الممارسات الخاصة بالفريق.

بينما يبدو إنشاء طلبات السحب أمرًا سهلاً، إليك بعض النصائح والحيل التي يمكن أن تزيد من سلاسة العملية:

• فكر في المسودات

• التفاصيل مهمة

• الحفاظ على التركيز

• التحديث المستمر

• استخدام القوالب

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

يجب على المطورين تقديم رسائل واضحة وموجزة ومحددة لالتزاماتهم الجديدة. وينطبق الوضوح والإيجاز والخصوصية أيضًا على عناوين وأوصاف طلبات السحب، مما يجعل من الأسهل والأسرع للمراجعين استخلاص القصد من تغييرات التعليمات البرمجية.

قد يؤدي تجميع عدة مشكلات في طلب سحب واحد إلى إطالة وقت التقييمات وزيادة عدد التعديلات. ويجب أن يكون عنوان كل طلب سحب إصلاح خطأ واحد أو ميزة واحدة فقط. يمكن أن تؤدي طلبات السحب المركزة إلى تقييمات أكثر كفاءة للتعليمات البرمجية.

قبل دفع التعليمات البرمجية وفتح طلب سحب، يجب على المطورين التأكد من تحديث فرعهم. ويؤدي التقاط أحدث التغييرات وأي التزامات جديدة إلى منع حدوث تعارضات بمجرد دمج طلب السحب. ويمكنهم استخدام إما الأمر git pull لجلب ودمج التغييرات من الفرع المستهدف أو الأمر git rebase للحصول على سجل التزامات git نظيف.

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

عادةً ما تتم كتابة القوالب باستخدام لغة الترميز Markdown وتوضع في المجلد الجذر أو الفرع الرئيسي لمستودع المشروع. تشمل الحقول النموذجية ما يلي:

• وصف المشكلة أو الميزة (مع رابط إلى التذكرة المقابلة في Jira أو أي برنامج آخر لتتبع المشكلات للرجوع إليها)

• حل يحدد تغييرات التعليمات البرمجية بالتفصيل

• الاختبار، مثل اختبار الوحدة أو حالات اختبار التكامل، تغطية الاختبار وخطوات التحقق من صحة الحل يدويًا إذا كان ذلك ممكنًا

• تغييرات التكوين

• قائمة التحقق من المهام ذات الصلة، مثل الوثائق وبناء التعليمات البرمجية النظيفة دون أخطاء أو تحذيرات

يمكن أن تؤدي أتمتة طلبات السحب إلى تسريع دورة حياة طلب السحب من الإنشاء وحتى التقييمات والدمج. ويشمل طلب السحب الأتمتة طبقة من الأنظمة التي تساعد في تخفيف الاختناقات:

• طلبات السحب المكدسة

• مسارات CI/CD

• أنظمة إدارة SDLC

• مساعدو البرمجة المدعومون بالذكاء الاصطناعي

معظم مستودعات Git ليست مصممة لدعم سير عمل مكدس، لكن بعض الأدوات تتجاهل تعقيد مزامنة طلبات السحب المكدسة والتعامل مع تعارضات الدمج. وتشمل هذه الأدوات منصة Graphite، التي تحتوي على سطر أوامر وامتداد لـ VS Code من Microsoft لطلبات السحب المكدسة وواجهة ويب لإدارتها؛ نظام Sapling لإدارة مصدر الرمز من Meta؛ ونظام ghstack CLI مفتوح المصدر لتقديم الفروقات المكدسة إلى GitHub كطلبات سحب منفصلة.

سير عمل DevOps تلقائي، يساعد مسار CI/CD في ضمان جودة التعليمات البرمجية. يمكن لمنصات مثل GitHub Actions وGitLab وغيرها من أدوات CI تشغيل اختبارات الوحدات واختبارات التكامل ونشر بيئات المعاينة التي تعمل كآليات تحديد الوصول لعرض واختبار تغييرات التعليمات البرمجية في طلبات السحب.

تعمل مسارات CI/CD أيضًا على تعزيز ممارسات البرمجة الآمنة. وتندمج أدوات تحليل التعليمات البرمجية الثابتة وأدوات اختبار أمان التطبيقات الثابتة (SAST) بسلاسة مع معظم بيئات CI/CD لتحديد الثغرات الأمنية المحتملة في التعليمات البرمجية. ويمكن لفرق DevOps تنفيذ آليات ما قبل الالتزام لكشف الأسرار، ما يجعل المسح السري خطوة مطلوبة قبل أن يقوم المطورون بالتزام التعليمات البرمجية أو بدء طلبات السحب، ومنع التغييرات التي تحتوي على أسرار مشفرة صلبة.

منصات مثل Jira وIBM Engineering Lifecycle Management (ELM) تدعم تتبع وإدارة طلبات السحب طوال دورة حياة تطوير البرمجيات (SDLC).

كجزء من مجموعة ELM، تقوم IBM Engineering Workflow Management (EWM) وIBM Engineering Integration Hub بدمج الأتمتة مباشرةً في عمليات سير عمل التطوير. ويمكن أن تتصل EWM بمستودعات Git من خلال موصلات المحور وتحفيز إنشاء طلبات السحب من عناصر العمل. وعندما تتم الموافقة على متطلب أو طلب تغيير في EWM، يمكن للقاعدة فتح طلب سحب تلقائيًا في مستودع Git المرتبط وتعبئة الوصف مسبقًا.

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

يمكن لمساعدي البرمجة المدعومة بالذكاء الاصطناعي مثل GitHub Copilot وIBM Bob تعزيز عمليات سير عمل طلبات السحب. على سبيل المثال، يمكن لـ Bob إنشاء رسائل التزام جيدة التنسيق وذات مغزى. ويفحص اسم الفرع وسجل الالتزام لمطابقة اصطلاحات نمط المشروع.

يمكن لـ Bob أيضًا إنشاء طلب سحب مباشرةً من IDE الخاص بالمطورين. ويقوم بتحليل اسم الفرع، وتغييرات التعليمات البرمجية، وسجل الالتزامات لفهم الغرض والنطاق. ثم يُنشئ عنوانًا لطلب السحب ووصفًا تفصيليًا يلخص التغييرات، ويكتشف تلقائيًا قوالب طلبات السحب الحالية للمشروع ويستخدمها لأوصاف طلبات السحب.