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

تهيئة المستودع

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

$ git init
$ git commit --allow-empty -m "التزام أولي"
$ git checkout -b تطوير الرئيسي

ملاحظة: في بعض الأحيان يكون من المهم للمشروع إضافة المزيد من الفروع اللانهائية، على سبيل المثال، لتمثيل البيئات المتاحة. ومع ذلك، حافظ على "قاعدة الاثنين" إن أمكن.

الفروع المميزة

عند البدء في العمل على ميزة معينة، تأكد أولاً من أن لديك تطوير فرع متزامن.

$ git checkout development & git pull --rebase

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

$ git checkout -b ميزة JIRA-TASK-ID تطوير

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

$ git add .
 $ git commit -m "JIRA-TASK-ID: وصف المهمة"

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

$ git push origin feature-JIRA-TASK-ID

عندما يصبح الفرع جاهزاً، افتح طلب السحب على GitHub، باتباع هذه المقالة: https://help.github.com/en/articles/creating-a-pull-request

قبل فتح طلب سحب، يرجى التأكد مما يلي:

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

$ git checkout develop & git draw --rebase
$ git checkout git ميزة-JIRA-TASK-ID && git rebase develop # استخدم علامة -i للسكواتش
$ git push -f origin feature-JIRA-TASK-ID 1TP63استخدم هذا بعناية لأن علامة -f تستبدل المستودع البعيد

• الاحتفاظ بالالتزامات المهمة فقط - يجب تمثيل كل التزام بمهمة JIRA، على سبيل المثال, JIRA-TASK-ID: تكوين ميزة جديدة; يجب أن يكون الآخرون سحق أثناء إعادة التأسيس فرعك مع فرع التطوير
• لديك فرع الوجهة المناسبة المحددة
• لا تنسى أن تغيير حالة مهمة JIRA الخاصة بك

دمج فرع ميزات الدمج

حان الوقت لدمج تغييراتك في فرع التطوير عندما:

• تمت الموافقة على طلب السحب من قبل أعضاء الفريق المختارين
• انتهت جميع الاختبارات بنجاح
• لا توجد تعارضات في الدمج ويبدو سجل الالتزامات جيدًا

يمكن القيام بذلك إما عن طريق مدير المشروع أو مطور الميزات. لتنفيذ الدمج، اتبع الخطوات التالية:

$ git checkout تطوير
 $ git دمج الميزة-JIRA-TASK-ID
 $ git دفع git الأصل تطوير
 $ git branch -d feature-JIRA-TASK-ID
 $ git push origin :feature-JIRA-TASK-ID

الآن، يمكن تغيير حالة مهمة JIRA.

الإصدارات

يجب إنشاء فروع الإصدار من قبل شخص مسؤول عن الإصدار الحالي. وعادةً ما يتم إنشاء الإصدارات بشكل دوري، على سبيل المثال، وفقًا لـ العدو السريع دورة الحياة.

الإصدار الدلالي

