التحكم في الإصدارات الموزعة

الموسوعة الحرة
عملية تهيئة مستودع Git. يُعد Git أحد أكثر برامج التحكم في الإصدارات الموزعة استخدامًا.

في مجال تطوير البرمجيات ، يُعدّ نظام التحكم في الإصدارات الموزع (المعروف أيضًا باسم نظام التحكم في المراجعات الموزع ) أحد أشكال التحكم في الإصدارات ، حيث يتم نسخ قاعدة التعليمات البرمجية بالكامل ، بما في ذلك تاريخها الكامل، على جهاز كل مطور. [ 1 ] بالمقارنة مع نظام التحكم في الإصدارات المركزي ، يُمكّن هذا النظام من إدارة التفرعات والدمج تلقائيًا ، ويُسرّع معظم العمليات (باستثناء الدفع والجلب)، ويُحسّن إمكانية العمل دون اتصال بالإنترنت، ولا يعتمد على موقع واحد للنسخ الاحتياطية. [ 1 ] [ 2 ] [ 3 ] يُعدّ Git ، نظام التحكم في الإصدارات الأكثر شيوعًا في العالم، [ 4 ] نظامًا للتحكم في الإصدارات الموزع.

التوزيع مقابل المركزية

تستخدم أنظمة التحكم في الإصدارات الموزعة (DVCS) أسلوب الند للند للتحكم في الإصدارات ، على عكس أسلوب العميل والخادم في الأنظمة المركزية. يعمل التحكم الموزع في الإصدارات على مزامنة المستودعات عن طريق نقل التصحيحات من ند إلى ند. لا توجد نسخة مركزية واحدة لقاعدة التعليمات البرمجية؛ بل يمتلك كل مستخدم نسخة عمل وسجل التغييرات الكامل.

تشمل مزايا أنظمة التحكم الموزعة (مقارنة بالأنظمة المركزية) ما يلي:

  • يُمكّن المستخدمين من العمل بكفاءة حتى في حال عدم اتصالهم بالشبكة.
  • تُعدّ العمليات الشائعة (مثل عمليات الحفظ، وعرض سجل التغييرات، والتراجع عنها) أسرع في أنظمة التحكم الموزعة للإصدارات (DVCS)، لعدم الحاجة إلى التواصل مع خادم مركزي. [ 5 ] مع أنظمة التحكم الموزعة للإصدارات، يصبح التواصل ضروريًا فقط عند مشاركة التغييرات بين النظراء الآخرين.
  • يسمح بالعمل الخاص، بحيث يمكن للمستخدمين استخدام تغييراتهم حتى في المسودات الأولية التي لا يرغبون في نشرها.
  • تعمل النسخ العاملة كنسخ احتياطية عن بعد، مما يجنب الاعتماد على جهاز مادي واحد كنقطة فشل وحيدة. [ 5 ]
  • يسمح باستخدام نماذج تطوير متنوعة، مثل استخدام فروع التطوير أو نموذج القائد/الملازم. [ 6 ]
  • يسمح بالتحكم المركزي في "الإصدار النهائي" للمشروع
  • في مشاريع البرمجيات الحرة والمفتوحة المصدر، من الأسهل بكثير إنشاء نسخة فرعية من مشروع متوقف بسبب صراعات القيادة أو الخلافات التصميمية.

تشمل عيوب أنظمة التحكم الموزعة (مقارنة بالأنظمة المركزية) ما يلي:

  • Initial checkout of a repository is slower as compared to checkout in a centralized version control system, because all branches and revision history are copied to the local machine by default.
  • The lack of locking mechanisms that is part of most centralized VCS and still plays an important role when it comes to non-mergeable binary files such as graphic assets or too complex single file binary or XML packages (e.g. office documents, PowerBI files, SQL Server Data Tools BI packages, etc.).
  • Additional storage required for every user to have a complete copy of the complete codebase history.[7]
  • Increased exposure of the code base since every participant has a locally vulnerable copy.

Some originally centralized systems now offer some distributed features. Team Foundation Server and Visual Studio Team Services now host centralized and distributed version control repositories via hosting Git.

Similarly, some distributed systems now offer features that mitigate the issues of checkout times and storage costs, such as the Virtual File System for Git developed by Microsoft to work with very large codebases,[8] which exposes a virtual file system that downloads files to local storage only as they are needed.

Work model

A distributed model is generally better suited for large projects with partly independent developers, such as the Linux Kernel. It allows developers to work in independent branches and apply changes that can later be committed, audited and merged (or rejected)[9] by others. This model allows for better flexibility and permits for the creation and adaptation of custom source code branches (forks) whose purpose might differ from the original project. In addition, it permits developers to locally clone an existing code repository and work on such from a local environment where changes are tracked and committed to the local repository[10] allowing for better tracking of changes before being committed to the master branch of the repository. Such an approach enables developers to work in local and disconnected branches, making it more convenient for larger distributed teams.

Central and branch repositories

In a truly distributed project, such as Linux, every contributor maintains their own version of the project, with different contributors hosting their own respective versions and pulling in changes from other users as needed, resulting in a general consensus emerging from multiple different nodes. This also makes the process of "forking" easy, as all that is required is one contributor stop accepting pull requests from other contributors and letting the codebases gradually grow apart.

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

غالباً ما تختار المؤسسات التي تستخدم هذا النمط المركزي استضافة المستودع المركزي على خدمة خارجية مثل GitHub ، والتي لا توفر فقط وقت تشغيل أكثر موثوقية من المستودعات المستضافة ذاتياً، ولكنها يمكن أن تضيف أيضاً ميزات مركزية مثل متتبعات المشكلات والتكامل المستمر .

