نظام Git: الأساسيات وأفضل الممارسات وكيفية الالتزام بنظام GitFlow
طور لينوس تورفالدس مطوّر نواة لينوكس الشهيرة برنامج Git ليصبح البرنامج الأكثر استخداما لحفظ الإصدارات المختلفة من الكود بين مجتمع المطورين، بحيث أصبح لا غنى عنه في المشروعات البرمجية التي تتطلب تعاونا بين فرق العمل، ولذلك على كل مطور أو مبرمج أن يبدأ في التعرف على أساسيات النظام وكيفية استخدامه وأفضل الممارسات وكيفية الالتزام بنظام GitFlow وهو ما نحاول المساعدة فيه من خلال هذا المقال.
اساسيات نظام Git:
يعد نظام Git هو نظام التحكم بالإصدار (version control system) الأكثر استخداما. وتعتمد فكرته في الأساس على تتبع سلسة التغييرات التي تقوم بها على الملفات، فيصبح لديك سجل (log) بالإضافات والحذف والتعديلات التي قمت بها منذ بدء المشروع، فيمكنك العودة إلى إصدارات محددة إذا احتجت إلى ذلك.
يعتمد Git على ثلاثة بيئات للعمل:
عادة ما يتم استخدام Git كالتالي:
git initgit add filename git status git diff // Check the differencesgit commit -m "Initial commit" git log
انت الان تحتفظ بكل التعديلات التي قمت بها في الكود وتستطيع العودة إليها اذا ما احتجت الي ذلك ولكن أحيانا لا نكون متأكدين من الكود الذي كتبناه أو من الميزة feature الجديدة التي أضفناها ونود أن نجرب إضافتها بشكل مختلف، في هذه الحالة:
git branch branchName // create new branchgit checkout branchName // Go the new branchgit checkout main // go to the main branchgit merge branchName // merge the code to main git branch -d branchName // delete the branch
يتم تخزين الملفات بتواريخ التغييرات على جهاز الحاسب الخاص بك، ولكن يمكنك أيضا استخدام احدى أدوات Git ذات واجهات الاستخدام مثل مواقع GitHub وGitBucket أو GitLab وهي تسمح لك بتخزين نسخة من المستودعات الخاصة بك وما تحتويه من ملفات على الإنترنت، مما يتيح سهولة مشاركتها مع فريق العمل؛ بل ان الإحتفاظ بالكود في مكان مركزي يتيح للجميع العمل على نفس النسخة من الكود بشكل متزامن مع دمج تغييرات كل عضو في الفريق في وقت لاحق دون أن يُفقد عمل اي مطوّر وهو ما يعد أحد أفضل مميزات Git.
للتعاون مع فريق العمل من خلال Git، غالبًا سوف يقوم كل فرد بالعمل على النحو التالي:
git clone repoLocation cloneNameOfChoicegit fetch git merge origin/branchName// Create a featureBranchName// Repeat fetch and mergegit push branchName origin
الطريقة التي رأيناها للتو تعمل بشكل جيد، ومنظمة، فهي تسمح للمطورين بالعمل بشكل متزامن في إنشاء خواص جديدة أو إصلاح أخطاء تم اكتشافها دون المساس بالكود الأصلي وهي سهلة وتفي بالغرض. لكن في حال كنت تعمل على مشروع كبير فإنك قد توّد أن تأخذ حذرك أكثر من ذلك بحيث لا يسمح بدمج الكود من الفروع إلى الكود الأصلي في أي وقت. من هنا نشأت فكرة طرق سير عمل GitFlow وهي تعتبر إطار يحدد لكل مطوّر طريقة معينة لدمج الكود بحيث يكون الكود الأصلي دائما جاهزا للإصدار وخاليًا من العيوب.
تعرّف على طريقة سير العمل الصارمة GitFlow
كما تحدثنا، فإن الهدف من ال GitFlow هو ضمان جودة واستقرار الكود. وهو يعتمد على تخصيص أدوار معينة للفروع branches المختلفة، ويحدد متى و كيف تتفاعل هذه الفروع مع بعضها البعض. يعتمد نظام سير GitFlow على وجود فرعين أساسيين للمساهمة عليهم: الفرع الرئيسي main ويُعرف أيضًا بفرع الإصدار release branch وفرع التطوير develop.
بهذه الطريقة يكون الفرع الرئيسي جاهزا في أي وقت للإصدار ويكون بنسبة كبير خاليًا من العيوب الخطيرة وبذلك تزيد كفاءة الكود ويصبح التطبيق أكثر إستقرارا؛ وفي نفس الوقت يستطيع المطورون من العمل بشكل متزامن سواء في فروع الـ fetaures أو الـ bugFixes.
حسنًا، الآن يمكننا استخدام Git ويمكننا تطبيق GitFlow ولكن يمكننا دومًا التحسن في إستخدام Git، دعنا نحاول استعراض بعض أفضل الممارسات عند استخدام Git.
أفضل الممارسات عند استخدام Git
سنحاول في هذا الجزء تحديد بعض النقاط المفيدة عند التعامل مع Git ولكن أهم هذه النقاط هي كتابة الـ commit message بشكل واضح حيث تعد هذه الرسائل المصممة جيدًا أفضل طريقة لإيصال السياق المطلوب حول التغييرات التي تمت لزملائك في الفريق. لذلك دعنا في البداية نتحدث عن الطريقة الأفضل لكتابة رسائل الـcommits:
إليك بعض النقاط الأخرى التي ستساعدك على استخدام Git بالشكل الأمثل:
// git bisectgit bisect startgit bisect bad head git bisect good dc7a3cfgit bisect reset
كل النقاط السابقة يمكن تطبيقها عندما تعمل في مشروع بمفردك او من خلال فريق عمل؛ ولكن العمل مع فريق عمل يستدعي التزامًا أكبر من جميع أفراد الفريق وذلك للحفاظ على معايير عالية للكود المكتوب وكفاءته. إليك بعض النقاط الهامة عندما تكون عضوًا في الفريق:
برجاء الأخذ بالاعتبار أن هذه الممارسات قد تختلف من شخص لشخص أو من فريق لفريق لذلك يجب على الفريق الإتفاق على الطرق والممارسات التي سوف يتبعونها خلال عملهم على المشروع والتأكد من التزام كل أعضاء الفريق بهذا الاتفاق طوال الوقت، لمنع حدوث أي تعارض قد يعطل الفريق عن العمل. كما يجب أن يتضمن هذا الإتفاق تحديد طريقة دمج الكود بإستخدام git merge أو git rebase.
الفرق بين git merge وgit rebase
يوجد طريقتين اساسيتين لدمج التغييرات من فرع لاي فرع اخر، وهما git merge و git rebase. يقوم كلا الأمرين بدمج التغييرات، ولكن عند استخدام git merge يتأثر فقط الفرع الذي يتم الدمج إليه الـ main، اما الفرع المصدر feature أو الـ bug فيبقي تاريخ الـ commits كما هو ولذلك يفضله البعض لانه يحتفظ بتاريخ التغييرات دون مساس، أما git rebase فانه يقوم بضغط كل التغييرات في الفرع المصدر إلى تغيير واحد ثم يقوم بدمجه في الفرع الآخر main، فهو يقوم بإعادة تاريخ الـ commits، ويفضله البعض لأنه يسهّل عملية المراجعة.
يعتبر git merge سهل الاستخدام، غير مدمر، بمعني انه يقوم بحفظ كل التغييرات ورسائل التغيير commit messages كما هي في كلا الفرعين المدمجين ويمكنك الرجوع لأي منها في وقت، وعند وجود اي تعارضات في التغييرات بين الفرعين فانه يتم حلها فقط مره واحده عند الدمج ولا تحتاج لحلها كل مره يتم اضافه تغييرات جديده في الفرع المدمج. ولكن عادة ما ينتج عنه تاريخ تغييرات غير منظم ويزيد الامر سوءا اذا كان يتم الدمج بطريقه دورية كما أنه يتم اضافه رساله دمج commit message إضافية عند دمج اي فرعين.
,وفي حالة git rebase فإنه ينتج عنه تاريخ تغييرات منظم ونظيف للفرع بحيث يستطيع اي شخص ان يقوم بتتبع التغييرات بدقه وبالترتيب الصحيح لها ولا يقوم بإضافه رساله دمج إضافية عند الدمج، بل يقوم بترتيب الرسائل الموجودة سلفًا في الفرعين المدمجين بحيث تظهران كخط واحد من التغيررات المرتبة. لكن فكرة إعادة كتابة تاريخ التغييرات وخسارة رسائل التغيير الاصلية (commit messages)للفرع المدمج قد تتسب في مشاكل جمة لاعضاء الفريق في حال تمتالفرع معهم، ففهي هذه الحالة قمت انت بتغيير تاريخ التغييرات علي هذا الفرع بحيث اصبح مختلفا عما لديهم.
استخدم git merge:
استخدم git rebase:
إذا لم تكن تستخدم Git من قبل برجاء إبدأ بإستخدامه من الآن، سوف تشكر نفسك فيما بعد؛ اما إذا كنت مستخدم لـ Git برجاء الالتزام بأفضل الممارسات الممكنة، سوف يشكرك زملائك في العمل بكل تأكيد.
كتب هذا المقال بواسطة الدفعة الثانية في Lintschool، ثم نسقها وجمعها أنس بشندي.
لا يفوتك أيضابرمجةالسابق