العمل الجماعي دون ارتباك: فهم استراتيجيات التفرع في جيت

مقدمة

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

هل استراتيجيات التفرع ضرورية؟

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

• العمل في أي فرع
• الاندماج في فروع أخرى تعسفية
• حذف بعض الفروع
• خلق جديدة
• وبالتالي سيتصرف كل عضو في الفريق بتدفق غير مُدار.

ولهذا السبب لدينا ثلاث استراتيجيات يجب مراعاتها أدناه. دعنا نذهب!

تدفق جيثب

من الغريب أن استراتيجية التفرع هذه مفضلة على GitHub :) وهي تأتي مع مجموعة من القواعد :

1. يجب عدم كسر الكود الموجود في الفرع الرئيسي. وينبغي أن تكون جاهزة للنشر في أي وقت. أي أنه لا يجب عليك وضع تعليمات برمجية هناك تمنعك من بناء المشروع ونشره على الخادم.
2. عندما تخطط للعمل على وظيفة جديدة، فإنك تحتاج إلى إنشاء فرع ميزات جديد استنادًا إلى الفرع الرئيسي وإعطائه اسمًا ذا معنى. قم بتنفيذ التعليمات البرمجية الخاصة بك محليًا وادفع تغييراتك بانتظام إلى نفس الفرع في المستودع البعيد.
3. افتح طلب سحب (يمكنك القراءة عن طلبات السحب هنا ) عندما تعتقد أن العمل جاهز ويمكن دمجه في الفرع الرئيسي (أو إذا لم تكن متأكدًا، ولكنك ترغب في الحصول على تعليقات حول العمل المنجز).
4. بعد الموافقة على الميزة الجديدة في طلب السحب، يمكن دمجها في الفرع الرئيسي.
5. عندما يتم دمج التغييرات في الفرع الرئيسي، يجب نشرها على الخادم على الفور.

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

جيت فلو

الإستراتيجية السابقة (GitHub Flow) ليست معقدة للغاية في جوهرها. هناك نوعان من الفروع: الفروع الرئيسية والفروع المميزة. لكن GitFlow أكثر جدية. على الأقل، يجب أن توضح الصورة أعلاه ذلك :) إذًا كيف تعمل هذه الإستراتيجية؟ بشكل عام، يتكون GitFlow من فرعين ثابتين وعدة أنواع من الفروع المؤقتة. في سياق GitHub Flow، يكون الفرع الرئيسي ثابتًا والفرع الآخر مؤقت. الفروع المستمرة

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

يتم التطوير باستخدام ثلاثة فروع مؤقتة مساعدة :

1. فروع الميزة - لتطوير وظائف جديدة.
2. فروع الإصدار - للتحضير لإصدار نسخة جديدة من المشروع.
3. فروع الإصلاح العاجل – لإصلاح الأخطاء التي يعثر عليها المستخدمون الحقيقيون على خادم حقيقي بسرعة.

فروع مميزة

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

الافراج عن الفروع

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

فروع الإصلاح العاجل

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

شوكة سير العمل

في سير عمل التفرع، يتضمن التطوير مستودعين:

1. المستودع الأصلي، الذي سيتم دمج جميع التغييرات فيه.
2. مستودع شوكة. هذه نسخة من المستودع الأصلي، يملكها مطور آخر يريد إجراء تغييرات على المستودع الأصلي.

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

مثال على سير العمل شوكة

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

أي استراتيجية تختار

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

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

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