شرح تدفق جيت المحسن

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

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

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

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

روعة وبؤس نموذج Git Flow الكلاسيكي

لقد كنت مدافعًا قويًا عن Git flow منذ أن اكتشفت كيف تتفوق عند تطوير منتج يتطور بزيادات كبيرة في القيمة (بمعنى آخر ، الإصدارات ).

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

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

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

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

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

ولكن حتى مع وجود مشاريع مناسبة تمامًا لنموذج Git flow الكلاسيكي ، فقد عانيت من المشكلات النموذجية التي يمكن أن تجلبها:

• يعد تدفق Git معقدًا ، حيث يحتوي على فرعين طويل الأمد وثلاثة أنواع من الفروع المؤقتة وقواعد صارمة حول كيفية تعامل الفروع مع بعضها البعض. مثل هذا التعقيد يجعل الأخطاء أكثر احتمالا ويزيد من الجهد المطلوب لإصلاحها.
• تتطلب فروع الإصدار والإصلاح العاجل "دمجًا مزدوجًا" - مرة واحدة في الرئيسي ، ثم في التطوير. في بعض الأحيان يمكنك أن تنسى القيام بالأمرين. يمكنك جعل تفرع Git flow أسهل باستخدام البرامج النصية أو المكونات الإضافية لعميل VCS GUI ، ولكن عليك إعدادها أولاً لكل جهاز لكل مطور مشارك في مشروع معين.
• في عمليات سير عمل CI / CD ، ينتهي بك الأمر عادةً بنسختين نهائيتين لإصدار - أحدهما من الالتزام الأخير لفرع الإصدار نفسه والآخر من التزام الدمج إلى الرئيسي. بالمعنى الدقيق للكلمة ، يجب عليك استخدام واحد من الرئيسي ، لكن الاثنين متطابقان عادة ، مما يخلق احتمالية حدوث ارتباك.

أدخل "Git Flow المحسن"

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

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

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

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

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

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

كانت تجربتي الإجمالية مع نهج التفريع الجديد هذا إيجابية للغاية لدرجة أنني أردت مشاركتها مع زملائي المطورين لمساعدتهم على التغلب على عيوب تدفق Git الكلاسيكي.

أوجه التشابه مع Git Flow الكلاسيكي: عزل التطوير

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

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

جميع الميزات المتراكمة في فرع التطوير حتى نقطة قطع معينة ستشكل الإصدار الجديد.

يدمج الاسكواش

لقد أوصيت بشدة باستخدام دمج الاسكواش لفروع الميزات للحفاظ على السجل جميلًا وخطيًا في معظم الأوقات. بدونها ، تبدأ الرسوم البيانية الملتزمة (من أدوات واجهة المستخدم الرسومية أو git log --graph ) في الظهور عندما يكون الفريق يتلاعب حتى بعدد قليل من فروع الميزات:

ولكن حتى إذا كنت موافقًا على العناصر المرئية في هذا السيناريو ، فهناك سبب آخر للاسحق. بدون سحق ، قم بإخبار وجهات نظر التاريخ - من بينها كلا من git log العادي (بدون - --graph ) وأيضًا GitHub - أخبر قصصًا غير متماسكة إلى حد ما حتى مع أبسط سيناريوهات الدمج:

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

الاختلافات عن Classic Git Flow: الإصدارات والإصلاحات

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

الإصدارات في تدفق Git المحسن

تختلف كل خطوة من خطوات إصدار مع تدفق Git المحسن عن عملية تدفق Git الكلاسيكية:

1. الإصدارات تستند إلى الرئيسي ، وليس على التطوير. ضع علامة على الطرف الحالي للفرع الرئيسي بشيء مفيد. لقد اعتمدت علامات بناءً على التاريخ الحالي بتنسيق ISO 8601 مسبوقًا بـ "v" —eg ، v2020-09-09 .
   • في حالة حدوث عدة إصدارات في يوم واحد - على سبيل المثال ، الإصلاحات العاجلة - يمكن أن يحتوي التنسيق على رقم تسلسلي أو حرف مثبت عليه حسب الحاجة.
   • اعلم أن العلامات لا تتوافق بشكل عام مع تواريخ الإصدار. إنهم فقط يجبرون Git على الاحتفاظ بمرجع لكيفية نظر الفرع الرئيسي في الوقت الذي بدأت فيه عملية الإصدار التالية.
