الطريقة المثالية للإستخدام Git في مشروعك (Git Flow)

الطريقة المثالية للإستخدام Git في مشروعك (Git Flow)

مرحبا بكم في موضوع جديد لـ Git ،هذا الموضوع راح يكون جداً مفيد لجميع المطورين في مشاريعهم الحالية والمستقبلية ،وسواء كانوا يعملوا بشكل منفرد او مع فريق.

أنصح قبل قراءة هذا الموضوع بقراءة موضوعي السابق
كيف تتجاهل الملفات في مشروعك البرمجي عند استخدامك Git ؟

على أي حال جميع المطورين يعتمدوا على Git في مشاريعهم البرمجية ، ولكن كل مطور او فريق من المطورين يعتمدوا على نهج مختلف عن الاخر حتى عام 2010 عندما كتب مطور رهيب اسمه Vincent Driessen عن تجربته في مشاريعه الخاصة وايضا في مشاريع عمله ومن تجربته لمدة سنة لاحظ بأنها طريقة جداً ناجحه ، فيما بعد سميت بـ Git Flow 

ماهي طريقة Git Flow ؟ 

بداية لتوضيح الأمور الـ Git Flow عباره عن Branching Model بمعنى انها عباره عن استراتجية او طريقة ،تساعدك عند اتباعها على تجنب الكثير من المشاكل التي قد تواجها في مشروعك وتعاملك مع Git.

فكرتها هي :

البداية

سوف تملك في المشروع 2 من الـ Branch واحد يدعى master والاخر develop . والذين يعتبروا اساس طريقة الـ Git Flow

بداية مشروعك راح تعمل Branch جديد من الـ master تسميه develop ومن الان كل شغلك راح يكون على develop ! ، الـ master عباره عن نسخة الـ Production للمشروع ، بمعنى فقط يحتوي على النسخه المستقرة من المشروع وبما يعني ايضا بانه لن تعمل Merge للـ master الا في حالات معينه فقط !

Features branches 

في كل مره تريد اضافة ميزة جديدة او حتى تصلح Bugs يحتاج له وقت لحله راح تسوي Branch جديد لكل ميزة (feature) ، وضروري تنتبه بأنه يؤخد من الـ develop وليس من الـ master !

ما الفكرة هنا ؟
كل ميزة راح يكون لها Branch مستقل ، وبالتالي جميع الفريق سوف يركز على تطوير المميزات بشكل مستقل وايضا يستطيع مطورين او أكثر التعاون فيما بينهم لتطوير الميزة ، فالفائده هنا عمل الفريق كامل بشكل متزامن وايضا متعاون فيما بينهم .

لاحظ في هذه الصورة عندنا ميزتين ، الميزة الاولى انتهى تطويرها واختبارها بعد الانتهاء منها تم دمجها (merge) مع الـ develop وايضا سيتم حذف الـ Branch لانه لن يكون له فائده بعد الـ merge ، ومن ثم فعلنا نفس الامر مع الميزة الاخرى عندما انتيهنا منها تم دمجها مع الـ develop 

Release branches

بعد اضافة عدة مميزات سوف تقرر بأنه حان الوقت لاطلاق نسخة جديدة لمشروعك سواء لمتجر التطبيقات اذا كان تطبيق او ترفعه على السيرفر اذا كان موقع، هنا راح تسوي Branch جديد اسمه release-رقم النسخة 

ما الفائده من هذا الـ Branch ؟ في هذا الـ Branch النسخه تكون جاهزة للاطلاق ، فهنا يتم اختبارها سوا من قبل المستخدمين كمثال اطلاق نسخة للتطبيق في Testflight او من الفريق الـQA بعد عمل هذا الـ Branch تتوقف اضافة مميزات جديدة لهذه النسخه وفقط يتم حل الـ Bugs المكتشف اثناء تجربة المشروع من قبل الـ Testers.

