مدخل إلى أنظمة إدارة النسخ VCS

ما هو نظام التحكّم في النسخ Git، ولماذا حرّي بك أن توليه اهتماما؟

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

أنظمة إدارة إصدارات المصدر المحلية

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

إحدى أدوات VCS الأكثر شعبية كان نظاما تدعى rcs والتي لا تزال تُوّزع مع العديد من حواسيب اليوم. حتى نظام OS X المشهور يحوي أمر rcs عند تنصيبك لأدوات المطور، تعمل هذه الأداة أساسا بحفظ مجموع الرقع (أي الاختلافات الحاصلة بين الملفات) بين كل عملية تغيير واحدة ومثيلتها في هيئة خاصة على القرص الصلب، يمكنها بهذا إعادة إنشاء أي ملف بنفس الهيئة التي كان عليها في نقطة ما من الزمن عن طريق دمج الرقع.

أنظمة إدارة إصدارات المصدر المركزية

المشكل الكبير التالي الذي واجه المستخدمين هو حاجتهم إلى التعاون مع مُبرمجين آخرين على أنظمة تشغيل أخرى. ولحل هذا المُشكل تم تطوير أنظمة لإدارة إصدارات المصدر مركزية (CVCSs). تستخدم هذه الأنظمة، مثل كل من CVS ،Subversion أو Perforce خادوما واحدا يحتوي كل الملفات التي نقوم بإدارة إصداراتها، إضافة إلى مجموعة من العملاء الذين يقومون باسترجاع الملفات من هذا الخادوم المركزي. ظلت هذه الأنظمة لسنوات عديدة المعيار القياسي لأنظمة إدارة إصدارات المصدر.

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

أنظمة إدارة الإصدارات الموزعة

ولمثل هذه الأوضاع ظهرت أنظمة إدارة الإصدارات المُوزعة (DVCSs). في مثل هذه الأنظمة كـ Git ،Mercurial ،Bazaar أو Darcs فإن ما يقوم به المستخدمون ليس مُجرد التحقق من آخر إصدار للملفات، لكن يقومون بإخذ نسخ كاملة عن المستودعات التي يعملون عليها. وعليه، فإن تعرض الخادوم لأي خلل فإنه يُمكن مواصلة العمل عبر نسخ المستودع الموجود على أي من أجهزة المستخدمين بحكم أن أي عملية تحقق يقوم بها المستخدم هي عبارة عن عملية نسخ احتياطي كامل لكامل بيانات المشروع (انظر الصورة التالية).

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

ترجمة -وبتصرف- لـ About Version Control  من كتاب Pro Git لصاحبه Scott Chacon.