Git Branching Strategy

كيف ينظم فريق ما العمل المتوازي في Git، وبالنسبة لـ Salesforce، كيف يتوافق ذلك مع بنية الـ org.

التعريف

تحدّد استراتيجية تفريع Git كيف ينظم فريق ما العمل المتوازي في التحكم بالإصدارات: ما هي الفروع الموجودة (main وdevelop وfeature وrelease)، وكيف تُدمج التغييرات بينها، ومتى. تشمل النماذج الشائعة GitFlow (فروع develop وrelease طويلة الأمد إلى جانب فروع feature)، وtrunk-based development (فروع قصيرة الأمد تُدمج بشكل متكرر في main واحد)، وenvironment branching، أي فرع لكل org في Salesforce، وهو أمر شائع تحديدًا في Salesforce. بالنسبة لفرق Salesforce، تتوافق استراتيجية التفريع عادةً بشكل مباشر مع استراتيجية الـ org، حيث يقابل كل فرع طويل الأمد عادةً بيئة sandbox، ما يعني أن النموذج يجب أن يراعي بنية بيئة Salesforce نفسها، لا مجرد تنظيم الكود. إخفاق هذا يسبب ألمًا حقيقيًا: تعارضات دمج في ملفات البيانات الوصفية، وعمليات نشر لا تطابق ما هو موجود فعليًا في org، وارتباك حول أي فرع يعكس الإنتاج. يغطي دليلنا لـ Salesforce DevOps كيف تندمج استراتيجية التفريع ضمن عملية إصدار كاملة.

من واقع الاستخدام

إزاي بيشتغل في Serpent

تستبدل Serpent إدارة الفروع بتتبّع قائم على Work Item: يعمل المسؤولون والمطوّرون والمختبِرون عبر Work Items بدلاً من إنشاء الفروع ودمجها يدويًا، بينما تُشغّل Serpent عمليات Git في الخلفية، مقابل المستودع الذي تملكه بالفعل على GitHub أو مضيف آخر، للحفاظ على دقة السجل. هذا يزيل مشكلات تعارضات الدمج وتشعب الفروع التي تواجهها فرق Salesforce مع نماذج التفريع التقليدية، دون فقدان سجل الالتزامات (commits) الكامل أو القدرة على تتبّع أي تغيير مرة أخرى إلى Work Item الخاص به. لا تزال الفرق التي تريد سير عمل أصيل قائم على Git تحصل عليه؛ فقط لا يتعين عليها إدارته يدويًا. راجع سير العمل القائم على Work Item في Serpent لمعرفة كيف يستبدل التفريع اليدوي.

Serpent يطبّق استراتيجية تفريع Git على مسار orgs في Salesforce

أسئلة شائعة