لكن يمكن الاستمرار في تطوير مميزات جديدة للنسخه التالية من خلال feature branch ، فهذا المغزى من الـ Git Flow المشروع يستمر في التطوير بشكل متزامن

الان وصلت لمرحلة مستقرة للنسخة وحان وقت اطلاقها للمتجر او الموقع ، الذي سوف تقوم به هو دمجها اولاً مع الـ master وايضا اعطائها Tag برقم النسخه
ومن ثم دمجها مع الـ develop واخيرا يتم حذف Branch الـ release لعدم الحاجة له.

تذكر في بداية الموضوع ذكرت بأنه هناك حالات معينه فقط سوف تدمج الـBranch مع الـ master وايضا ذكرت بأن الـ master هو الذي يحتوي على نسخ الـ Production وهنا ذكرت بأنه يجب اضافة Tag برقم النسخة ، الـ Tag راح يفيدك مستقبلاً ، مثلا اطلقت نسخه واكتشفت وجود مشكلة كبيرة اضطريت تسحب النسخه ، فهنا تستطيع العودة للنسخه المستقرة اعتمادا على الـ Tag، ايضا في حال اكتشفت وجود bug يحتاج الى إصلاح بشكل عاجل ايضا راح يفدك الـ Tag

Hotfix branches

افترض اطلقت نسخه للتطبيق او الموقع وبعد اطلاقه اكتشفت انه في Bug
وهذا الـ Bug يتوجب عليك اصلاحه بشكل عاجل ولا يتحمل التأخير الى النسخة الاخرى ، وفي نفس الوقت المطورين مستمرين في تطوير مميزات جديدة لاطلاقها في النسخه الاخرى وتم دمج بعضها في الـ develop بما يعني Branch الـdevelop ماهو مستقر فهنا الحالة الوحيدة التي سوف تعمل Branch جديد للـ hotfix من الـ master !
وايضا مثل الـ release سوف يحتوي على Tag برقم النسخة ومن ثم تقوم بحل الـBug وعند الانتهاء منه تقوم بدمج الـ hotfix مع الـ master وايضا الـdevelop اخيراً يتم حذف Branch الـ hotfix لعدم الحاجة له

كذا نكون انتهينا من شرح طريقة الـGit Flow بشكل نظري. بما انه هناك الكثير من التفاصيل هذه النقاط المهمه التي يجب الانتباه لها :

الـ develop يتم عمله من الـ master

الـ feature يتم عمله من الـ develop

الـ release يتم عمله من الـ develop

عند اكتشاف Bug في نسخة التي تم اطلاقها بشكل رسمي يتم عمل hotfix من الـ master

عند الإنتهاء من الـ feature يتم دمجه مع الـ develop

عند الإنتهاء من الـ release يتم دمجه مع الـ master و الـ develop

عند الإنتهاء من الـ hotfix يتم دمجه مع الـ master و الـ develop

شرح تطبيق طريقة الـ Git Flow في مشروعك 

هناك عدة طرق لاستخدامها في مشروعك :

طريقة يدوية عن طريق استخدام اوامر الـ Terminal

طريقة مختصرة عن طريق تثبت أداة git-flow ومن ثم ايضا استخدام اوامر الـ Terminal

طريقة مختصرة وبواجهة رسومية باستخدام برنامج Sourcetree

في هذا الموضوع سوف اشرح الطرق الثلاثه مع اني افضل الـSourcetree
والسبب لتتبع الشرح بالطريقة التي تفضلها وتراها مناسبة لك

تثبيت الأدوات المناسبة

بما أنك تقرا هذا الموضوع فبطبيعة الحال مثبت في جهازك الـ Git وتعلم كيف تستخدمه لذلك سوف اتطرق لباقي الادوات

أداة git-flow يمكنك تحميلها بكتابة هذا الامر في نظام الماك
اذا كنت مستخدم لنظام اخر اتبع الشرح في هذه الصفحة

