استخدام التخريب دون جذع

Question

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

هل أي شخص آخر هناك يفعل هذا؟

إذا كان الأمر كذلك، هل لاحظت أي إيجابيات / سلبيات؟

حتى لو لم يفعل فريقك هذا، هل لدى أي شخص أي أفكار حول هذا التصميم؟

Answer 1

أنت تتحدث عن نموذج الترويجية - ورقة Perforce تسلط الضوء على المشكلات المتعلقة به - التواصل الأدوار المتغيرة لخطوط التعليمات البرمجية والعمل المتحرك بين الفروع.

توسيع على وجهات نظري للمشاكل المدرجة:

1) تغيير سياسة خطوط التعليمات البرمجية:

يحتوي كل خط رمز سياسة، سواء كان مكتوبا وصيدا إضافيا أو ضمنيا تماما في رأس المطور. يحدد ذلك على سبيل المثال:

• من يسمح للالتزام بخط الكود
• ما مقدار الاختبار المطلوب (مثل إجراء اختبارات الوحدة يجب أن تمر، اختبارات الانحدار، اختبار النظام الكامل)
• كم من الناس يتعين على تغييرات استعراض التعليمات البرمجية
• أي نوع من التغييرات المسموح بها

مع نهج الجذع، لا تزال السياسات ثابتة، لذلك من الأسهل الكتابة، مما يجعلها أسهل في التواصل (أكثر أهمية في فريق أكبر).

على سبيل المثال جذع:

• يمكن لأي مطور الالتزام
• أي تغيير
• اختبارات الوحدة يجب أن تمر
• استعراض الكود بعد الالتزام

فرع النسخة:

• مطور صيانة فقط
• علة فقط إصلاح
• اختبار الوحدة + اختبارات الانحدار
• استعراض الكود بواسطة 2 مطور آخر قبل الالتزام

فرع العلامة:

• لا ارتكب بعد الخلق

فرع المطور الخاص:

• فقط الشيكات المطور في
• أي تغيير
• اختبار مطلوب فقط قبل دمج الجذع
• مراجعة التعليمات البرمجية قبل دمج الجذع

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

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

إذا نظرت إلى تطوير نواة Linux Linux، فيمكنك أن ترى الضغط بين النموذج الترويجي ونموذج الجذع: شجرة Linus هي ترويجية - يمر عبر دورات بين نافذة الدمج، وفترة RC / الاستقرار. لكن Linux - Next و -mm قد انتشرت لإعطاء خط جذع آخر.

SCM / VCs الموزعة مختلف إلى حد ما على أي حال، لا يجب توزيع السياسات على جميع المطورين لأن كل طور لديه أشجاره الخاصة، وتسحب التغييرات عندما يريد.

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

2) نقل العمل:

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

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

Answer 2

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

أ) فريق صغير (من 5 إلى 7 مطورين) جميعا داخل صراخ المسافة من بعضهم البعض. التواصل غير قضية عندما نحتاج إلى إجراء فرع

و

ب) رمز كود حيث يوجد بالفعل 2 فروع رئيسية فقط - فرع إنتاج و "الشيء التالي في التنمية". ربما مرة واحدة في القمر الأزرق لدينا 3.

أعتقد أن وجهة نظري هي - إنها شيء حي. ليقول "النموذج الترويجي له مشاكل" يشبه قول "لا تستخدم أبدا أو / م". ذلك يعتمد على بيئتك.

Answer 3

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

Answer 4

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

Answer 5

نحن نفعل - نوع من. نحن لا نستخدم صندوق جذع، ولكن إنشاء فرع جديد لكل إصدار من مشاريعنا. هذا الفرع "الموسومة" هو ثم الجذع لكل إصدار، ونحن نعلم bugfixes عن طريق دمج التغييرات على الإصدارات القديمة.

إنه يعمل بشكل جيد بالنسبة لنا، لكن لدينا الكثير من المشارفات الفرعية في مشروعنا.

Answer 6

IME، في بعض البيئات، فإن الجذع هو مكان جيد لإصلاحات المبادلة والتغييرات من / من. وهذا هو، الجميع يدمج إصلاحاتهم ل الجذع، والجميع يدمج إصلاحات الآخرين من الجذع. وجدنا أن مفيدة للغاية في بيئة تم تشاركها الكثير من الكود بين العديد من المشاريع المستقلة وأين ساهمت كل هذه المشاريع في القانون المشترك.

قد تختلف بيئة، رغم ذلك.