ليس من السهل إعطاء فرع الإصدار اسمًا مناسبًا وعلامة مقابلة في البداية. من الممارسات الجيدة البدء باستخدام الإصدار الدلالي (https://semver.org/) مما يسمح بتحكم أفضل ويجعل قراءة سجل git أسهل. يتم إنشاء سلسلة الإصدار وفقًا لمخطط MAJOR.MINOR.PATCH:

• رئيسي - تغيير يمثل تغييرات غير متوافقة في واجهة برمجة التطبيقات (API)
• ثانوي - إضافة ميزات جديدة بطريقة متوافقة مع الإصدارات السابقة
• PATCH - إضافة إصلاحات أخطاء متوافقة مع الإصدارات السابقة

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

إصدار إصدار

يجب أن يكون فرع الإصدار تابعًا لفرع التطوير ويمكن أن يحتوي فقط على الالتزامات المرتبطة بإصلاح الأخطاء.

يجب أن يستند اسم الفرع إلى إصدار الإصدار، مع استخدام بادئة الإصدار: إصدار-MAJOR.MINOR.MINOR.PATCH. يجب أن يكون فرع الإصدار تم اختباره بالكامل آلياً ويدوياً على بيئة التدريج. في حالة حدوث أخطاء، فهذه هي الفرصة الأخيرة لدفع الإصلاحات المناسبة وإعادة تشغيل العملية بأكملها، طالما أنه لن يتم التحقق منها بشكل إيجابي وجاهز لمزيد من المعالجة. بعد ذلك، يجب دفع التزام الإصدار، مع تغييرات سلسلة إصدار الإصدار الحالي في الملفات، مثل package.json. يجب أن يكون له تأثير أيضًا على ملف CHANGELOG.md. سيساعدك هذا على تتبع جميع التغييرات قبل الإصدار المناسب وإعداد المحتوى لإصدار GitHub عند اكتمال عملية الدمج. يجب أن يتكون تحديث الملف الواحد من جميع تغييرات الإصدار المجمعة في ثلاث فئات: الميزات والإصلاحات والصيانة.

ولكن في الخطوة الأولى، تأكد من تحديث كل من فرعي التطوير والفرع الرئيسي.

 $ git checkout Master && git pull --rebase
 $ git checkout developer && git pull --rebase
 $ git merge Master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "المنتج اسم الإصدار M.M.P"
 $ git push origin release-M.M.P

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

$ git checkout master
 $ git دمج الإصدار M.M.P
 $ git tag -a M.M.P $ يمكن تعيين رسالة الإضافة عبر العلامة -m
 $ git push origin M.M.P
 $ git دفع الأصل الرئيسي
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.M.P

ثم انتقل إلى صفحة إصدارات GitHub واضغط على زر "مسودة إصدار جديد". في النموذج المعروض، حدد علامة الإصدار الحالي، وقم بتعيين عنوان الإصدار المشابه لالتزام الإصدار (إصدار اسم المنتج M.M.P) ووصف مناسب، استنادًا إلى ملف CHANGELOG.md. بالنسبة للمشاريع العامة، يجب أن يحتوي الوصف على قائمة بجميع العلاقات العامة المضمنة في الإصدار الحالي.

في حال تم تطبيق بعض إصلاحات الأخطاء على فرع الإصدار، تأكد من تحديث فرع التطوير الخاص بك:

$ git checkout development & git merge master
$ git push origin develo

الإصلاحات العاجلة وإصلاحات الأخطاء

الفرق الرئيسي بين الخطأ والإصلاحات الساخنة هو الفروع المستهدفة.

إصلاح الأخطاء

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

$ git checkout الإصدار-M.M.P & git pull --rebase
 $ git checkout -b bugfix-M.M.P

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

$ git checkout إصدار M.M.P
 $ git دمج الإصلاح الخاطئ-M.M.P
 $ git push origin release-M.M.P

هوت فيكس

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

$ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y. (Z+1) # M.M.P يمثل الإصدار الحالي

بعد ذلك، اتبع خطوات التطوير المعتادة وعندما تنتهي العملية، قم بإنشاء طلب سحب مع الفرع الرئيسي كهدف. ضع في اعتبارك أن الالتزام النهائي يجب أن يتطابق مع المخطط المحدد "الإصلاح السريع X.Y.(Z + 1): إصلاح جوهر المشكلة". عند اجتياز كل نقطة تدقيق بنجاح، قم بإجراء دمج إلى الرئيسي. تختلف هذه الخطوات عن تلك المقدمة لإصلاح الأخطاء، حيث نحتاج إلى رفع إصدار الإصدار الحالي.

$ git checkout master && git pull --rebase
 $ git دمج هوتفيكس-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) $ يمكن تعيين رسالة الإضافة عبر العلامة -m
 $ git push origin X.Y.(Z+1)
 $ git دفع الأصل الرئيسي
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origin :hotfix-X.Y.(Z+1)
 $ git checkout تطوير &&دفع git merge master
 $ git دفع الأصل تطوير

ورقة الغش

المستودع الأولي

