كيف أعمل في نفس الوقت على الإصدار 1.1 والإصدار 2.0؟
https://stackoverflow.com/questions/44566
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
الوضع:لقد انتهينا من النسخة التجريبية وتم طرح الإصدار 1.0 في العديد من مواقع العملاء.الفريق "أ" مشغول بالفعل بالعمل على الإصدار 1.1 الذي سيحتوي على إصلاحات أخطاء إضافية وتعديلات في قابلية الاستخدام، بينما يعمل فريق آخر على الإصدار 2.0 مع تغييرات واسعة النطاق، حيث ربما تم إعادة تصميم جوهر المنتج بالكامل.الآن، معظم التغييرات التي تم إجراؤها على الإصدار 1.1 يجب أن تشق طريقها إلى الإصدار 2.0 في مرحلة ما، وقد تحتاج في الواقع إلى جدولة بعض إصلاحات الأخطاء التي تم إجراؤها في الفرع 2.0 لإصدار سابق.المشكلة هي أنه نظرًا لوجود اختلافات جوهرية في الإصدار 2.0، فلا يمكن دمج أي تغييرات من الإصدار 1.1 بدون تحويل يدوي، ولا العكس.
سؤالي:ما هي أفضل ممارسات التحكم في المراجعة لتقليل تعارضات الدمج والعمل المكرر في هذا النوع من المواقف؟كيف يمكنني التأكد من أن فريقي ينفق أقل قدر ممكن من الوقت والجهد على مشكلات التحكم في المراجعة، مع الاستمرار في توفير تصحيحات منتظمة للعملاء؟
المحلول
إحدى الطرق الجيدة هي إصلاح كل خطأ في الفرع المستقر ودمج الفرع المستقر في فرع التطوير.هذا ال خطوط الصيانة/التطوير الموازية النمط، والمفتاح هو الدمج مبكرًا وفي كثير من الأحيان.الدمج بشكل غير متكرر ومتأخر يعني أنه لا يمكن التعرف على فرع التطوير مقارنة بالفرع المستقر، أو لا يمكن تكرار الخطأ بنفس الطريقة.
التخريب يتضمن تتبع الدمج منذ الإصدار 1.5 حتى تتأكد من عدم دمج مجموعة التغييرات نفسها مرتين، مما يتسبب في حدوث تعارضات سخيفة.توجد أنظمة أخرى (على سبيل المثال. شخص سخيف, زئبقي, أكيوريف, بحكم الأمر) هذا يتيح لك إجراء استفسارات من النوع "ما هي التغييرات في الفرع A لم يتم دمجها في الفرع B؟" والكرز-اختر الإصلاحات التي تحتاجها عبر فرع DEV.
نصائح أخرى
المقالة هنا (يوميًا مع Subversion) يذكر أن إحدى الطرق هي تحديث الإصدار 2 باستمرار ببيانات من الإصدار 1.1.في المقال، يقول الرجل أن تفعل ذلك كل يوم.
الجزء الذي تريد قراءته يحمل عنوان "أيها النادل، هناك خلل في صندوق السيارة!".لقد وصل إلى منتصف المقال تقريبًا.
ربما سأعتمد على نظام تتبع المشكلات لهذا الغرض، وأتأكد من وضع علامة على كل تغيير يجب إدخاله في رمز صندوق الاتصال.يمكنك بعد ذلك التأكد من أن تعليقات تسجيل الوصول لكل تغيير تشير إلى المشكلة ذات الصلة، وأن تكون واضحة في التعبير عن الغرض من تغيير التعليمات البرمجية بحيث يمكن فهمها بسهولة عند محاولة إعادة التنفيذ في صندوق الأمتعة.
إلى حد كبير ما قاله الجميع، لكنني اعتقدت أنني سأضيف تجربتي في التعامل مع التطوير في فروع متعددة باستخدام SVN
مع منتجنا الرئيسي، نحتاج إلى التطوير في وقت واحد في أكثر من إصدارين في نفس الوقت.
لقد استخدمت في الأصل الصندوق الرئيسي كإصدار "التطوير الرئيسي"، مع العلامات المستخدمة لكل إصدار فعلي.تم استخدام الفروع لجهود التطوير الكبيرة لمجموعة ميزات جديدة.ثم لاحقًا، عندما بدأنا العمل على الإصدارات الثانية والثالثة والرابعة في وقت واحد، بدأت باستخدام فرع لكل مراجعة.
نظرًا لأنني أحتفظ بالمستودع وأتعامل أيضًا مع دفع تصميمات ضمان الجودة، فأنا أتأكد من إجراء "مجموعات" كل صباح - والتي تتكون من دمج التغييرات أعلى الشجرة بدءًا من الفرع الأقل نشاطًا حاليًا.لذلك انتهى بي الأمر إلى دمج التغييرات من 1.1 إلى 1.2، والتي تم دمجها في 1.3 مع أي تغييرات أخرى من 1.2 منذ آخر عملية دمج، وما إلى ذلك.
عندما ألتزم، أتأكد دائمًا من التعليق على الالتزام بشيء مثل
دمج 1.1 مراجعة 5656-5690
قد يكون الأمر مؤلمًا بعض الشيء، لكنه يعمل :)
قم بالدمج مبكرًا، والدمج بشكل متكرر، وتأكد من أن ضمان الجودة على الخط الرئيسي يعرف العيوب التي تم إصلاحها في كل تصحيح لإصدارات الصيانة ويتراجع/يتحقق منها.
من السهل حقًا ترك شيء ما يفلت من أيدينا و"إصلاح" خطأ ما في إصدار لاحق، واسمحوا لي أن أخبركم أن العملاء لا يهتمون بمدى التعقيد الذي يمكن أن تصل إليه إدارة الفروع المتعددة - فهذه هي وظيفتك.
تأكد من أنك تستخدم نظام تحكم بالمصدر يدعم التفرع والدمج (لدي خبرة مع Perforce وSVN، وعلى الرغم من أن Perforce أفضل، إلا أن SVN مجاني).
وأعتقد أيضًا أن وجود شخص واحد مسؤول عن تنفيذ عمليات الدمج بطريقة متسقة يساعد في ضمان حدوثها بانتظام.لقد كنت أنا عمومًا أو أحد كبار الأشخاص في فريقنا.
الطريقة التي نتعامل بها مع هذا الأمر في عملي هي الحفاظ على فرع صندوق الأمتعة باعتباره الكود الأكثر تطورًا (أي 2.0 في هذه الحالة).يمكنك إنشاء فرع لرمز 1.x وإجراء كافة الإصلاحات هناك.يجب دمج أي تغييرات على 1.x (يدويًا، إذا لزم الأمر) في فرع الجذع (2.0).
أصر بعد ذلك على أن يقوم مطورو الإصدار 1.x بتدوين رقم المراجعة للالتزام 1.x ورقم المراجعة للدمج 2.0 في تذكرة هذا الخطأ.بهذه الطريقة، سيكون من الأسهل ملاحظة ما إذا كان أي شخص قد نسي دمج تغييراته، وحقيقة أنه يتعين عليه تتبعها ستساعده على التذكر.
يتم التقاط نقطة رئيسية واحدة في هذه الصورة من دكتور البناء:دمج اتجاه واحد فقط.
للإجابة على هذا السؤال المحدد، قام العديد من المطورين بالتبديل من Subversion إلى Git.الخروج github.com.
