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

مقدمة

أصبح Git هو المعيار الصناعي الفعلي للتحكم في الإصدار في إنشاء البرامج. للتعرف على ماهية git وكيفية البدء، اقرأ مقالتي عنها أولاً . هل قرأتها؟ عظيم، دعونا نمضي قدما! شئنا أم أبينا، فإن الأداة التي ابتكرها لينوس توالدز لن تتقاعد. لذلك، من المنطقي التحدث عن كيفية عمل الفرق الموزعة في 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. الفكرة هي أن العمل على الوظائف الجديدة قد لا يتوقف عند اللحظات التي تحتاج فيها إلى إصلاح خلل في خادم حقيقي (كما نقول، "قيد الإنتاج": مرة أخرى، نسخة من الكلمة الإنجليزية للإنتاج). يجب إنشاء فرع الإصلاح العاجل من الفرع الرئيسي، لأنه يمثل الحالة التي تعمل في الإنتاج. بمجرد أن يصبح حل الخلل جاهزًا، يتم دمجه في الملف الرئيسي، ويتم إنشاء تسمية جديدة. تمامًا مثل إعداد فرع الإصدار، يجب على فرع الإصلاح العاجل دمج الحل الخاص به في فرع التطوير.

استراتيجية سير العمل Forking

كجزء من استراتيجية Forking Workflow، يتم تنفيذ التطوير بحيث يوجد مستودعان:

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

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

مثال سير العمل Forking

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

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

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

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

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

روابط مفيدة

• تدفق GitHub: أفضل طريقة لاستخدام Git وGitHub
• سحب الطلبات على GitHub أو كيف يمكنني إجراء تغييرات على مشروع شخص آخر
• جيثب: حول طلبات السحب
• التكامل المستمر والتسليم والنشر المتمايز
• أساسيات Git: العمل مع العلامات
• حبر: نموذج متفرّع ناجح لـ Git