طلبات السحب

تُقدَّم المساهمات في مستودع شفرة المصدر الذي يستخدم نظام تحكم في الإصدارات موزّعًا عادةً عن طريق طلب سحب ، يُعرف أيضًا بطلب دمج . [ 11 ] يطلب المساهم من مسؤول المشروع سحب تغيير شفرة المصدر، ومن هنا جاءت تسمية "طلب السحب". ويتعين على المسؤول دمج طلب السحب إذا ما أراد أن تصبح المساهمة جزءًا من قاعدة المصدر. [ 12 ]

يُنشئ المطور طلب سحب لإبلاغ القائمين على الصيانة بالتغيير الجديد؛ ويرتبط كل طلب سحب بسلسلة تعليقات. يتيح ذلك مناقشة مركزة لتغييرات الكود . طلبات السحب المُقدمة مرئية لأي شخص لديه صلاحية الوصول إلى المستودع. يمكن للقائمين على الصيانة قبول طلب السحب أو رفضه. [ 13 ]

بعد مراجعة طلب السحب والموافقة عليه، يُدمج في المستودع. وبحسب سير العمل المُعتمد، قد يلزم اختبار الكود قبل إدراجه في الإصدار الرسمي. لذا، تحتوي بعض المشاريع على فرع خاص لدمج طلبات السحب غير المختبرة. [ 12 ] [ 14 ] بينما تُشغّل مشاريع أخرى مجموعة اختبارات آلية على كل طلب سحب، باستخدام أداة التكامل المستمر ، ويتحقق المراجع من أن أي كود جديد يتمتع بتغطية اختبارية مناسبة.

تاريخ

تضمنت أنظمة التحكم في الإصدارات الموزعة مفتوحة المصدر الأولى Arch و Monotone و Darcs . ومع ذلك، لم تحظَ هذه الأنظمة بشعبية كبيرة حتى إصدار Git و Mercurial .

استُخدم برنامج BitKeeper في تطوير نواة لينكس من عام 2002 إلى عام 2005. [ 15 ] وقد حفّز قرار الشركة المصنّعة لبرنامج BitKeeper بإلغاء الترخيص المجاني الذي كان لينوس تورفالدز وبعض مطوري نواة لينكس الآخرين قد استفادوا منه سابقًا، تطويرَ Git ، وهو الآن نظام التحكم في الإصدارات الأكثر شيوعًا في العالم . [ 4 ]

انظر أيضاً

مراجع

  1. 1 2 تشاكون، سكوت؛ ستراوب، بن (2014). "حول التحكم في الإصدارات" . برو جيت (  الطبعة الثانية). أبريس. الفصل 1.1 . تم الاطلاع عليه في 4 يونيو 2019 .
  2. ↑ سبولسكي، جويل (17 مارس 2010). "التحكم الموزع في الإصدارات باقٍ لا محالة" . جويل حول البرمجيات . تم الاطلاع عليه في 4 يونيو 2019 .
  3. ↑ "مقدمة في التحكم الموزع في الإصدارات (مصورة)" . www.betterexplained.com . تم الاطلاع عليه بتاريخ 7 يناير 2018 .
  4. 1 2 "شعبية أنظمة التحكم في الإصدارات في عام 2016" . www.rhodecode.com . تم الاطلاع عليه بتاريخ 7 يناير 2018 .
  5. 1 2 أوسوليفان، برايان. "التحكم في المراجعة الموزعة باستخدام ميركوريال" . تم الاسترجاع في 13 يوليو 2007 .
  6. ↑ تشاكون، سكوت؛ ستراوب، بن (2014). "سير العمل الموزع" . برو جيت ( الطبعة الثانية). أبريس. الفصل 5.1. 
  7. ↑ "ما هو نظام التحكم في الإصدارات: النظام المركزي مقابل نظام التحكم في الإصدارات الموزعة" . www.atlassian.com . 14 فبراير 2012. تم الاطلاع عليه بتاريخ 7 يناير 2018 .
  8. ↑ جوناثان ألين (2017-02-08). "كيف حلت مايكروسوفت مشكلة جيت مع المستودعات الكبيرة" . تم الاطلاع عليه بتاريخ 2019-08-06 .
  9. ↑ "تقديم التصحيحات: الدليل الأساسي لإدخال التعليمات البرمجية الخاصة بك في النواة — وثائق نواة لينكس" . www.kernel.org . تاريخ الاطلاع: 22 نوفمبر 2024 .
  10. ↑ "Git - تحديد المراجعة" . git-scm.com . تم الاطلاع عليه بتاريخ 22-11-2024 .
  11. ^ سيجبرانديج ، سيتس (29 سبتمبر 2014). "تدفق جيتلاب" . جيتلاب . تم الاسترجاع في 4 أغسطس 2018 .
  12. 1 2 جونسون، مارك (8 نوفمبر 2013). "ما هو طلب السحب؟" . Oaawatch . تم الاسترجاع في 27 مارس 2016 .
  13. ↑ "استخدام طلبات السحب" . جيت هاب . تم الاطلاع عليه بتاريخ 27 مارس 2016 .
  14. ↑ "تقديم طلب سحب" . أتلاسيان . تم الاطلاع عليه بتاريخ 27 مارس 2016 .
  15. 1 2 ماكاليستر، نيل. "خطأ لينوس تورفالدز في BitKeeper" . إنفوورلد . تم الاسترجاع في 19 مارس 2017 .