نظام إدارة التوزيعات git... لأن المشروعات الكبيرة تحتاج المشاركة!

قصةٌ قصيرةٌ حزينة!

استيقظ X من النوم نشيطاً، وغادر منزله متجهاً نحو العمل دون تناول الفطور، فحماسه لم يمهله الوقت الكافي لتناول الطعام، وفي خلده تدور أفكار كثيرة عن مشروعه البرمجي الذي يعمل عليه بصحبه زميله Y.

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

تسعُ ساعاتٍ مرّت بسرعة؛ شعر بعدها صديقنا بالإرهاق، فترك حاسبه ليرفع الملف الجديد الذي يحوي مئات الأسطر الجديدة إلى المخدم وذهب ليستنشق الهواء في الخارج. عاد بعد ذلك إلى حاسوبه وفتح الملف ليكمل تعديلاته لكنه لم يجد أياً منها! فقد قام y برفع تعديلاته هو الآخر وذهب مجهود الساعات الطويلة سدًى!

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

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

لتجاوز هذه المشكلات؛ يمكنُ استخدام برنامجٍ لتنقيح التعديلات الجماعية في الفريق، وباختصار؛ يسمحُ نظامُ إدارة التوزيعات للمستخدم بإجراء التعديلات على الكود مع الاحتفاظ بنسخٍ قديمة من الكود يمكن العودة إليها في وقت لاحق في حال حدوث خطأ ما، ويتيح للفريق العملَ على نحوٍ جماعي على ملف واحد دون خشية حدوث تداخلات في أثناء إجراء التعديلات.

بُنيت أحد أشهر هذه الأنظمة من قِبل «لينوس تروفالدس» - ومن معه من المطورين- لحلّ المشكلات المتعلقة بالعمل الجماعي في أثناء العمل على نواة Linux، ليصبح لاحقاً النظام المستخدم لإدارة التعديلات في مشروعات رائدة من أمثال Android و Facebook و Twitter وغيرها؛ هذا النظام هو نظام Git.

نظام Git؛ أداةٌ تتيح لك أن تبقى منظماً؛ أن تكون مبدعاً في الوقت ذاته عندما يحين الوقت للبدء بمغامرةً ما.

مبدأ عمل Git هو أن التعديلات لا تُجرى منفردة؛ إنما يُجري المطور عددًا من التعديلات لإضافة ميزة جديدة أو إزالة ثغرة ما، وبذلك يمكن أن تُجمع هذه التعديلات ضمن حزمة وترفق بشرحٍ مبسطٍ يسهّل عملية المراجعة فيما بعد، ومن ثمّ الاحتفاظ بهذه الحزم في المخزَن البرمجي Repository (وهو المكان المخصص لحفظ المشروع مع سجل التعديلات الخاصة به)، وبذلك يمكن تمييز ثلاثة أماكن في أثناء عملية الاحتفاظ بالتعديلات وهي:

- المجلّد الفعلي الذي يحتوي التعديلات.

- منطقة وسيطة يُحتفظ ضمنها بالتعديلات الحالية في حزمة لها اسم معين.

- المستودع الذي يضم مجموعةَ الحزم.

يمكن للمطور باستخدام Git أن يُجري التعديلات حتى ولو لم يكن متصلاً بالإنترنت، وعندما يحدث الاتصال، تُرفع التعديلات إلى المخدم؛ حيث توجد الملفات الأصلية للمشروع. هذا يعني أن نسخةً من المشروع موجودةٌ على الأقل لدى كلّ مطور؛ مما يقلل فرصَ الخطر وضياع البيانات، وتساعد Git في عملية مزامنة التعديلات وحل التداخلات -إن وجدت- وتقدّم إمكانيةَ توضيح التعديلات بين النسخ المختلفة من المشروع والتفاصيل المتعلقة بالتعديلات (صاحب التعديل أو وقت التعديل أو الوصف المرافق له).

وتقدم Git خدمةَ إنشاء فروع متعددة Branches في أثناء عملية التطوير؛ مما يتيح لكل مطوّرٍ -أو فريقٍ من المطورين- القدرة على العمل لإدراج ميزة معينة دون انتظار حل المشاكل الناتجة عن تطوير المزايا الأخرى.

