سؤال

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

سؤالي هو ما هي أفضل طريقة للتعامل مع مثل هذه المواقف.ربما حذف العلامة وإعادة إنشائها من مراجعة رأس الفرع؟

هل كانت مفيدة؟

المحلول

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

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

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

نصائح أخرى

أفضل الممارسات هي عدم الحذف tags في الواقع، ليس المقصود من العلامات أن يتم لمسها، فهي مجرد تسميات، في حين أنه من الصحيح أن كل شيء عبارة عن مجلد في أي مستودع svn، فإن الممارسة عادة هي العمل عليها trunk, ، تحديث branches في حالة وجود البق، وترك tags كعلامات لسجل العمل السابق كمرجع، يمكن أيضًا استخدام الفروع للعمل المنفصل، وأفضل ممارسة هي العمل بنمط جذع واحد رئيسي واحد وتجنب الفروع قدر الإمكان (تكامل التسليم المستمر) ولكن في حالتك سأفعل علامة الفرع وتحديثها ثم الدمج مرة أخرى في صندوق السيارة. tags من المفترض أن تبقى.ما سأفعله هو نسخ tag الى branch باسم الفرع وقم بالتحديث هناك.و بعد ذلك اردت merge إعادته إلى trunkعمليات الدمج التلقائي هناك أداة مساعدة رائعة لـ svn تسمى فائدة الدمج التلقائي

اعتمدت جوجل وفيسبوك التطوير القائم على الجذع.التطوير في المواد المذكورة أعلاه، تحدث موظفو Google هؤلاء عن العمل على HEAD، وأن عمليات تسجيل الدخول تتم لـ HEAD في جميع الأوقات.يقول أشيش صندوق الأمتعة عدة مرات قرب النهاية في قسم الأسئلة والأجوبة، وقد ذكر تجنب التفرع من أجل التطوير المستمر (لا علاقة له بالإصدارات في حد ذاتها).لذا، أصبح الأمر رسميًا أن التطوير القائم على صندوق النقل (TBD) هو ما تفعله Google، ويفعلون ذلك على نطاق واسع!(http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/)

العلامات في SVN (تقليديا) RO Subtree.إذا كنت قد تغيرت بعد إنشاء رمز العلامة، فعليك إنشاء علامة جديدة من التعليمات البرمجية التي تم تغييرها

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top