كيفية اختيار نموذج Git Workflow & المتفرّع المناسب لفريقك

جدول المحتويات:

كيفية اختيار نموذج Git Workflow & المتفرّع المناسب لفريقك
كيفية اختيار نموذج Git Workflow & المتفرّع المناسب لفريقك
Anonim

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

منظمة مستودعات أفضل ، تطوير أسرع

مع ظهور خطوط أنابيب الأتمتة سهلة الاستخدام مثل Jenkins ، بدأت العديد من الشركات في القيام بالتكامل والتسليم المستمر (CI / CD) ، مع دمج التغييرات من المطورين في الريبو في كثير من الأحيان ، وعادة ما يتم شحن منتج على جدول أسبوعي وليس شهريًا.

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

master، فستواجه مشكلات مع تعارضات الدمج المتكررة.

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

ميزة وتطوير الفروع

هناك مشكلتان كبيرتان تعمل فروع Git للمساعدة في حل الحفاظ على مزامنة فرقك الداخلية ، والحفاظ على إصدارك العام.

عندما تبدأ فرعًا في Git ، سيتم إجراء التزامات جديدة على هذا الفرع ، بدلاً من

masterيمكن أن يكون هذا مفيدًا لتتبع التقدم الفردي في ميزة معينة أو إصلاح الخلل؛ على سبيل المثال ، يمكن لكل فرع تنفيذ ميزة محددة في مشكلة في خدمة كانبان ، مثل Jira أو Trello أو Github Issues & Projects.

صورة
صورة

عادة ، يتم دمج الفروع من خلال طلبات السحب ، وهي ميزة لحلول Git المستضافة مثل Github ، حيث يطلب الفريق أن

master

يسحب من

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

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

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

صورة
صورة

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

التنمية القائمة على الجذع

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

التطوير المستند إلى Trunk قريب من البرمجة الجماعية التي يجب أن تكون تكرارًا سريعًا في الفرع

master

، لدفع منتج قابل للتطبيق بسرعة. يصنع الفريق أفرعًا مميزة قصيرة العمر ، وعادة لا تدوم أكثر من بضعة أيام ، وغالبًا ما يلتزم مباشرةً بـ

master

يطلق عليه "الجذع" لأن تأثير ذلك يجعل الفرع

masterالفرع الأكثر نشاطًا وفائدة في الريبو بأكمله ، مثل جذع شجرة سميك يدعم كل شيء آخر. تتم جميع عمليات التطوير بالتركيز على هذا الفرع ، وهو سريع وسهل الالتفاف حوله ، مما يجعل تجربة المطور جيدة.

صورة
صورة

بمجرد أن يصبح جاهزًا للإصدار ، يتم إنشاء فرع جديد بإصدار جديد لكل إصدار. هذا يبقي الإصدارات منفصلة عن

master، ويساعد أيضًا في إضافة تصحيحات أو انتقاء الكرز إلى إصدارات LTS.

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

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

تدفق البوابة التقليدية

"Git Flow" هو سير عمل نجح في العديد من الفرق. إنه أكثر تعقيدًا من سير العمل البسيط للتطوير المستند إلى trunk ، ولكنه يوفر الكثير من الفوائد للمشاريع مفتوحة المصدر ، والمشاريع الكبيرة مع العديد من أعضاء الفريق.

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

master.

مع Git Flow ، الوصول أكثر تقييدًا ، لأن معظم المطورين لن يحصلوا على إذن للاندماج مباشرة في

Develop

، وبالطبع ليس في

master، وسيتعين علينا إنشاء الفروع كطريقة أساسية لإجراء التغييرات.

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

صورة
صورة

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

masterوإعطاء علامة ، يمكن من خلالها إنشاء إصدار.

الاختلاف الرئيسي هو أن هذا

master

يتم الحفاظ عليه جنبًا إلى جنب مع

Develop

تم دمج الالتزامات من فروع الإصدار مرة أخرى فيتطوير

، وكذلك أي إصلاحات عاجلة. هذا يجعل

Develop

دائمًا الفرع الأحدث ، حيث يتم إصدار الإصدارات عندما تكون مستقرة.

يؤدي وجود هذا الفصل إلى تسهيل إدارة إصلاحات الأخطاء الصغيرة التي يجب إصدارها قبل دمج

masterمع أحدث الإصدارات. يعمل فرع التحرير بشكل مشابه تمامًا لفرع الميزة ، حيث تتمثل الميزة في حقيقة أنه تم وضع علامة عليه كإصدار مستقر.

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

اختر ما يناسبك

صورة
صورة

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

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

موضوع شعبي