كُتبت Git بلغة C؛ ممَّا يمنحها فرقاً في سرعة الأداء عند مقارنتها مع نظائرها المكتوبة بلغات أخرى من أمثال SVN، بالإضافة إلى أن معظم التعديلات تُجرى محلياً؛ أي على جهاز المطور وليس على المخدم؛ مما يجعل Git تتفوق في أغلب الأحيان على نظائرها من ناحية السرعة.

تخسر Git في سباق السرعة أمام SVN عند مقارنة عمليةِ تحميل المخزَن البرمجي من المخدم للمرة الأولى فقط (باستخدام الأمر git clone)؛ وذلك لأن Git تُحمّل السجل بالكامل عوضاً عن تحميل النسخة الأخيرة فحسب؛ ولكن يمكن التغاضي عن فرق السرعة هنا؛ إذ تُنفّذ هذه العملية مرةً واحدةً فقط.

تفاصيل العمل (بإيجاز) :

- بدايةً يجب على المستخدم أن يٌنشئ مخزَنًا برمجيًا محليًا ليحفظ التغييرات بداخله؛ إذ إن المخزن هو عبارة عن مجلّد عادي تراقب أداة Git التغييرات التي تجري داخله، و يُنشأ هذا المخزن إما بوصفه مخزنًا جديدًا عن طريق الأمر git init، وإمّا من مخزن موجود مسبقاً على مخدم عن طريق الأمر git clone.

- الملفات الجديدة التي ستضاف إلى هذا المجلد ستكون خارجَ نطاق المراقبة لاحقاً، ولا يمكن لـgit أن تتبعها، ولتتبع التغيّرات الحاصلة على ملفٍّ ما؛ يجب إضافة هذا الملف إلى المنصة (staging area) عن طريق الأمر git add (و يمكن إضافة جميع الملفات الموجودة ضمن المخزن إلى المنصة عن طريق الأمر git add --all). تعني إضافةُ الملف إلى المنصة أنه أصبح الآن مستعداً لحفظ التغيّرات التي ستُجرى عليه ضمن الحزمة القادمة.

-بعد أن تصبح جميع الملفات التي نريد الاحتفاظ بالتغيّرات الحاصلة عليها موجودة على المنصة؛ يمكن الآن الاحتفاظ بالتغيّرات ضمن حزمة عن طريق الأمر git commit –m "Package name".

- يمكن رفع التعديلات لاحقاً إلى المخزن الموجود على المخدم عن طريق الأمر git push، أو الحصول على التعديلات التي قام بها الزملاء عن طريق الأمر git pull.

(يمكن تشبيه الأمر برمّته على أنه استوديو تصوير، إذ يٌجهّز الأمر add الملفات ويضيفها إلى منصة التصوير دون تصويرها فعلياً، وفي هذه اللحظة؛ يمكن إجراء المزيد من التعديلات قبل التقاط الصورة فعلياً، وأما الأمر commit؛ فإنه يلتقط الصورة ويعطيها اسماً، والأمر push يرسل مجموعة الحزم (ألبوم الصور) إلى الزبون (المخزن الموجود على المخدم) ).

- يمكن الاستعلام عن الحالة الحالية للملفات (قيد التعديل أو على المنصة أو غير مراقبة) في أي وقت عن طريق الأمر git status، ويمكن ملاحظة الاختلافات بين الحزم عن طريق الأمر git diff، أو حتى الحصول على تقرير كامل للتعديلات على طريق الأمر git log.

- في حال حصول تعارضات؛ لا يمكن لـgit التعامل معها يف أثناء عملية التطوير؛ لكنّها توفر المساعدة لحل هذه التعارضات عن طريق تعليقات تضيفها git إلى موقع التعارض.

- يمكن إنشاءُ فروع جديدة تضمن التوازي في العمل -كتطوير مزايا جديدة دون الإخلال بالنسخة الحالية- على المخدم أو حتى ضمن المستودع المحلي، ويمكن التبديل بين الفروع عن طريق الأمر git checkout، وبذلك يكون المطور قادراً على إجراء التعديلات ضمن الفروع على نحوٍ منفصل تماماً؛ ليدمج التعديلات في النهاية عن طريق الأمر git merge غالبا دون أي عناء يذكر.

git add thisArticle

git commit –m "Create git article"

git push

----------------------

المصادر:

Git Folien ،Tutoriumsblätter (besonders 1-te ، 4-te) ،Programmieren II (2015 SS) ،Leibniz Universität Hannover

هنا