سير عمل بوابة:دمج وإصلاح الصراعات مرة واحدة

Question

لدينا سير عمل بسيط مع ثلاثة فروع رئيسية

staging أي بيئة الاختبار

master أي بيئة الإنتاج

dev/XXX حيث XXX هو رقم التذكرة

• عملاء تسجيل التذاكر
• نقوم بإنشاء فرع على سبيل المثال dev/2332
• نحن نعمل + نلتزم + ندفع
• نقوم بدمج العمل عندما يكون جاهزًا staging
• يوافق العميل على العمل staging
• نقوم بدمج العمل في master ويتم نشر التذكرة عند الإنتاج

المشكلة:

إذا كان العديد من المطورين يعملون على كل منهم dev/XXX الفروع؛عندما يندمجون في staging, في بعض الأحيان، يخلقون الصراعات.إنهم يقومون بإصلاح تلك الصراعات على المسرح والدفع.

المشكلة هي عندما يوافق العميل على تلك التذاكر المحددة ونقوم بدمج العمل فيها master, ، علينا إصلاح الصراعات مرة أخرى

مهم:

• لا يمكننا دمج التدريج في البرنامج الرئيسي -- بسبب التذاكر غير المعتمدة
• يتم إنشاء جميع الفروع بشكل افتراضي من أحدث فرع رئيسي
• يتم تطوير تذاكر متعددة في وقت واحد ولكن يتم نشرها عند الموافقة عليها
• يعد إعادة التأسيس من الرئيسي لتجنب التعارضات خيارًا فقط إذا تمت الموافقة على العمل + نشره بالفعل
• إعادة التأسيس من التدريج هو لا خيار - بسبب التذاكر غير المعتمدة

أي أفكار حول كيفية حل هذه المشكلة؟هل سير العمل لدينا معيب؟هل نفتقد بعض اختراق git؟

في الأساس، لا أريد أن يكرر الفريق نفس الشيء مرتين

شكرًا لك

Answer 1

ينظر الى فرع لكل ميزة.يجب أن تحصل على رسالتي حول هذا الموضوع بالذات.لقد أجبت أيضًا على سؤال هنا حول تقاسم ذاكرة التخزين المؤقت rerere

Answer 2

تحتاج إلى الاحتفاظ بها master و staging قريبة من بعضها البعض قدر الإمكان.يمكنك محاولة التعامل معها بالطريقة التي تستخدمها git نفسها pu فرع.وهذا هو عند اكتمال مهمة جديدة، الفرع تم الحذف, ، أعيد إنشاؤها من master وتم دمج جميع الميزات التي تنتظر الموافقة.وميزة ذلك هي أن الفروع لا تتباعد وأنه لا توجد مشكلات في إلغاء دمج الميزات المرفوضة.العيب هو أنه لا يمكنك أن تبني أي عمل عليه، لكنك لا تفعل ذلك على أي حال.

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

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