app branching strategy
1.0.0
فهم لماذا s؟
master -> أحدث وأكبر رمز اختبار Devلا توجد جذوع دائمة أخرى.
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> يستخدم لرفع PRS لإتقان لكل تغيير يتم دفعه لإطلاق الفروع YYMM.DD.NN
رقم التصحيح NN ➡
على سبيل المثال: 2301.25.00 ، 2302.01.04
master؟ على حدة master.yml على كل دمج لإتقان نقوم بتحديث النسخة الكاملة. سيتم تعديل الإصدارات الرئيسية ، إذا كان الإصدار الحالي من تاريخ سابق ، وإلا سيتم زيادة رقم التصحيح فقط.
مثال :
الإصدار الحالي: 2301.25.02
إذا تم دفع التزام جديد في 25 يناير ، 2023 ، يصبح الإصدار 2301.25.03
إذا تم دفع التزام جديد في 26 يناير ، 2023 ، يصبح الإصدار 2301.26.00
release/**؟ على بعد الحرية
release* في كل التزام نقوم بتحديث رقم التصحيح على فروع release*
release/** على master ؟ على الحافة ، فإن كل دفعة release* ستؤدي إلى حدوث علاقات عامة مقابلة إلى master عبر فرع auto-backmerge/<pr_number> .
سيتم دمج العلاقات العامة تلقائيًا إذا لم يكن هناك تعارضات
؟ إعداد release.yml قم بإنشاء فرع إصدار من أحدث Master ، مع الإصدار الصحيح في اسم الفرع.
الإجراءات
؟ قم بإنشاء العلامة المقيدة.
الإجراءات
٪٪ {init: {'gitgraph': {'mainbranchName': 'master' ، 'showCommitLabel': True}}} ٪٪
gitgraph
معرف الالتزام: "؟ 2301.25.00"
فرع الإصلاح/الإطارات bug
معرف الالتزام: "إصلاح المنطق"
معرف الالتزام: "إصلاح واجهة المستخدم"
ماجستير الخروج
ميزة الفرع/DM
معرف الالتزام: "إضافة DB"
معرف الالتزام: "إضافة مقبس"
ماجستير الخروج
دمج إصلاح/إطارات معرف: "العلاقات العامة: علة الإطارات"
معرف الالتزام: "؟ 2301.25.01"
ميزة الخروج/DM
MERGE Master ID: "سحب Master"
معرف الالتزام: "إضافة واجهة المستخدم"
ماجستير الخروج
ميزة دمج/معرف DM: "PR: ميزة DM"
معرف الالتزام: "؟ 2301.25.02"
master (الإجراءاتmaster وانتقل إلى الخطوة 2 ٪٪ {init: {'gitgraph': {'mainbranchName': 'master' ، 'showCommitLabel': True}}} ٪٪
gitgraph
معرف الالتزام: "؟ 2301.25.02"
فرع الإصدار/V-2301.25
ماجستير الخروج
معرف الالتزام: "PR: ميزة جديدة" النوع: تسليط الضوء على
معرف الالتزام: "؟ 2301.26.00"
إصدار Checkout/V-2301.25
فرع الإصلاح/الإصدار
معرف الالتزام: "إصلاح الخلل"
إصدار Checkout/V-2301.25
معرف دمج/إصدار معرف: "PR: الإصدار علة"
إصدار Checkout/V-2301.25
فرع التقطيع التلقائي/الإصدار
دمج المعرف الرئيسي: "فرع التحديث"
إصدار Checkout/V-2301.25
معرف الالتزام: "؟ 2301.25.03" العلامة: "V-2301.25.03"
ماجستير الخروج
Merge Auto-Backberge/Release-Bug ID: "Backmerge"
ماجستير الخروج
معرف الالتزام: "؟ 2301.26.01"
الإجراءات
بمجرد أن نكون؟ في جميع الاختبارات ، قم بما سبق لتمييز أحدث الالتزام من فرع الإصدار وإنشاء إصدار جيثب مع ملاحظات الإصدار الآلي. وتحميل القطع الأثرية إلى متاجر التطبيق
إصلاح مشكلة في بناء الإنتاج الحالي ( v-2301.16.01 )
v-2301.16.01 > الفرع: release/v-2301.16 )الباقي هو نفسه تدفق التحرير العادي
٪٪ {init: {'gitgraph': {'mainbranchName': 'release/v-2301.16' ، 'ShowCommitLabel': True}}} ٪٪
gitgraph
معرف الالتزام: "2301.16.04" العلامة: "V-2301.16.04"
فرع Hotfix/Crash
معرف الالتزام: "إصلاح تحطم"
إصدار Checkout/V-2301.16
دمج Hotfix/Crash ID: "تحطم العلاقات العامة"
معرف الالتزام: "؟ 2301.16.05"
فرع Hotfix/علة
معرف الالتزام: "إصلاح الخلل"
إصدار Checkout/V-2301.16
دمج Hotfix/Bug ID: "علة PR"
معرف الالتزام: "؟ 2301.16.06" العلامة: "V-2301.16.06"
التاريخ الخطي مرغوب فيه لأسباب مختلفة. كل الغليان إلى البساطة مرة أخرى.
فقط السماح للاسكواش بالاندماج بجذع واحد هو أبسط طريقة لتحقيق التاريخ الخطي. لا أحد يجب أن يفكر ، يحدث الشيء الصحيح تلقائيًا.
بشكل عام أيضًا ، يتمتع الناس بانضباط أفضل فيما يتعلق بعناوين العلاقات العامة بدلاً من ارتكاب الرسائل ، لذلك تبدو عمليات التغيير الخاصة بك جيدة أيضًا.
على عكس تطبيقات الخادم ، تميل عمليات إصدار تطبيقات الجوال إلى أن تكون طويلة. من الشائع أن يستغرق الأمر أسبوعين أو أكثر إذا قمنا بتضمين التدريج إلى 10 ٪> 20 ٪> 50 ٪> 100 ٪ أثناء مراقبة الاستقرار والمقاييس على طول الطريق.
وفي الوقت نفسه ، لا ينبغي أن يكون للمساهمين غموض ما إذا كان من الآمن الاندماج في السيطرة الآن.
بمجرد إصدار الإصدار ويتم وضع علامة على الالتزام ، ليس لديهم أي غرض. لهذا السبب نحذفهم بعد الإصدار.
جانت
تطوير تطبيق العنوان والإصدارات
DateFormat Yyyy-MM-DD
tickinterval 3day
القسم ديف 1
الميزة 2: A ، 2022-01-13 ، 15D
دمج إلى الماجستير: Crit ، Milestone ، بعد A ، 0D
قسم DEV 2
الميزة 1: ب ، 2022-01-12 ، 2D
دمج إلى الماجستير: معلم ، بعد B ، 0D
ترقية المكتبة ⬆: L ، 2022-01-16 ، 1D
دمج إلى الماجستير: Crit ، Milestone ، بعد L ، 0D
ميزة إصلاح 1 ؟: B2 ، بعد R1 ، 2D
دمج لإصدار: معلم ، بعد B2 ، 0D
ترقية الإطار ⬆: F ، 2022-01-22 ، 1D
دمج إلى الماجستير: Crit ، Milestone ، بعد F ، 0D
إصدار القسم
إعداد الإصدار 2201.14: معلم ، بعد B ، 0D
ميزة الاختبار 1: R1 ، بعد B ، 4D
ميزة الاختبار 1: R2 ، بعد B2 ، 1D
التراجع 2201.14.1 10 ٪ - 100 ٪: R3 ، بعد R2 ، 7D
إعداد الإصدار 2201.31: معلم ، 2022-01-31 ، 0D
دمج لسيادة؟ آمن ومشجع حتى عندما يكون الإصدار مستمر
إنه مخطط الإصدار القائم على التاريخ أيضًا
semver التي يكون الإصدار أكبر من الآخر2301.16.00 > 2212.31.07 )والأفضل من ذلك كله يتجنب السؤال - متى أصدرنا هذا الإصدار؟ إلى الأبد ، من أي شخص في الفريق بأكمله
حتى إذا لم تكن الإجابة على السؤال أعلاه أمرًا مهمًا لفريقك ، فهو جيد بنفس القدر ، إن لم يكن أفضل من semver . التي تستخدمها معظم الفرق بشكل افتراضي. الإصدار الدلالي ( semver ) منطقي للمكتبات. يريد مستهلكي مكتبتك معرفة متى تكون هناك تغييرات كسر وعندما لا تكون هناك. ويستفيد مديرو الحزم من هذه الاتفاقية لترقية التبعيات بأمان. لا يوجد لدى مستخدمي التطبيق / تطبيقات التطبيقات من مثل هذه التوقعات من إصدارات التطبيق. بالكاد يهتمون.
تستخدم فرقي مخططات الإصدار القائمة على التاريخ لأكثر من عام وهو رائع!
