هل تشعر بالراحة عند دمج الكود؟

Question

قرأت هذا الصباح رأيين حول إعادة البناء.

• الرأي 1 (الصفحة غير موجودة)
• الرأي 2 (الصفحة غير موجودة)

يوصون بتقسيم التعليمات البرمجية (ومن ثم دمجها لاحقًا) إلى:

1. حافظ على نظافة صندوق السيارة.
2. السماح للمطور بالابتعاد عن التغييرات المحفوفة بالمخاطر.

في تجربتي (خاصة مع فريق StarTeam التابع لبورلاند)، يعد الدمج عملية غير تافهة.ولهذا السبب، لا أقوم بالتفرع إلا عندما يتوجب علي ذلك (أي:عندما أرغب في تجميد مرشح الإفراج).

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

أسئلتي:

• هل تشعر بالراحة عند دمج الكود؟
• هل تفرع رمز لأسباب أخرى غير تجميد مرشح الإصدار؟

Answer 1

بعض المبادئ التوجيهية الفضفاضة:

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

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

من المحتمل أن يختلف موقفك تجاه التفرع بين المشاريع الموزعة مفتوحة المصدر (مثل تلك الموجودة على Git) ومشاريع التطوير الخاصة بشركتك (ربما تعمل على SVN).بالنسبة للمشاريع الموزعة، ستحتاج إلى تشجيع التفرع لتحقيق أقصى قدر من الابتكار والتجريب، وبالنسبة للتنوع الأخير، ستحتاج إلى تحكم أكثر صرامة وإملاء سياسات تسجيل الوصول لكل سطر من التعليمات البرمجية التي تحدد متى يجب/لا يجب أن يحدث التفريع، غالبًا من أجل "الحماية". الرمز.

فيما يلي دليل للتفرع:
http://www.vance.com/steve/perforce/Branching_Strategies.html

فيما يلي دليل مختصر يتضمن بعض أفضل الممارسات عالية المستوى:
https://www.perforce.com/sites/default/files/pdf/high-level-perforce-best-practices.pdf

Answer 2

قد يكون التفرع مؤلمًا ولكن لا ينبغي أن يكون كذلك.

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

يجب أن يكون التفريع أداة سهلة وقوية يتعين علينا استخدامها لأي سبب وجيه بما يكفي للتفرع.

بعض الأسباب الوجيهة للفروع:

• العمل على ميزة معينة بالتوازي مع أشخاص آخرين (أو أثناء العمل على ميزات أخرى بدلاً من ذلك إذا كنت بمفردك في المشروع)؛
• وجود العديد من إصدارات العلامة التجارية للتطبيق؛
• وجود إصدارات متوازية من نفس التطبيق - مثل التقنيات المتزامنة التي تم تطويرها في نفس الوقت بواسطة جزء من الفريق لمعرفة ما هو الأفضل؛
• تغيير موارد التطبيق في فرع محدد للفنان/المصممين (على سبيل المثال في الألعاب) حيث يكون التطبيق "مستقرًا" بينما يتم استخدام الفروع والجذع الأخرى لإضافة الميزات وتصحيح الأخطاء؛
• [أضف هنا استخدامات مفيدة]

Answer 3

التفرع أمر تافه.الدمج ليس كذلك.ولهذا السبب، نادرًا ما نقوم بتفرع أي شيء.

Answer 4

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

Answer 5

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

Answer 6

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

لإصلاح صغير:

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

بالنسبة لميزة الفريق متعدد الأشخاص:

• يقوم الفريق بإنشاء ميزة جانبية خارج التدفق الرئيسي
• يعمل عضو الفريق الفردي على الميزة الجانبية كما هو الحال في نهج "الإصلاح الصغير" ويتم دمجه في الميزة الجانبية.
• يقوم Sidebranch Prime بدمج التغييرات المتراكمة بشكل دوري من الدفق الرئيسي إلى ميزة Sidebranch.من الأسهل التعامل مع عمليات الدمج الإضافية الصغيرة من الاتجاه السائد إلى الفرع الجانبي المميز.
• عندما تعمل الميزة، قم بالدمج النهائي من الدفق الرئيسي إلى الفرع الجانبي للميزة
• دمج الميزة الجانبية في التيار الرئيسي

لإصدار برنامج العميل:

• جعل فرع الافراج
• تقديم الإصلاحات حسب الحاجة لتحرير الفرع
• يتم نشر الإصلاحات إلى/من التدفق الرئيسي حسب الحاجة

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

هل يمكنك أن تتخيل كم يجب أن تكلف Microsoft لدعم أنظمة التشغيل XP وVista وWindows 7 بشكل متزامن؟فكر في أسرّة الاختبار، والإدارة، والوثائق، وخدمة العملاء، وأخيرًا فرق التطوير.

قاعدة ذهبية: أبداً قم بكسر التيار الرئيسي حيث يمكنك إيقاف عدد كبير من المطورين. $$$

Answer 7

مشكلة التفرع هي سبب استخدامي لنظام التحكم في الإصدار الموزع (Git في حالتي، ولكن هناك أيضًا Mercurial وBazaar) حيث يكون إنشاء فرع أمرًا تافهًا.

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

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

Answer 8

أستخدم Subversion وأعتبر التفرع أمرًا بسيطًا وسهلاً للغاية.لذلك الإجابة على السؤال 1 ..نعم.

