كيفية إعادة البناء في فرع دون أن أفقد عقلي؟

Question

أقوم بإعادة صياغة الكود الخاص بي وكود الآخرين طوال الوقت.عندما أعمل في فرع وليس في Trunk، يؤدي هذا أحيانًا إلى بعض عمليات الدمج المؤلمة للغاية، خاصة إذا لم أقم بالدمج مرة أخرى في Trunk بانتظام (يتحول الكود الموجود في الفرع ببطء بعيدًا عن Trunc، وعندما يقوم الأشخاص بتعديل Trunk I يجب أن تعرف يدويًا كيفية تطبيق ذلك على الفرع).

الحلول التي أعرفها هي إما

1. الدمج المستمر من وإلى الجذع - يقلل من عمليات الدمج المؤلمة، ولكن لماذا العمل في فرع على الإطلاق؟
2. عندما تحتاج إلى إعادة بناء شيء ما، قم بالتبديل إلى Trunk، وقم بإعادة البناء هناك والاندماج في فرعك - لا أجد هذا عمليًا للغاية، نظرًا لأن التكلفة الفعلية لتبديل البيئات لكل عملية إعادة بناء ضخمة.

ماذا تفعل؟

Answer 1

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

يعد الدمج المستمر من وإلى صندوق السيارة ممارسة جيدة بشكل عام.

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

Answer 2

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

Answer 3

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

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

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

Answer 4

التغييرات يجب أن تكون إما سريع (لذلك ليس هناك الكثير من التغييرات تحت قيادتك) أو غير ذلك محلي (لذلك لا تهتم إلا بالتغييرات في عدد قليل من الأماكن).

وإلا فإن الدمج يمكن أن يكون بنفس القدر من العمل الذي كان عليه إعادة البناء.باعتباره خوارزمية، فإن القفل المتفائل لا يعمل ببساطة عندما تفشل العديد من المعاملات ويجب إعادة تشغيلها.

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

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

كما أن "إعادة بناء النظام بأكمله لاستخدام المصانع في كل مكان" ليست مهمة."إعادة بناء هذه الواجهة وتطبيقاتها لاستخدام المصانع" هي مهمة.

Answer 5

هذا هو المكان الذي يتفوق فيه VCS الموزع جيدًا.لكنني أعتقد أنك ملتزم بـ SVN بالفعل.

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

كان لدي فرع ذات مرة ظل خاملاً لمدة 3 أسابيع تقريبًا لأن الميزة "تم تعليقها" وكان من المستحيل دمجها.لقد بدأت للتو الميزة مرة أخرى في فرع جديد، باستخدام القديم كمرجع لأجزاء معينة.

Answer 6

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

إذا كان عليك التفرع تمامًا، فسأختار الخيار 1.حاول دمج أكبر قدر ممكن من التغييرات وقم بذلك بشكل متكرر.

Answer 7

التزم مبكرًا، والتزم كثيرًا.

أو في هذه الحالة...دمج في وقت مبكر، ودمج في كثير من الأحيان.

Answer 8

التكامل المستمر هو المفتاح...دفعة صغيرة من التغييرات في وقت واحد...