تعتبر أداة git أحد أشهر الأدوات في المشاريع البرمجية، إلا أن البعض يتوقف في تعلمها عند معرفة الأساسيات: (push - pull -commit - branch..etc) دون معرفة حقيقية بطريقة استخدامها للعمل كفريق بشكل فعال،
كيف تستخدم git في العمل مع فريق؟ و ما هو ال branching strategy؟
ثريد 👇🏻
كيف تستخدم git في العمل مع فريق؟ و ما هو ال branching strategy؟
ثريد 👇🏻
لعبت الظروف التاريخية التي واجهتها طرق بناء المنتجات التقنية دورا هاما في تحديد شكلها اليوم، و في الماضي كان لابد من ظهور تنظيمات معينة في طريقة استخدام git لتسهيل العمل كفريق (بتجميع) الأكواد و ترتيب طريقة (إيصال) الإصدارات الجديدة من المنتج للعميل النهائي، و لذلك..
و لذلك صدرت مجموعة من الأفكار تشرح عملية الترتيب بطرق مختلفة، لكن أبرز الأفكار طرحت في عام 2010 بمقالة (تاريخية) لمبرمج يدعى Vincent Driessen و الذي اقترح تنظيما لعملية استخدام الفروع و دمجها لتجميع الأكواد و إيصال الميزات و هو ما يعرف اليوم باسم: gitflow branching strategy
المقالة نشرها Driessen في موقعه الشخصي و أعتقد شخصيا أن الملايين قد زاروا موقعه لقراءة هذه المقالة تحديدا و فهم نموذج gitflow الذي اقترحه. طيب كيف يعمل؟ و كيف يمكن أن أطبقه؟
أساس استراتيجية gitflow هو أن يكون لديك فرعين أساسيين: dev و master بحيث يمثلان الفرعين الأساسيين و التي تبقى للأبد في المشروع و كل التغييرات الموجودة في أحدهما ستكون موجودة في الآخر في وقت ما ليكون ال dev و ال master متزامنين دائما
الغرض من ال dev هو أن يمثل انعكاسا للبيئة التجريبية للكود بحيث يتم نشر الميزات الجديدة فيه و تجريبها في بيئة (موقع أو تطبيق) خاص بالفريق للتأكد من عمل الميزات بشكل صحيح، و من ثم يتم دمجها إلى ال (master)، حيث تنشر إلى البيئة الحقيقة للمستخدم النهائي
كيف يتم بناء الميزات الجديدة؟ كل ميزة جديدة يجب فيها إنشاء فرع جديد من ال dev و يكون خاصا بالمبرمج الذي سيعمل على هذه الميزة، بحيث يتم عزل تغييراته و تجاربه عن الفرع المشترك مع المطورين الآخرين (dev) و يقوم بعمل تغييراته حتى يكمل الميزة تماما.
بعد إكمال الميزة لابد أن يتم نقلها للبيئة التجريبة ليقوم فريق الاختبار بتجربتها و التأكد من أنها تعمل في البيئة التجريبة، و بالتالي فإن كل مطور يقوم بدمج الفرع الخاص به في ال dev مرة أخرى بعد أن أكمل عمله على الميزة المطلوبة منه، ثم يبدأ بعمل فرع جديد من ال dev لميزة أخرى و هكذا
لاحظ كيف أن كل مبرمج قام بعمله في معزل عن البقية و من ثم قام بدمج عمله في الفرع المشترك (dev) و بالتالي تم تجميع (integration) أعمال المبرمجين معا في ال dev و أصبحت البيئة التجريبية تحتوي على جميع أعمالهم مجتمعة.
و بعد فترة من الزمن، عندما تتراكم مجموعة من الميزات الجديدة الجاهزة للنشر للعميل النهائي حينها سنكون بحاجة إلى إيصال مجموعة الميزات إلى ال master. كيف؟ عن طريق دمج ال dev بال master، و لكن عملية الدمج هذه لا تتم بشكل مباشر، و إنما..
و إنما تتم بإنشاء فرع جديد من الdev (من مدير الفرق) هذا الفرع مخصص للإصدار الجديد الذي سيتم نشره للمستخدمين (release) و بالتالي يتم تستميته برقم هذا الإصدار، و بعد إجراء مجموعة من الاختبارات على الميزات مجتمعة و إضافة التعديلات الأخيرة قبل النشر، يتم دمج الفرع هذا في ال master
لكن تذكر أن ال dev و ال master يجب أن يبقيا متزامنين، و هناك تعديلات جرت على ال release و ليست موجودة بعد في ال dev، لذلك لابد من دمج ال release في ال dev كذلك لإعادة التزامن بين ال dev و ال master، و بعد دمجه يمكن أن يتم حذفه حيث أن كل التغييرات أصبحت موجودة و لا خوف من فقدانها
و لأنه لا وجود لا شيء عديم الأخطاء ١٠٠٪ في بناء البرمجيات، فمن الوارد أن يتم اكتشاف خطأ في منتج المستخدم النهائي (production / master) بالرغم من كل الاختبارات التي تمت، ولا بد من إصلاح الخطأ في أسرع وقت ممكن، فما العمل بهذه الحالة؟
هذه الحالة الوحيدة التي يتم فيها إنشاء فرع من ال master و يتم فيه إصلاح الخطأ بشكل مباشر و من ثم يتم دمج الفرع في ال master مرة أخرى لضمان سرعة الإصلاح، هل هذا يكفي؟ لا، يجب دمجه كذلك في ال dev لإعادة التزامن و من ثم يمكن حذف فرع ال hotfix
dev - master - feature - release - hotfix
هذه أنواع الفروع المختلفة المستخدمة في ال gitflow و التي مثلت نموذجا كانت و ما زالت العديد من شركات البرمجيات تعتمد عليه في إدارة برامجها لأكثر من ١٠ سنوات.
هذه أنواع الفروع المختلفة المستخدمة في ال gitflow و التي مثلت نموذجا كانت و ما زالت العديد من شركات البرمجيات تعتمد عليه في إدارة برامجها لأكثر من ١٠ سنوات.
و مع مرور الوقت و ظهور ثقافة ال agile و توابعها مثل ال devops المتمثلة بال CI/CD فقد ظهرت نماذج أخرى بديلة مثل ال
githubflow - trunk based - gitlab flow
لتستبدل ال gitflow
و تكون متوافقة بشكل أكبر مع الثقافات الجديدة و مرونتها
githubflow - trunk based - gitlab flow
لتستبدل ال gitflow
و تكون متوافقة بشكل أكبر مع الثقافات الجديدة و مرونتها
حتى أن مقدمة مقالة Vincent Driessent الشهيرة اليوم تبدأ بهذا التنويه الذي يذكر فيه أن هذا النموذج كان مناسبا لطريقة بناء البرمجيات من ١٠ سنوات إلا أن الوقت الحالي يناسبه تبني ثقافات أقل تعقيدا و أكثر توافقا مع ال agile، و مع ذلك ما زالت الطريقة منتشرة بشكل كبير إلى اليوم.
كل هذه النماذج و طريقة استخدامها و أكثر هو ما سأتحدث عنه غدا في أكاديمية طويق | (الأربعاء) - الساعة ٧ مساءً في جلسة بعنوان: استراتيجيات git لبناء المشاريع البرمجية لمن أراد الاستزادة و الفهم بالتفصيل،
👇🏻 التسجيل:
👇🏻 التسجيل:
جاري تحميل الاقتراحات...