2. ادفع العلامة باستخدام git push origin <the new tag name> .
3. بعد ذلك ، هناك القليل من المفاجأة: حذف الفرع الرئيسي المحلي الخاص بك . لا تقلق ، لأننا سنستعيدها قريبًا.
   • لا تزال جميع الالتزامات الرئيسية آمنة - لقد قمنا بحمايتها من جمع البيانات المهملة عن طريق وضع علامات على main في الخطوة السابقة. كل واحد من هذه الالتزامات - حتى الإصلاحات العاجلة ، كما سنغطي بعد قليل - هو أيضًا جزء من التطوير.
   • فقط تأكد من أن شخصًا واحدًا فقط في الفريق يقوم بذلك لأي إصدار معين ؛ هذا هو ما يسمى بدور "مدير الإصدار". عادةً ما يكون مدير التحرير هو أكثر أعضاء الفريق خبرة و / أو أعلى رتبة ، ولكن سيكون من الحكمة تجنب أي عضو معين في الفريق يتولى هذا الدور بشكل دائم. من المنطقي نشر المعرفة بين الفريق لزيادة عامل الحافلة سيئ السمعة.
4. أنشئ فرعًا رئيسيًا محليًا جديدًا عند تقديم الإكراميات لفرع التطوير الخاص بك .
5. ادفع هذا الهيكل الجديد باستخدام git push --force ، نظرًا لأن الريبو البعيد لن يقبل مثل هذا "التغيير الجذري" بهذه السهولة. مرة أخرى ، هذا ليس غير آمن كما قد يبدو في هذا السياق للأسباب التالية:
   • نحن فقط ننقل مؤشر الفرع الرئيسي من التزام إلى آخر.
   • يقوم عضو واحد فقط من الفريق بإجراء هذا التغيير في كل مرة.
   • تحدث أعمال التطوير اليومية في فرع التطوير ، لذلك لن تعطل عمل أي شخص عن طريق الانتقال الرئيسي بهذه الطريقة.
6. لديك إصدارك الجديد! انشرها في بيئة التدريج واختبرها . (سنناقش أنماط CI / CD الملائمة أدناه.) أي إصلاحات تذهب مباشرة إلى الفرع الرئيسي ، وسوف تبدأ في التباعد عن فرع التطوير بسبب ذلك.
   • في نفس الوقت ، يمكنك البدء في العمل على إصدار جديد في فرع التطوير ، وهي نفس الميزة التي شوهدت في تدفق Git الكلاسيكي.
   • في الحدث المؤسف الذي يتطلب إصلاحًا عاجلاً لما هو قيد الإنتاج حاليًا (وليس الإصدار القادم في التدريج) في هذه المرحلة ، هناك المزيد من التفاصيل حول هذا السيناريو في "التعامل مع الإصلاحات العاجلة أثناء الإصدار النشط ..." أدناه.
7. عندما يعتبر إصدارك الجديد مستقرًا بدرجة كافية ، انشر الإصدار النهائي في بيئة الإنتاج وقم بإجراء دمج واحد للاسكواش للتطوير لالتقاط جميع الإصلاحات.

الإصلاحات في Git Flow المحسن

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

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

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

في حالة عدم القيام بذلك - عليك تقديم إصلاح سريع ، ولا يمكنك الانتظار حتى يصبح الإصدار الجديد جاهزًا - ثم استعد لإجراء Git المعقد إلى حد ما:

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

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

إعداد CI / CD أعلى تدفق Git المحسن

لا يتطلب كل مشروع بيئة تطوير مخصصة. قد يكون من السهل إعداد بيئة تطوير محلية متطورة على كل جهاز مطور.

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

لقد وجدت أن بعض أنماط CI / CD مفيدة بشكل خاص عند دمجها مع تدفق Git المحسن:

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

هذه الأنماط بسيطة نسبيًا ، لكنها توفر آلية قوية لدعم عمليات التطوير اليومية.

نموذج Git Flow المحسن: التحسينات والقيود المحتملة

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

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

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

شكر خاص لزميل Toptal أنطوان فام لدوره الرئيسي في تطوير الفكرة الكامنة وراء تدفق Git المحسن.

مزيد من القراءة على مدونة Toptal Engineering:

• التنمية المستندة إلى Trunk مقابل Git Flow
• Git Workflow for Pros: دليل Git الجيد

بصفتك شريكًا ذهبيًا لـ Microsoft ، فإن Toptal هي شبكة النخبة الخاصة بك من خبراء Microsoft. كوِّن فرقًا عالية الأداء مع الخبراء الذين تحتاجهم - في أي مكان وفي أي وقت بالضبط تحتاجهم!