SVN Workflow - الدجاج قبل البيض - قبل دمج V1 مع V2 ، أحتاج إلى رمز من V1 للعمل على V2

Question

يستخدم فريقنا الموزع (3 Devs الداخلية و 3+ Devs خارجية) SVN لإدارة قاعدة الشفرة الخاصة بنا لموقع ويب. لدينا فرع لكل نسخة ثانوية (4.1.0 ، 4.1.1 ، 4.1.2 ، إلخ ...). لدينا جذع ندمج كل إصدار فيه عندما نقوم بإصدار ونشر على موقعنا.

مثال على المشكلة التي نواجهها هي: تتم إضافة ميزة جديدة ، دعنا نسميها "القدرة على إنشاء مشروع" إلى 4.1.1. من المقرر أن تذهب ميزة أخرى تعتمد على واحد في 4.1.1 في 4.1.2 ، تسمى "القدرة على إضافة مهام للمشاريع".

لذلك ، يوم الاثنين ، نقول 4.1.1 "مغلق" ويجب اختباره. عادةً ما يبدأ مطورونا عن بُعد العمل على الميزات/التذاكر لمدة 4.1.2 في هذه المرحلة. على مدار الأسبوع ، سنختبر 4.1.1 ونصلح أي أخطاء ونلاحظها مرة أخرى إلى 4.1.1. بعد ذلك ، في يوم الجمعة أو نحو ذلك ، سنقوم بتمييز 4.1.1 ، وندمجه مع الجذع ، وأخيراً ، ندمجه بـ 4.1.2. ولكن ، خلال 4-5 أيام ، نختبر ، 4.1.2 ليس لديه الرمز من 4.1.1 أن بعض الميزات الجديدة لـ 4.1.2 تعتمد عليها.

لذا فإن Dev الذي يضيف ميزة "القدرة على إضافة المهام إلى المشاريع" ، وليس لديه ميزة "القدرة على إنشاء مشروع" للبناء عليها ، وعليها القيام ببعض نسخ ملفات الملفات لتتمكن من الاستمرار في العمل عليها .

ما الذي يمكن/يجب أن نفعله لتنعيم هذه العملية؟

PS الاعتذار إذا تم طرح هذا السؤال من قبل - أنا فعل ابحث ولكن لم أتمكن من العثور على ما أبحث عنه.

Answer 1

الطريقة التي نفعلها هي ذلك الكل يحدث التنمية في الجذع. حتى أنك تلتزم فقط بالجذع وبعد ذلك يتم دمج أي إصلاحات مطلوبة لمدة 4.1.1 من عند جذع ل فرع 4.1.1. يتم إنشاء الفرع لـ 4.1.2 فقط عند الاختبار في 4.1.2 يبدأ - بمجرد إجراء فرع 4.1.2 ، يستمر العمل في الجذع ، وإذا كانت هناك حاجة إلى أي إصلاحات لمدة 4.1.2 ، فهي مصنوعة في صندوق ثم يتم دمجها 4.1.2.

من النادر جدًا أن نجري تغييرًا في فرع يجب دمجه الى الخلف في صندوق (أو في أي مكان آخر ، حقا).

Answer 2

يبدو أنك بحاجة إلى فرع X يعتمد على الجذع ، وفرع y يعتمد على X.

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

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

يمكنك تكرار هذه العملية بعد إصدار كلتا الميزتين. في المرة القادمة التي تنهي فيها ميزة في X ، وتريد البناء عليها ، ما عليك سوى دمجها مرة أخرى في Y.

إذا كنت تفعل هذا ، فمن المهم أن تتذكر:

• يمكنك القيام بدمج طبيعية من الجذع إلى X ، ومن X إلى Y.
• يمكنك إعادة دمج الاندماج من X مرة أخرى إلى صندوق ، ومن Y العودة إلى X.
• بعد دمج إعادة دمج في صندوق ، تحتاج إلى ذلك منع الالتزام من الاندماج مرة أخرى إلى X.
• بعد دمج إعادة دمج في X ، تحتاج إلى منع الالتزام من الاندماج مرة أخرى في Y.
• الحفاظ على ملاحظات مفصلة حول أي ميزة في أي فرع ؛ وإلا فإن هذا يمكن أن يربك بسرعة.

Answer 3

كنت سأحصل على كل الالتزامات الجديدة إلى الجذع ما لم يكن هناك سبب لوضعها في مكان آخر. من خلال إنشاء فروع مختلفة لـ 4.1.1 و 4.1.2 ، على سبيل المثال ، من الأفضل التعامل مع مثالك من خلال القيام بدمج بين الفروع ، وكلاهما قد يتم دمجه مرة أخرى إلى الجذع. يوك! هذا هو MergeInfo Hell ، في رأيي.

إليك بعض النصائح الأساسية من كتاب التخريب:

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

Answer 4

أعتقد أن هناك عدة طرق للقيام بذلك.

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

بهذه الطريقة سيبقى الجذع مستقرًا. والرمز التجريبي هو دائما أنا الفرع.

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

Answer 5

نهج واحد هو الفرع 4.1.2 من 4.1.1 بدلاً من الجذع (وبالطبع 4.1.1 من الجذع).

يمكنك بعد ذلك دمج 4.1.1 بسهولة إلى 4.1.2 بانتظام وتظل قادرًا على القيام بالاندماج التافلي مرة أخرى في الجذع لكل فرع عندما يحين وقت الإفراج.