SVN: الجذع والفروع والعلامات

Question

إنه شهر أحاول معرفة أفضل حل لمشكلتي وهذا هو الأفضل. أود أن أعرف ما إذا كنت توافق على ذلك.

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

نحن نستخدم لتطوير على الجذع وظائف جديدة. كلما نشرنا شيئًا مباشرًا ، فإننا نضع علامة على إصدار Trunk باسم الإصدار. على سبيل المثال ، لنفترض أن إصدار الجذع الأول تم وضع علامة عليه 1.0.0. عندما نطور تنفيذ Furhter (أي أننا نعمل على 1.1.0) سلسلة من الأخطاء تخرج من إصدار الإنتاج. ما نفكر في القيام به هو علامة الخروج 1.0.0 وتصحيح الأخطاء نحو الإصدار 1.0.1.

الآن ما نود تحقيقه هو وضع علامة على كل نسخة مراجعة. بمعنى آخر ، نود أن نكون قادرين على الحصول على نسخة عمل مثالية من 1.0.0 ، 1.0.1 ، 1.0.2 ...

الآن هذا هو الحل الخاص بي ، أود أن أعرف ما إذا كنت توافق على ذلك.

1. أنا الخروج من الإصدار الموسومة 1.0.0 إلى المجلد المحلي /العلامات
2. أفرع هذا الإصدار إلى /branches/1.0.1 مجلد المستودع
3. أتحقق من فرعتي الجديدة إلى المجلد المحلي /الفروع
4. أقوم بتصحيح الأخطاء في الفرع 1.0.1
5. عندما ، بعد ارتكاب x ، كل شيء على ما يرام ، أقوم بتمييز هذا الإصدار الجديد إلى /tags/1.0.1

وما إلى ذلك لكل خطأ جديد / إصدار جديد. لقد جربتها ، وإذا قمت بالخروج من مجلد /TAGS ، يمكنني رؤية جميع الإصدارات ، العمل المثالي.

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

ما رأيك؟ شكرا ، ماركو

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

يبدو أمرا جيدا لي.

اعتمادًا على Ammount of Fixes التي تم إصدارها ، لن أزعجني إبداع الفروع لكل إصدار بسيط. إنشاء تلك ، التواصل مع الناس ما يجب الخروج/أين يمكن التحقق ، الدمج وما إلى ذلك شطف وتكرار.

إن وجود فرع لكل إصدار رئيسي واستخدامه كـ "صيانة"-يعمل بشكل جيد بالنسبة لنا.

فيما يلي وصف للعملية في حال كنت مهتمًا:استراتيجيات نشر SVN لمجموعات متعددة من المطورين (وليس المشتركين) الذين يعملون على مكونات مختلفة من نفس المشروع

حدد سياسات الفروع وإنشاء فرع جديد فقط إذا كان عليك القيام بشيء لا يتناسب مع السياسات الحالية. يساعد على الحد من التفرع.