brew install git-flow-avh

برنامج الـSourcetree يمكن تحميله من هنا 

نفس البرنامج يحتوي على اداة git-flow مثبته مسبقاً فاذا اردت استخدامه لا تحتاج الى تثبيت الاداة السابقة.

تجهيز المشروع

الطريقة اليدوية :
تقوم بإنشاء Branch بإسم develop في جهازك ومن تعمل push لرفعه الى الـ remote repository بكتابة هذه الاوامر

git branch develop git push -u origin develop

أداة git-flow :
تقوم بكتابة هذا الامر فقط

git flow init

بشكل تلقائي سوف يقوم بإنشاء Branch الـ develop ايضا سوف تلاحظ بأنه يسألك عن مسميات بقية الـ Branches الافضل تركها كما هيا

git flow init Initialized empty Git repository in ~/project/.git/ No branches exist yet. Base branches must be created now. Branch name for production releases: [master] Branch name for "next release" development: [develop] How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Version tag prefix? []

برنامج الـSourcetree 
اتبع الصور التالية :

إنشاء الـ Features branch 

الطريقة اليدوية :
تأكد بأنك في الـ develop ومن ثم أنشئ الـ feature branch
مع ملاحظة تسمية اسم الميزة بإسم واضح ، هنا من أجل الشرح فقط تم تسميتها بـ feature-branch 

git checkout develop git checkout -b feature_branch

أداة git-flow :
تقوم بكتابة هذا الامر فقط

git flow feature start feature_branch

برنامج الـSourcetree 
اتبع الصور التالية :

بعد انشاء الـ feature استخدم الـ git كما تستخدمه عادةً بمعنى اعمل التعديلات وسوي commit و push حتى تنتهي من الميزة

الانتهاء من الـ Features branch 

هنا اريد أن اوضح نقطه معينه، لما تسوي finish feature الي راح يصير كما ذكرنا في الشرح سابقا سوف يتم الدمج مع الـ develop ! 

ملاحظة مهمه وهيا اعمل pull للـ develop قبل الضغط على finish feature او عمل الـ merge
لجعل النسخه التي في جهازك من الـ develop طبق الاصل مع الـ remote

الامر هنا قد يختلف من فريق الى فريق اخر :

بعض المطورين سوف يتفقوا على أنه أي مطور ينهي تطوير الميزة يقوم بدمجها مع الـ develop بشكل مباشر !
 (هذا الامر ايضا سوف تفعله عندما تقوم بتطوير المشروع بشكل منفرد)

بعض المطورين سوف يتفقوا على أنه أي مطور ينهي تطوير الميزة ،يقوم بإرسال Pull request وفقط مطور معين في الفريق سوف تكون من مهامه قبول الدمج من عدمه !

في حال المطورين اتفقوا على السيناريو الاول

الطريقة اليدوية :
تأكد بأنك في الـ develop ومن ثم أعمل Merge للـ feature_branch
أخر خطوة تقوم بحذف Branch الـ feature_branch

git checkout develop git merge feature_branch git branch -d feature_branch

أداة git-flow :
تقوم بكتابة هذا الامر فقط ،تلقائيا سوف يقوم بكل ما سبق في الطريقة اليدوية!

git flow feature finish feature_branch

برنامج الـSourcetree 
اتبع الصور التالية :

في حال المطورين اتفقوا على السيناريو الثاني

بعد الانتهاء من تطوير الـfeature لا تقوم بالضغط على Finish Feature او تعمل Merge بدلا من ذلك اعمل فقط push 

الطريقة اليدوية :
تأكد بانك على Branch الـ feature التي تريد عمل لها push
ومن ثم نفذ امر الـ push لرفعها الى الـ remote repository

git checkout -b feature_branch git push -u origin feature_branch

أداة git-flow :
تقوم بكتابة هذا الامر فقط

git flow feature publish feature_branch