$ git init
 $ git commit --allow-empty -m "التزام أولي"
 $ git checkout -b تطوير الرئيسي
 $ git push origin developer
 $ git دفع الأصل الرئيسي

الميزات

$ git checkout git develop & git pull --rebase
$ git checkout -b ميزة-JIRA-TASK-ID تطوير

بدء التطوير والالتزامات الخاصة بك

$ git add .
$ git commit -m "IRA-TASK-ID: وصف المهمة" #نفيذ الالتزام الأولي
$ git push origin feature-JIRA-TASK-ID

فتح طلب سحب مفتوح

إعادة التأسيس والتحضير لطلب السحب

$ git checkout git develop & git pull --rebase
$ git checkout ميزة التحقق من ميزة-JIRA-TASK-ID & git rebase develop # استخدم علامة -i للسكواتش
$ git push -f origin feature-JIRA-TASK-ID 1TP63استخدم هذا بعناية لأن علامة -f تستبدل المستودع البعيد

دمج التغييرات وحذف الفرع

$ git checkout تطوير $ يجب مزامنة فرع # مع فرع التطوير في هذه المرحلة
$ git دمج الميزة JIRA-TASK-ID
$ git دفع git الأصل تطوير
1PTP62T git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

الإصدارات

$ git checkout Master && git pull --rebase
$ git checkout developer && git pull --rebase
$ git merge Master
$ git checkout -b release-M.M.P

إنشاء التزام الإصدار

$ git add .
$ git commit -m "اسم المنتج إصدار M.M.P" 1TP63التزام أولي
$ git push origin release-M.M.P

فتح طلب سحب مفتوح

دمج التغييرات والإصدار وحذف الفرع

$ git checkout master يجب مزامنة فرع # مع الفرع الرئيسي في هذه المرحلة
$ git دمج الإصدار M.M.P
$ git tag -a M.M.P $ يمكن تعيين رسالة الإضافة عبر العلامة -m
$ git push origin M.M.P
$ git دفع الأصل الرئيسي
$ git branch -d release-M.M.P
$ git push origin :release-M.M.M.P

إصلاح الأخطاء

$ git checkout الإصدار-M.M.P & git pull --rebase
$ git checkout -b bugfix-M.M.P

$ التزم بالإصلاحات
$ git add .
$ git ارتكاب -m "إصلاح الأخطاء M.M.P: إصلاح جوهر المشكلة" 1TP63التزام أولي
$ git push origin bugfix-M.M.P

فتح طلب سحب مفتوح

دمج التغييرات وحذف الفرع

يجب مزامنة فرع $ git checkout الإصدار-M.M.P # مع فرع الإصدار الحالي في هذه المرحلة
$ git دمج الإصلاح الخاطئ-M.M.P
$ git دفع الإصدار الأصلي-M.M.P
$ git branch -d bugfix-M.M.P
$ git دفع الأصل:bugfix-M.M.P

هوت فيكس

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P يمثل الإصدار الحالي

$ الالتزام بالإصلاحات
$ git add .
$ git ارتكاب -m "الإصلاح الساخن M.M.P: إصلاح جوهر المشكلة" 1TP63التزام أولي
$ git push origin bugfix-M.M.P

فتح طلب سحب مفتوح

دمج التغييرات وإصدار وحذف الفروع

$ git checkout Master # يجب مزامنة الفرع # مع الرئيسي الحالي في هذه المرحلة
$ git دمج هوتفيكس-X.Y. (Z+1)
$ git tag -a X.Y.(Z+1) $ يمكن تعيين رسالة الإضافة عبر العلامة -m
$ git push origin X.Y.(Z+1)
$ git دفع الأصل الرئيسي
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout تطوير &&دفع git merge master
$ git دفع الأصل تطوير

اقرأ المزيد:

• ممارسة Codest الجيدة لبناء البرمجيات: CircleCI
• كيفية إنشاء ملحقات Google Chrome باستخدام مصمم ترجمات Netflix؟
• React: إطار React الأكثر شيوعًا