Coroid ينتهي بفتح فرع pull request خاص به مقابل الفرع الأساسي الخاص بك. لا يقوم بالدمج تلقائيًا أبدًا. الدمج دائمًا قرار يُتخذ من قبل شخص ما، سواء في بيئة المزود أو مع الموافقة والدمج في Coroid. انظر إلى الدمج.
ما الذي يصل معه؟
- تغيير الكود
- الاختبارات التي تم كتابتها أو تحديثها إلى جانبه
- نتيجة تشغيل مجموعة الاختبارات الحالية لديك
- نتيجة أي بوابات جودة قامت مؤسستك بإعدادها
- مراجعة للفروقات، مع وجود نتائج تم إصلاحها بالفعل أو مدرجة في القائمة
الهدف ليس استبدال مراجعتك. بل أن مراجعتك لا يجب أن تكون الأولى.
main- تغيير الكود4 ملفات
- اختبارات تم كتابتها أو تحديثها2 ملفات
- مجموعة الاختبارات الحالية الخاصة بكنجح
- بوابات الجودةوجد إرشاد واحد
- اجتياز المراجعةتم إصلاح 2، ورد 1
ما الذي يجب فحصه فعليًا؟
تم فحص الجوانب الآلية بالفعل. ركّز اهتمامك على الأمور التي لا يمكن سوى لك تقييمها:
- هل يحل المشكلة الصحيحة؟ قارنه بمعايير القبول المحددة في المواصفات، وليس بذاكرتك عما طلبته.
- هل يتناسب مع قاعدة الكود؟ الاتفاقيات، التسمية، شكل التجريد. تقوم Coroid بقراءة كودك لاستنتاج هذه الأمور، وتحقق فيها نتائج جيدة في الغالب — لكن ليس دائمًا.
- ما الذي يؤثر عليه دون أن تتوقع ذلك؟ اطلع على قائمة الملفات قبل الفروقات.
- هل الاختبارات الجديدة ذات معنى؟ اختبار ناجح لا يثبت أي شيء هو أسوأ من عدم وجود اختبار.
إعادة العمل
لديك ثلاث خيارات، بترتيب تصاعدي من حيث التكلفة:
- إضافة تعليق وطلب إعادة العمل — تُعاد المهمة إلى عامل التطوير الآلي مع نتائجك، مع الحفاظ على سياقها. الأفضل لحالة «هذا صحيح لكنه غير كامل».
- رفض الخطة وإعادة التشغيل — عندما يكون المنهج خاطئًا، وليس التنفيذ.
- إلغاء المهمة — عندما لا ينبغي تنفيذ العمل أصلًا. الإلغاء يوقف التشغيل ويحرر مساحة العامل الآلي.
كن دقيقًا في تعليقات إعادة العمل كما لو كنت تتحدث مع زميل. "هذا لا يتعامل مع الحالة الفارغة في parseRange" ينتج عنه تصحيح؛ أما عبارة "يحتاج إلى تحسين" فتؤدي إلى تخمين.
الدمج
Coroid لا يقوم بالدمج من تلقاء نفسه أبدًا. ولا يوجد إعداد يجعله يدمج عند اكتمال المهمة. يحدث الدمج بطريقتين، وكلاهما يبدأ بقرار من شخص ما للدمج.
ينطبق هذا على العمل الذي يُبدأ ضمن تفويض أيضًا. تسجل Coroid ما كان سيقرره بشأن كل عملية دمج لتقييم حكمها الخاص، لكنها لا تتصرف بناءً على هذه السجلات. انظر ما يقرره Coroid وما يبقى بيدك.
في GitHub أو GitLab
قم بدمج pull request في بيئة الاستضافة الخاصة بك، باستخدام قواعد حماية الفروع والفحوصات المطلوبة وقواعد الموافقة المعتادة لديك. pull request فرع عادي تمامًا — وهذا مقصود — لذا يمر عبر عمليات المراجعة واختبارات التكامل المستمر التي تثق بها.
من Coroid، مع خيار الموافقة والدمج
شاشات المراجعة في Coroid تحتوي على الموافقة والدمج زر. يطلب منك التأكيد، ثم تقوم Coroid بدمج pull request نيابة عنك عبر GitHub أو GitLab، باستخدام اتصال المستودع الخاص بالمشروع. وهو نفس إجراء الضغط على زر الدمج في بيئة الاستضافة الخاصة بك، لذا تنطبق قواعد حماية الفروع والفحوصات المطلوبة وقواعد الموافقة. إذا منعت هذه القواعد عملية الدمج، تعرض Coroid سبب الرفض من بيئة الاستضافة ولا يتم الدمج.
ما يحدث قبل الدمج يعتمد على ما توافق عليه:
- مهمة. تحتاج المهمة إلى pull request أولاً. إذا لم يكن موجودًا بعد، تقدم شاشة المراجعة خيار إنشاء PR قبل الموافقة والدمج. عندما توافق، تدفع Coroid بفرع المهمة حتى يحتوي pull request على أحدث الالتزامات التي تمت مراجعتها، ثم تقوم بدمج pull request. يتطلب الموافقة على مهمة صلاحيات كتابة للمشروع الخاص بها.
- خطة. لا يمكن دمج المهام التابعة لخطة بشكل منفصل. يتم الموافقة على فرع pull request الخاص بالخطة من خلال مراجعة الترقية. تتحقق Coroid أولاً من أن الفرع الأساسي لم يتغير منذ بدء الخطة (انظر عندما يتغير الفرع الأساسي), وتنجح الفحوصات المطلوبة للجودة، ولا توجد تعارضات في الدمج في pull request، ولا توجد حواجز تمنع الدمج. ثم تقوم بدمج pull request. يتطلب الموافقة على خطة صلاحيات كتابة للمشروع الخاص بها.
- الدمج الإجباري. توفر مراجعة الترقية للخطة أيضًا خيار الدمج الإجباري. يتجاوز هذا الخيار فحوصات الفرع الأساسي وتعارضات الدمج وحواجز المسار في Coroid، لكنه لا يتجاوز الفحوصات المطلوبة للجودة أو قواعد بيئة الاستضافة الخاصة بك. يتطلب ذلك سببًا مكتوبًا يُسجل مع عملية الترقية، بالإضافة إلى صلاحيات مسؤول للمشروع.
الـ مساعد الدردشة و عملاء بروتوكول MCP يمكنهم أيضًا الموافقة على pull request الخاص بالخطة أو دمجها قسرًا. يعملون نيابة عنك، لذا تُطبق عليهم نفس عمليات التحقق وقواعد الوصول إلى المشروع. يطلب المساعد منك دائمًا التأكيد أولاً. عملية الدمج القسرية من عميل بروتوكول MCP تنتظر دائمًا في عمليات الموافقة ليتم معالجتها بواسطة شخص. يعتمد انتظار موافقة عميل بروتوكول MCP هناك على سياسات الأتمتة الخاصة بك. لا يمكن لأي منهما دمج مهمة واحدة.
جهّز ما سيتم إصداره
بعد الدمج، افتح علامة تبويب إصدارات في مشروعك و اختر إصدار جديد. اختر الالتزام المدمج الذي تريد إصداره؛ يعرض Coroid طلبات السحب التي يحتويها. ثم تقوم صفحة الإصدار بإرشاد كل بيئة عبر أربع خطوات: التحقق، والموافقة، والنشر، والصحة. لا يزال مستودعك وCI/CD هما اللذان يقومان بالنشر. لا يُعلن Coroid عن إصدار تم نشره إلا بعد تأكيد خط أنابيب التوزيع، أو عندما يسجل مالك أو مشرف نشرًا خارجيًا تم التحقق منه.
التالي
إصدارات — جهّز الالتزام المدمج وتابعه عبر كل بيئة. إلى أين ننتقل الآن؟ تعرض سير العمل الأخرى.