برنامج الـSourcetree 
بعد عمل الـ Commit فقط اضغط على زر Push
وتستطيع تختصر الامر عند عمل أي Commit تقوم بتفعيل خيار عمل Push بشكل تلقائي كما في الصورة التالية

بعد تنفيذ اي طريقة من الطرق السابقة يتبقى فقط عمل الـ pull request
افتح صفحة المشروع سوا في github او gitLab او غيره
سوف تجد بشكل تلقائي خيار لعمل pull request في الصفحة
كما في الصورة التالية :

توضيح سبب تسمية الـ Branch بـ feature_branch2 هو لاني قمت سابقا بدمج الـ feature_branch  بإستخدام finsh feature ، فبدلا من استخدام نفس الاسم قمت بعمل Branch  باسم مختلف

عند الضغط على Compare & pull request 

تأكد بأن خيار الـ base على develop وايضا تأكد بأن خيار الـ compare على Branch الـ feature التي قمت بالانتهاء منها وليس Branch لـ feature اخر !

تستطيع كتابة معلومات اضافيه هنا اذا اردت إضافتها ! ومن ثم اضغط على create pull request

المطور المسؤول يستيطع النقاش معاك في نفس هذه الصفحة وايضا يستيطع إغلاق الـ pull request او يقوم بقبوله وعمل Merge

بعد المواقفة على الـ pull request سيتم الدمج مع الـ develop
وفي هذه الحالة ستكون النسخه الي عندك للـ develop قديمة وغير مطابقة للنسخة في الـ remote وهنا فقط تحتاج تسوي pull لجلب البيانات الجديدة

احيانا راح يصير Merge Conflicts بما يعني تعارض في عملية الدمج
عند عمل finish feature ، او بعد عمل pull request وثم قبول الـ merge
كما شرحت سابقاً ، فهنا فقط حل التعارض واعمل push للتغيرات

في أغلب الأحيان سوف تواجهه الـ Merge Conflicts والذي تعني تعارض  ،السبب بإختصار بأن هناك إختلاف بين النسخ
من تجربتي أفضل طريقة لحل التعارض هو فتح الملفات التي تحتوي على التعارض في برنامج Visual Studio Code
ومن البرنامج سوف يوضحلك الاسطر في الكود التي سببت التعارض وسوف يخيرك اي سطر تريد إبقاءها هل تريد إبقاء أسطر النسخه القديمة او الجديدة.

إنشاء الـ Release branch 

بعد اضافة عدة مميزات للنسخه التالية من المشروع ، سوف يحين وقت اختبار النسخه النهائية قبل الاطلاق ، فهنا سوف تقوم بإنشاء الـRelease branch 

كما ذكرنا سابقا في الشرح عند الوصول لهذه النقطة سوف تتوقف من اضافة مميزات جديدة للمشروع للنسخه التالية ! لكن تستطيع الاستمرار في تطوير مميزات جديدة للنسخه ما بعد التالية .

بما يعني Branch الـ release يكون فقط لاصلاح الـ Bugs الذي قد يظهر من استخدام النسخه من قبل المختبرين الـ Testers

طريقة إنشاء الـ release مشابة لإنشاء الـ feature

الطريقة اليدوية :
تأكد بانك على Branch الـ devlop من ثم أنشئ الـ release branch
مع ملاحظة اضافة رقم للنسخة يكون مطابق لرقم نسخة التطبيق

git checkout develop git checkout -b release/1.0

أداة git-flow :
تقوم بكتابة هذا الامر فقط

git flow release start 1.0

برنامج الـSourcetree 
اتبع الصور التالية :

الانتهاء من الـ Release branch 

الامر هنا مشابه للـ feature واعتمادا على الاتفاق مع بقية مطورين الفريق
اما سوف يتفقوا على السيناريو الاول كما سوف اقوم بالشرح هنا او سوف يتفقوا على السيناريو الثاني . في حال اتفقوا على السيناريو الثاني فيجب الملاحظه بأنه هناك فرق عن الـ feature وهو بعد عمل merge مع الـ develop سوف تقوم ايضا بعمل merge للـ develop مع الـ master

