منظمة المستودع

Question

عندما بدأت لأول مرة في استخدام أنظمة التحكم في المراجعة مثل CVS و SVN, ، لم أفهم حقًا مفاهيم "الجذع" والتفرع والدمج ووضع العلامات.لقد بدأت الآن في فهم هذه المفاهيم، وأدرك حقًا الأهمية والقوة الكامنة وراءها.

لذلك، بدأت في القيام بذلك بشكل صحيح.أو هكذا أظن...وهذا ما أفهمه حتى الآن:يجب أن يكون الإصدار الأخير/الإصدار الثابت من التعليمات البرمجية الخاصة بك موجودًا في /trunk/ بينما توجد إصدارات بيتا أو إصدارات الحافة النازفة داخل الدليل /branches/ كأدلة مختلفة لكل إصدار تجريبي، ثم يتم دمجها في الصندوق عند الإصدار.

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

Answer 1

راجع هذين السؤالين على SO لمزيد من المعلومات:

• ماذا يعني الفرع والعلامة والجذع حقًا؟
• سؤال التخريب

Answer 2

ما أفعله وأراه عادة كمعيار هو:

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

شيء مثل:

/trunk (هنا تقوم بتطوير الإصدار 2.0) /branches/rb-1.0 (هذا هو فرع الإصدار لـ 1.0) /branches/rb-1.5

عندما تجد خطأ في الإصدار 1.5، تقوم بإصلاحه في فرع RB ثم تقوم بدمجه في صندوق السيارة.

أوصي أيضا هذا الكتاب.

Answer 3

لدى إريك سلسلة ممتازة من المقالات حول استخدام التحكم بالمصادر وأفضل الممارسات التنظيمية.ويتناول الفصل السابع الفروع (ونعم، توصي بالدلائل /trunk/ و/branches/ التي تقترحها).

Answer 4

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

تحدث التطورات في الفروع المتفرعة من MAIN (عادة - في بعض الأحيان قد ترغب في التفرع من فرع مطور موجود).قم بالتكامل من MAIN إلى فروع التطوير الخاصة بك بقدر ما تستطيع، لمنع تباين الأمور أكثر من اللازم - أو يمكنك ببساطة وضع ميزانية لفترة تكامل أكبر لاحقًا.قم بدمج ميزة الركل الجديدة الخاصة بك في MAIN فقط عندما تكون متأكدًا من أنها ستخرج في إصدار قادم.

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

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

على سبيل المثالسيكون لدي شيء مثل هذا:

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...

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

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

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

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

آمل أن يكون ذلك مفيدًا، وألا يكون واضحًا أكثر من اللازم.