سير العمل في Git
كيف تنظّم الفرق الفروع والمراجعات والإصدارات. يأتي كل سير عمل أدناه مع قواعده كما صاغها مصدره الأصلي، ومتى يناسب، وعرض متحرك — يشغّله محاكي Git ويُتحقَّق منه مقارنةً بـ Git الحقيقي.
| سير العمل | فروع طويلة الأمد | طريقة الإصدار | الأنسب لـ |
|---|---|---|---|
| main | نشر main بعد كل pull request مدموج | تطبيقات تُنشر باستمرار | |
| main, develop | فروع release، يوضع وسمها على main | برمجيات بإصدارات مرقّمة، مع دعم عدة إصدارات | |
| main (the trunk) | من الجذع (trunk)، أو من فرع release قصير الأمد | فرق CI/CD تدمج يوميًا | |
| upstream’s main | المشرفون يدمجون pull requests القادمة من الـ forks | المصادر المفتوحة، مساهمون بلا صلاحية كتابة |
GitHub flow
فرع main واحد + فروع قصيرة الأمد + pull requests
سير عمل خفيف قائم على الفروع. كل ما في main قابل للنشر؛ ويُجرى كل تغيير على فرع خاص باسم وصفي، ثم يُدمج في main عبر pull request تمت مراجعته، ثم يُنشر.
القواعد
- كل ما في فرع main قابل للنشر.
- أنشئ فرعًا باسم وصفي من main لكل تغيير.
- سجّل الـ commits محليًا وادفع بانتظام إلى الفرع الذي يحمل الاسم نفسه.
- افتح pull request لطلب الملاحظات، أو عندما يصبح الفرع جاهزًا للدمج.
- ادمج في main بعد المراجعة، ثم احذف الفرع.
- انشر فور الدمج (في المقال الأصلي: «يمكنك بل يجب أن تنشر فورًا»).
✓ استخدمه عندما
تطبيقات الويب والخدمات التي تُنشر باستمرار من إصدار واحد.
✗ تجنّبه عندما
عليك صيانة عدة إصدارات منشورة في الوقت نفسه.
المصادر
فتح الـ pull request ودمجه يتمّان على GitHub؛ ويعرض العرض المتحرك عمليات Git المكافئة (زر الدمج الافتراضي في GitHub ينشئ commit دمج).
ابدأ سير العمل وامشِ فيه مرة واحدة.
0.0s / 142s
commitالحلقة = الـ commit الذي يقف عليه HEADغير قابل للوصول (لا يزال موجودًا)الفرع = لافتة متحركةorigin/* = إشارتك المرجعية للمستودع البعيدHEAD = موقعك الحالي
1 إنشاء فرع
2 إجراء التغييرات
3 إنشاء pull request
4 معالجة تعليقات المراجعة
5 دمج الـ pull request
6 حذف فرعك