ملاحظة مهمه وهيا اعمل pull للـ develop وايضا للـ master قبل الضغط على finish release او عمل الـ merge
لجعل النسخه التي في جهازك من الـ develop و master طبق الاصل مع الـ remote

الطريقة اليدوية :
تأكد بانك على Branch الـ master من ثم تقوم بعمل merge للـ release branch مع الـ master

git checkout master git merge release/1.0

ومن ثم سوف تقوم ايضا بدمج الـ release مع الـ develop ، اخر خطوة تقوم بحذف الـ release

git checkout develop git merge release/1.0 git branch -D release/1.0

أداة git-flow :
تقوم بكتابة هذا الامر فقط ،تلقائيا سوف يقوم بكل ما سبق في الطريقة اليدوية!

git flow release finish '1.0'

برنامج الـSourcetree 
اتبع الصور التالية :

بعد عمل الـ merge لا تنسى تعمل push لرفعها الى الـ remote

إنشاء الـ Hotfix branch 

كما ذكرت في الشرح سابقاً ، الـ hotfix branch تكون للحالات الحرجة فقط وفكرتها انه تحل Bug حرج ظهر بعد اطلاق النسخة بشكل رسمي. لذلك من النادر استخدام الـ hotfix

وتذكر Branch الـ hotfix ينعمل من الـ master وهو الـ Branch الوحيد الذي يتم انشائه من الـ master

الطريقة اليدوية :
تأكد بانك على Branch الـ master من ثم أنشئ الـ hotfix branch

تذكر الـ hotfix مشابه للـ release والسبب لأنك سوف تقوم بحل Bug بشكل عاجل ومن ثم سوف تقوم بإطلاق النسخه بشكل عاجل . لذلك سوف تعطي رقم جديد للنسخة !

وغالبا في تسمية النسخ :
الرقم الاول 1.0 يكون للنسخه الجديدة بميزات وتغيرات كبيرة
الرقم الثاني 1.0 يتغير اذا اطلقت نسخه جديدة باضافة مميزات الجديدة
الرقم الثالث 1.0.1 يتغير عند حل Bug في الغالب
لذلك سوف نقوم بتسمية نسخة الـ hotfix بـ 1.0.1

git checkout master git checkout -b hotfix/1.0.1

أداة git-flow :
تقوم بكتابة هذا الامر فقط

git flow hotfix start 1.0.1

برنامج الـSourcetree 
اتبع الصور التالية :

الانتهاء من الـ Hotfix branch 

ملاحظة مهمه وهيا اعمل pull للـ develop وايضا للـ master قبل الضغط على finish hotfix او عمل الـ merge
لجعل النسخه التي في جهازك من الـ develop و master طبق الاصل مع الـ remote

الطريقة اليدوية :
تأكد بانك على Branch الـ master من ثم تقوم بعمل merge للـ hotfix branch مع الـ master

git checkout master git merge hotfix/1.0.1

ومن ثم سوف تقوم ايضا بدمج الـ hotfix مع الـ develop ، اخر خطوة تقوم بحذف الـ hotfix

git checkout develop git merge hotfix/1.0.1 git branch -D hotfix/1.0.1

أداة git-flow :
تقوم بكتابة هذا الامر فقط ،تلقائيا سوف يقوم بكل ما سبق في الطريقة اليدوية!

git flow hotfix finish '1.0.1'

برنامج الـSourcetree 
اتبع الصور التالية :

بكذا نكون انتيهنا من الموضوع وشرح طريقة الـ Git Flow
صحيح هذه الطريقة تحتوي على كثير من التفاصيل ولكنها جداً مفيدة عند تطوير مشروعك على المدى البعيد سوف تلاحظ اهميتها !