تحظى Git بشعبية لا تصدق وتدعم في كل مكان تقريبًا. نظرًا لكونه عمليًا نظام التحكم في الإصدار الافتراضي ، فإنه يطرح السؤال ، ما هي البدائل؟ هل يستحقون التفكير ، وكيف يختلفون؟
لاحظ أن هذه المقالة تناقش بدائل
gitكبرنامج للتحكم بالمصادر. إذا كنت تبحث ببساطة عن بدائل لخدمة مستضافة مثل Github ، فيمكنك قراءة دليلنا لحلول Git المستضافة بدلاً من ذلك.
سلبيات Git
لفهم قيود Git بشكل أفضل ، يجب أن نبدأ أولاً بما يفعله بشكل صحيح.
يستخدم Git نموذج التحكم في المصدر الموزع ؛ المستودع المحلي لكل مستخدم غير متصل حقًا بأي خادم مركزي. يمكن لهذا المستخدم عدم الاتصال بالإنترنت ، وإجراء مجموعة من التغييرات ، ولن يرى أي شخص آخر هذه التغييرات حتى يتم دفعها إلى جهاز التحكم عن بُعد. هذا يعمل بشكل جيد للغاية لتطوير البرمجيات مفتوحة المصدر ؛ يعد Git أسرع في معظم الإجراءات ، حيث يمكن للمستخدمين الفرديين استنساخ مستودع وإجراء تغييرات صغيرة خاصة بهم دون الحاجة إلى القلق بشأن ما يفعله الآخرون.
يمكن دمج هذه التغييرات في المستودع الرئيسي باستخدام طلبات السحب (يقوم المستخدم بإجراء طلبات التغيير للمستودع الرئيسي لسحب الالتزامات من نسخته الخاصة من المستودع) ، والتحديثات المدفوعة من المستخدمين المصادق عليهم ، مما يوفر كل عمليات الدمج يتم حل النزاعات بشكل صحيح.
هذا النموذج منطقي جدًا لبيئة التطوير الموزعة هذه ، لكن المشكلة في Git تأتي عندما تحاول تكييفها للاستخدام في بيئة الشركة ، حيث غالبًا ما يكون لديك العديد من الأشخاص الذين يعملون على نفس البتات من الكود ، والتنسيق الصحيح هو المفتاح.
لا تفهمنا بشكل خاطئ - لا يزال الأمر رائعًا ، لا سيما عند إقرانه ببرنامج تتبع المشكلات الخارجية وخطوط أنابيب CI / CD ، وهو أمر تؤديه خدمات مثل GitLab و BitBucket بشكل جيد. لكن Git لم يتم إنشاؤه بالضبط ليكون تحكمًا في مصادر الشركة ، حيث سيكون لديك دائمًا خادم مركزي يعمل كمستودع رئيسي. يتطلب استخدامًا مناسبًا للغاية (وغالبًا أدوات خارجية) ليكون فعالًا للفرق الرشيقة التي تدفع الكثير من التغييرات في التعليمات البرمجية.
مع Git ، يخزن كل عميل نسخة كاملة من سجل التغيير الخاص بالمشروع. في كل مرة تقوم فيها بالتزام في Git ، يقوم بتخزين التغييرات التي تم إجراؤها محليًا على نظامك. هذا يجعل العمل مع Git سريعًا جدًا ، نظرًا لأنك تحتاج فقط إلى الاستعلام عن محرك أقراص ثابت وليس خادم مركزي. كما يتيح لك العمل دون اتصال بسهولة أكبر. ولكن مع المشاريع الكبيرة ذات التاريخ الطويل للتغيير ، يمكن أن يؤدي ذلك أيضًا إلى احتلال مجلد
gitمساحة غير معقولة.
أيضًا ، إذا كان لديك عدة مشاريع ، فربما لا تريد شفرة المصدر لكل شيء مرئي لكل مطور.في Git ، عادةً ما يتم حل هذه المشكلة من خلال وجود مستودعات منفصلة لكل مشروع ، والتي تعمل بشكل جيد ، ولكنها ليست مثالية إذا كنت بحاجة إلى دمجها معًا في قطعة واحدة متماسكة. باستخدام التحكم المركزي في الإصدار ، يمكنك منح حق الوصول إلى مجلدات محددة فقط.
لذا ، على الرغم من أن Git قد لا يكون الخيار الخاطئ لعملك ، خاصة إذا تم تنفيذه بشكل صحيح ، إلا أن هناك خيارات أخرى للتحكم بالمصادر مصممة خصيصًا لسير عمل الشركة ، وقد يكون من المفيد النظر إلى المنافسة.
البديل الأساسي: التحكم المركزي في الإصدار
الاختلاف الأكثر شيوعًا بين Git والبدائل هو الانفصال عن التحكم في الإصدار اللامركزي لصالح خادم مركزي موثوق. Apache Subversion و Team Foundation Version Control هما نظامان رئيسيان للتحكم في الإصدار يتبع هذا التنسيق.
للمقارنة ، في نظام DVC ، يمتلك كل مستخدم مستودعًا محليًا يلتزم بتغييراته الخاصة به.عندما يكونون مستعدين لإرسال التحديثات إلى الخادم الرئيسي ، فمن الممكن للمستخدمين الآخرين أن يكون لديهم إصدارات مختلفة من نفس الملف الذي تعمل عليه. يُعرف هذا باسم تعارض الدمج ، وهو مشكلة شائعة جدًا (على الرغم من إمكانية حلها بسهولة) مع Git.
في التحكم المركزي في الإصدار (CVC) مثل Apache Subversion ، يوجد مستودع خادم واحد والعديد من العملاء المتصلين به مباشرة. إذا قمت بإجراء تغيير على أحد الملفات ، فسيتم تحديث هذا الملف على أجهزة المستخدمين الآخرين كلما قاموا بالتحديث. يتم تنفيذ الالتزامات مباشرة إلى الخادم الرئيسي.
لمنع تعارضات الدمج ، تستخدم معظم أنظمة التحقق من البطاقة (CVC) الأقفال. إذا كان المستخدم "أ" يرغب في العمل على ملف ، ولا يريد أي شخص آخر العبث به ، فيمكنه قفل الملف حتى يتم الانتهاء منه ، مما يمنع المستخدمين الآخرين من فعل الشيء نفسه. هذا ليس مطلوبًا في التخريب ، ولا يزال من الممكن أن تحدث تعارضات الدمج ، لكنها ليست مجرد حادث.
يتم تخفيف المشكلة في الغالب من خلال النسخ المتفرعة والمحلية ، والتي تسمح لعدة مستخدمين بالعمل على إصداراتهم الخاصة لفترات طويلة من الوقت قبل دمج التغييرات.
ميزة أخرى رائعة للتحكم المركزي في الإصدار هي إدارة الأذونات ؛ بدلاً من منح حق الوصول إلى المستودع بالكامل ، يجعل رمز التحقق من البطاقة (CVC) من السهل فصل الوصول إلى مجلدات محددة. يعمل Team Foundation Version Control بنفس الطريقة التي يعمل بها Subversion ، مما يسمح بتفويض الأذونات المحبب وصولاً إلى مستوى الملف.
كل هذه الميزات تجعل التحكم في الإصدار المركزي بديلاً قابلاً للتطبيق لـ DVC. بعد كل شيء ، تستضيف Google جميع التعليمات البرمجية الخاصة بها في نظام مركزي واحد ضخم ، أكبر بكثير من أي نظام موزع يمكن أن يتعامل معه. من المؤكد أن قاعدة رموز Windows عبارة عن مستودع Git بسعة 300 جيجابايت ، ولكن هذا باستخدام المكون الإضافي لنظام الملفات الافتراضي من Git ، والذي يسمح للمستخدمين بتنزيل الملفات التي يحتاجون إليها فقط ، ولا شيء أكثر من ذلك.
أحد الجوانب السلبية للتخريب هو أنه غالبًا ما يحتاج إلى الكثير من النسخ والتنزيل ، مما قد يجعله أبطأ بكثير من نموذج Git المحلي فقط.
بدائل أخرى
بينما ركزنا على أنظمة التحكم في الإصدار المركزي التي يمكن أن تحل محل Git ، هناك أنظمة أخرى للتحكم في الإصدار الموزع يمكنك استخدامها ، وأبرزها Mercurial.
Mercurial أسهل قليلاً في الاستخدام من Git ، وكلاهما متشابه من حيث الأداء ، لكنهما متشابهان جدًا بشكل عام. حقًا ، لا يوجد سبب كبير لاختيار Mercurial بدلاً من Git ، بخلاف التفضيل الشخصي ، والذي ربما لا ينبغي أن يملي قرارات الشركة.
Mercurial اعتاد أن يكون خيارًا في BitBucket ، لكنهم أسقطوا الدعم له مؤخرًا ، والسبب الرئيسي هو أن Git أصبح أكثر شيوعًا ودعمًا على نطاق واسع. إنه عمليًا نظام التحكم في الإصدار الافتراضي ، وما لم يغير البديل النموذج جذريًا (مثل رمز التحقق من البطاقة) ، فلا يستحق التفكير فيه.