يمكن أن يختلف سبب التفرع بشكل كبير.أنا فرع إذا شعرت أنني يجب أن.من الصعب جدًا وضع القواعد والأسباب لجميع الاحتمالات.

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

Answer 9

لقد كنت في مشروع يستخدم svn و TFS وكان التفرع بحد ذاته أمرًا بسيطًا حقًا.

استخدمنا التفرع للإصدار المرشح بالإضافة إلى الميزات طويلة الأمد أو التجريبية وللعزل عن تدخل الفريق الآخر.

اللحظة المؤلمة الوحيدة في التفرع هي الاندماج، لأن الفرع القديم أو المتطور بشكل مكثف قد يختلف كثيرًا عن الجذع وقد يتطلب جهدًا كبيرًا للاندماج مرة أخرى.

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

Answer 10

إذا كان الدمج يمثل الكثير من الألم، ففكر في الانتقال إلى VCS أفضل.سيكون ذلك ألمًا أكبر، لكن مرة واحدة فقط.

Answer 11

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

نحن أيضا نشرات فرعية.

لقد نجح التفرع والدمج بشكل جيد بالنسبة لنا.من المؤكد أن هناك أوقات يتعين علينا فيها الجلوس والتفكير في كيفية تناسب الأشياء معًا، ولكن عادةً ما يقوم svn بعمل رائع في دمج كل شيء.

Answer 12

أستخدم svn، ويستغرق رمز الفرع أقل من دقيقة.كنت أستخدم Clearcase، وكان رمز الفرع يستغرق أقل من دقيقة.لقد استخدمت أيضًا أنظمة SCM أخرى أقل حجمًا، وهي إما لا تدعم الفروع أو كانت مؤلمة جدًا عند استخدامها.يبدو فريق Starteam مثل الأخير.

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

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

Answer 13

لقد فعلت ذلك بضع مرات فقط، لذا فأنا لست مرتاحًا تمامًا لذلك.

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

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

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

Answer 14

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

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

وبالتالي فإن أي عمليات دمج مطلوبة في التكامل النهائي يمكن معالجتها تلقائيًا أيضًا.

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

Answer 15

هل تشعر بالراحة رمز المتفرعة؟

يعتمد الأمر حقًا على الأداة التي أستخدمها.مع Starteam، التفرع ليس أمرًا تافهًا بالفعل (TBH، Starteam سيء في التفرع).مع Git، يعد التفرع نشاطًا منتظمًا وسهلًا للغاية.

هل تقوم برمز الفرع لأسباب أخرى غير تجميد مرشح الإفراج؟

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

• التحكم في الإصدار لفرق Agile المتعددة بواسطة هنريك كنيبيرج
• ميزةفرع بواسطة مارتن فاولر

يعجبني حقًا النمط الموضح في المقالة الأولى ويمكن تطبيقه مع أي نظام تحكم في الإصدار (غير موزع)، بما في ذلك Starteam.

قد أفكر في النهج الثاني (في الواقع، مزيج من كلتا الاستراتيجيتين) مع (وفقط مع) أنظمة التحكم في الإصدار الموزع (DVCS) مثل Git و Mercurial...

Answer 16

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

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

• الإصلاح العاجل للإنتاج
• المشاريع ذات دورات التطوير الطويلة أو المتداخلة
• إعادة كتابة واسعة النطاق أو التطوير التجريبي

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

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

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

Answer 17

التفرع أمر تافه، كما أجاب معظمهم، ولكن الدمج، كما تقول، ليس كذلك.

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

Answer 18

يجب أن يكون التفرع والدمج واضحًا إلى حد ما.

• أشعر براحة شديدة في التفرع/الدمج.
• يتم التفرع لأسباب مختلفة، اعتمادًا على نموذج عملية التطوير لديك/

هناك بضعة نماذج فرعية مختلفة:

هنا واحد

  Trunk          
  .      
  .      
  .      
  ..         
  . ....     
  .   ...
  .      ..Release1
  .      
  .      
  ...        
  .  .... 
  .    ...Release2
  .      
  .      
  ..         
  . ...  
  .  .. 
  .    ...Release3
  .      
  .      

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

نموذج فرعي آخر هو إجراء جميع عمليات التطوير على Trunk، ويتم وضع علامة على كل إصدار، ولكن لا يتم إجراء أي تطوير إضافي على هذا الإصدار المحدد.الفروع تحدث من أجل التنمية.

  Trunk                                           
  .                                                         
  .                                                         
  .                                                         
  .Release1           
  .                       
  .                       
  .                   
  .                   
  .Release2           
  .                   
  .......                 
  .      ......       
  .           ...DevVer1
  .          .    
  .          .            
  .        ...DevVer2
  .      ....         
  .  ....             
  ...                     
  .Release3           
      .

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

خلاصة القول هي أن VCS الخاص بك يحتاج إلى دعم التفرع والدمج المرن.تمثل أنظمة VCS لكل ملف مشكلة كبيرة في IMO (RCS، Clearcase، CVS).ويقال أن SVN يمثل مشكلة هنا أيضًا، ولست متأكدًا من السبب.

يقوم Mercurial بعمل رائع هنا، كما هو الحال مع git (على ما أعتقد).