الفرق بين GIT و CVS

https://stackoverflow.com/questions/802573

03-07-2019
|

سؤال

ما هو الفرق بين أنظمة التحكم في إصدار GIT و CVS؟

لقد كنت بسعادة استخدام CVS لأكثر من 10 سنوات ، والآن قيل لي إن Git أفضل بكثير. هل يمكن لأي شخص أن يوضح ما هو الفرق بين الاثنين ، ولماذا يكون أحدهما أفضل من الآخر؟

المحلول

الفرق الرئيسي هو أن (كما قيل بالفعل في ردود أخرى) CVS هي نظام التحكم في الإصدار المركزي (القديم) ، بينما يتم توزيع GIT.

ولكن حتى إذا كنت تستخدم التحكم في الإصدار لمطور واحد ، على جهاز واحد (حساب واحد) ، فهناك بعض الاختلافات بين GIT و CVS:

إعداد مستودع. مستودع متاجر GIT في .git دليل في أعلى دليل لمشروعك ؛ تتطلب CVS إعداد CVSROOT ، وهو المكان المركزي لتخزين معلومات التحكم في الإصدار لمشاريع مختلفة (الوحدات النمطية). تتمثل نتيجة هذا التصميم للمستخدم في أن استيراد المصادر الموجودة إلى التحكم في الإصدار أمر بسيط مثل "GIT init && git add. && git comming" في git ، في حين أنه أكثر تعقيدا في السير الذاتية.
العمليات الذرية. نظرًا لأن CVS في البداية كانت مجموعة من البرامج النصية حول نظام التحكم في إصدار RCS لكل ملف ، فإن الالتزامات (والعمليات الأخرى) ليست ذرية في CVS ؛ إذا تمت مقاطعة عملية على المستودع في الوسط ، فيمكن ترك المستودع في حالة غير متناسقة. في GIT جميع العمليات ذرية: إما أنها تنجح ككل ، أو تفشل دون أي تغييرات.
تغييرات. التغييرات في CVS لكل ملف ، في حين أن التغييرات (الالتزام) في GIT تشير دائمًا إلى المشروع بأكمله. هذا مهم جدا تحول النموذج. واحدة من عواقب ذلك هو أنه من السهل للغاية في GIT العودة (إنشاء تغيير يتكبد) أو التراجع كامل يتغيرون؛ والنتيجة الأخرى هي أنه في CVS من السهل القيام بنقاط جزئية ، في حين أنها حاليًا بجوار مستحيل في GIT. حقيقة أن التغييرات لكل ملف ، أدت تجميعها معًا إلى اختراع تنسيق GNU Changelog لالتزام رسائل في CVS ؛ يستخدم مستخدمو GIT (ويتوقع بعض أدوات GIT) اتفاقية مختلفة ، مع وصف خط واحد (تلخيص) ، يليه خط فارغ ، يليه وصف أكثر تفصيلاً للتغييرات.
تسمية المراجعات / أرقام الإصدار. هناك مشكلة أخرى مرتبطة بحقيقة أن التغييرات في CVS لكل ملفات: أرقام الإصدار (كما ترون أحيانًا في توسيع الكلمات الرئيسية, ، انظر أدناه) مثل 1.4 يعكس عدد الوقت الذي تم تغييره. في GIT ، كل إصدار من المشروع ككل (كل التزام) له اسمه الفريد الذي قدمه SHA-1 ID ؛ عادةً ما تكون الأحرف الأولى من 7 إلى 8 كافية لتحديد الالتزام (لا يمكنك استخدام مخطط ترقيم بسيط للإصدارات في نظام التحكم في الإصدار الموزع-يتطلب سلطة الترقيم المركزية). في CVS للحصول على رقم الإصدار أو الاسم الرمزي الذي يشير إلى حالة المشروع ككل تستخدمه العلامات; ؛ وينطبق الشيء نفسه في git إذا كنت تريد استخدام اسم مثل "v1.5.6-rc2" للحصول على بعض إصدار من المشروع ... ولكن العلامات في git أسهل بكثير في الاستخدام.
سهلة التفرع. الفروع في CVS في رأيي معقدة للغاية ، ويصعب التعامل معها. يجب عليك وضع علامة على الفروع للحصول على اسم لفرع مستودع كامل (وحتى قد يفشل في بعض الحالات ، إذا كنت أتذكر بشكل صحيح ، بسبب معالجة لكل ملف). أضف إلى ذلك حقيقة أن السير الذاتية لا تملك دمج تتبع, ، لذلك عليك إما أن تتذكر ، أو تضع علامة في دمج ونقاط المتفرعة يدويًا ، وتزويد المعلومات الصحيحة يدويًا بـ "تحديث CVS -J" لدمج الفروع ، ويجعل المتفرعة غير ضرورية. في GIT إنشاء ودمج الفروع أمر سهل للغاية ؛ يتذكر GIT جميع المعلومات المطلوبة في حد ذاتها (لذا فإن دمج الفرع سهل مثل "دمج git اسم الفرع") ... كان عليها ، لأن التطوير الموزع يؤدي بشكل طبيعي إلى فروع متعددة.

هذا يعني أنك قادر على استخدامه فروع الموضوع, ، أي تطوير ميزة منفصلة في خطوات متعددة في فرع ميزة منفصلة.
إعادة تسمية (ونسخ) تتبع. لا يتم دعم إعادة تسمية الملفات في CVS ، وقد يؤدي إعادة تسمية اليدوي إلى كسر التاريخ إلى قسمين ، أو يؤدي إلى تاريخ غير صالح حيث لا يمكنك استرداد حالة المشروع بشكل صحيح قبل إعادة تسمية. يستخدم GIT اكتشاف إعادة تسمية الإرشادات ، استنادًا إلى تشابه المحتويات واسم الملف (يعمل هذا الحل بشكل جيد في الممارسة). يمكنك أيضًا طلب اكتشاف نسخ الملفات. هذا يعني ذاك:
- عند فحص الالتزام المحدد ، ستحصل على معلومات تم إعادة تسمية بعض الملفات ،
- يندمج الدمج بشكل صحيح في الاعتبار (على سبيل المثال ، إذا تم إعادة تسمية الملف فقط في فرع واحد)
- "Git Lay" ، ما يعادل (أفضل) من "CVS insate" ، وهي أداة لإظهار تاريخ محتويات الملفات ، يمكنها اتباع حركة التعليمات البرمجية أيضًا عبر إعادة تسمية
الملفات الثنائية. تحتوي CVS على دعم محدود للغاية للملفات الثنائية (EG Images) ، مما يتطلب من المستخدمين تحديد الملفات الثنائية بشكل صريح عند الإضافة (أو لاحقًا باستخدام "CVS Admin" ملف ثنائي عبر تحويل نهاية الخط وتوسع الكلمات الرئيسية. يكتشف GIT تلقائيًا ملفًا ثنائيًا بناءً على المحتويات بنفس الطريقة التي تقوم بها CNU Diff والأدوات الأخرى ؛ يمكنك تجاوز هذا الكشف باستخدام آلية Gitattributes. علاوة على ذلك ، فإن الملفات الثنائية آمنة مقابل عمليات التشويش غير القابلة للاسترداد بفضل الافتراضي على "Safecrlf" (وحقيقة أنه يتعين عليك طلب تحويل نهاية الخط ، على الرغم من أن هذا قد يتم تشغيله افتراضيًا اعتمادًا على التوزيع) ، وهذه الكلمة الرئيسية (المحدودة) التوسع هو "اختيار" صارم في GIT.
توسيع الكلمات الرئيسية. تقدم GIT مجموعة محدودة للغاية من الكلمات الرئيسية مقارنة بالسيرة الذاتية (افتراضيًا). هذا بسبب وقائعتين: التغييرات في GIT هي لكل مستودع وليس لكل ملف ، وتجنب GIT تعديل الملفات التي لم تتغير عند التحول إلى فرع آخر أو إعادة الترجيح إلى نقطة أخرى في التاريخ. إذا كنت ترغب في تضمين رقم المراجعة باستخدام GIT ، فيجب عليك القيام بذلك باستخدام نظام الإنشاء الخاص بك ، على سبيل المثال مثال على النصي GIT-Version-Gen في مصادر Kernel Linux وفي مصادر GIT.
تعديل الالتزامات. لأنه في VCs الموزعة مثل ACT GIT من نشر منفصل عن إنشاء التزام ، يمكن للمرء أن يتغير (تحرير ، إعادة كتابة) جزء غير منشور من التاريخ دون إزعاج المستخدمين الآخرين. على وجه الخصوص ، إذا لاحظت خطأ مطبعي (أو خطأ آخر) في رسالة الالتزام ، أو خطأ في الالتزام ، يمكنك ببساطة استخدام "GIT Commice -التعلم". هذا غير ممكن (على الأقل لا يخلو من الاختراق الثقيل) في CVS.
أدوات أكثر. تقدم GIT أدوات أكثر بكثير من CVS. أحد الأهم هو "git bisect"يمكن استخدام ذلك للعثور على التزام (مراجعة) قدم خطأً ؛ إذا كانت ارتكابك صغيرًا ومكتفيًا ، فيجب أن يكون سهلاً إلى حد ما لاكتشاف مكان الخطأ.

إذا كنت تعاونًا مع مطور واحد على الأقل ، فستجد أيضًا الاختلافات التالية بين GIT و CVS:

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

إذا كنت تفضل أن يكون لديك تاريخ خطي وتجنب الاندماج ، فيمكنك دائمًا استخدامها الالتزام-روق سير العمل عبر "git rebase" (و "Git Pull -Rebase") ، وهو ما يشبه CVS من حيث أنك تعيد تغيير التغييرات الخاصة بك أعلى الحالة المحدثة. لكنك دائما تلتزم أولا.
لا حاجة لمستودع مركزي مع git ليست هناك حاجة إلى الحصول على مكان مركزي واحد حيث ترتكب تغييراتك. يمكن لكل مطور أن يكون له مستودع خاص به (أو مستودعات أفضل: جهاز خاص يقوم به/هي التي يقوم بها التنمية ، والعارية العامة حيث تنشر هذا الجزء الجاهز) ، ويمكنهم سحب/جلب من بعضها البعض أزياء متماثلة. من ناحية أخرى ، من الشائع أن يكون لدى المشروع الأكبر اجتماعيا مستودع مركزي محدد/تم ترشيحه ينسحب منه الجميع (الحصول على تغييرات من).

أخيرًا ، يوفر GIT العديد من الاحتمالات عند الحاجة إلى التعاون مع عدد كبير من المطورين. فيما يلي اختلافات بين CVS في GIT لمراحل مختلفة من الاهتمام والموقف في المشروع (تحت التحكم في الإصدار باستخدام CVS أو GIT):

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

GIT يدعم هنا مجهول غير مصادق الوصول للقراءة فقط عبر كفاءة مخصصة git://بروتوكول ، أو إذا كنت وراء حظر جدار الحماية DEFAULT_GIT_PORT (9418) يمكنك استخدام HTTP العادي.

بالنسبة إلى السير الذاتية الأكثر شيوعًا (كما أفهمها) للوصول إلى القراءة فقط حساب الضيف لبروتوكول "pserver" على CVS_AUTH_PORT (2401) ، عادة ما يسمى "مجهول" ومع كلمة مرور فارغة. يتم تخزين بيانات الاعتماد افتراضيًا في $HOME/.cvspass ملف ، لذلك عليك توفيره مرة واحدة فقط ؛ ومع ذلك ، هذا جزء من الحاجز (يجب أن تعرف اسم حساب الضيف ، أو الانتباه إلى رسائل خادم CVS) والانزعاج.
مطور هامش (مساهم الأوراق). طريقة واحدة لنشر التغييرات الخاصة بك في OSS هي إرسال تصحيحات عبر البريد الإلكتروني. هذا هو الحل الأكثر شيوعًا إذا كنت (أكثر أو أقل) مطورًا عرضيًا ، أو إرسال تغيير واحد ، أو Bugfix واحد. بالمناسبة. قد يكون إرسال تصحيحات عبر لوحة المراجعة (نظام مراجعة التصحيح) أو وسيلة مماثلة ، ليس فقط عبر البريد الإلكتروني.

تقدم GIT هنا أدوات تساعد في آلية الانتشار (النشر) على حد سواء للمرسل (العميل) ، وللصياغة (Server). للأشخاص الذين يرغبون في إرسال تغييراتهم عبر البريد الإلكتروني هناك "جيت ريباس"(أو" Git Pull -Rebase ") أداة لإعادة تشغيل التغييرات الخاصة بك أعلى إصدار المنبع الحالي ، وبالتالي فإن التغييرات الخاصة بك على رأس الإصدار الحالي (جديدة) ، و" و "Git Format-Patch"لإنشاء بريد إلكتروني باستخدام رسالة الالتزام (والتأليف) ، التغيير في شكل تنسيق Diff الموحد (الموسع) (بالإضافة إلى Diffstat لسهولة المراجعة). يمكن للصيانة تحويل هذا البريد الإلكتروني مباشرة إلى التزام بالحفاظ على جميع المعلومات (بما في ذلك رسالة الالتزام) باستخدام"جيت".

لا تقدم CVS أي أدوات من هذا القبيل: يمكنك استخدام "CVS Diff" / "CVS RDIFF" لإنشاء تغييرات ، واستخدام GNU Patch لتطبيق التغييرات ، ولكن بقدر ما أعرف أنه لا توجد طريقة لأتمتة تطبيق رسالة الالتزام. كان من المفترض أن تستخدم CVS في أزياء الخادم <-> الخادم ...
أيتها الملازم. إذا كنت مشرفًا لجزء منفصل من المشروع (النظام الفرعي) ، أو إذا كان تطوير مشروعك يتبع سير عمل "شبكة الثقة" المستخدمة في تطوير kernel Linux ... أو إذا كان لديك مستودعك العام الخاص بك ، وتغييرك تريد النشر أكبر من أن ترسل عبر البريد الإلكتروني كـ سلسلة التصحيح, ، يمكنك ارسال طلب سحب إلى (الرئيسي) مشروع المشروع.

هذا هو الحل الخاص بـ وزعت أنظمة التحكم في الإصدار ، لذلك بالطبع لا تدعم CVS طريقة التعاون هذه. هناك حتى أداة تسمى "GIT request-pull" تساعد في إعداد البريد الإلكتروني لإرسالها إلى المشرف مع طلب السحب من مستودعك. بفضل "Git Bundle" ، يمكنك استخدام هذه الآلية حتى دون وجود مستودع عام ، عن طريق إرسال حزمة من التغييرات عبر البريد الإلكتروني أو SneakerNet. بعض مواقع استضافة GIT مثل جيثب احصل على دعم لإخطار أن شخصًا ما يعمل (نشر بعض الأعمال) في مشروعك (شريطة أن يستخدم/هي نفس موقع استضافة GIT) ، و PM-Eng نوع من طلب السحب.
المطور الرئيسي, ، أي شخص ما نشر مباشرة يتغير/لها (إلى مستودع رئيسي/قانوني). هذه الفئة أوسع لأنظمة التحكم في الإصدار الموزعة ، لأن وجود العديد من المطورين الذين يتمتعون بالوصول إلى الكتابة إلى المستودع المركزي ليس فقط سير العمل (يمكنك أن يكون لديك مشرف واحد يدفع التغييرات في المستودع الكنسي ، مجموعة من الملازم/المشرفين على النظام الفرعي الذي يسحب منه ، ومجموعة واسعة من مطوري الأوراق الذين يرسلون تصحيحات عبر البريد إما إلى قائمة البريدية/المشروع ، أو إلى واحد من الملازمات/الخضوع).

مع git لديك اختيار استخدام بروتوكول SSH (بروتوكول GIT ملفوف في SSH) لنشر التغييرات ، مع أدوات مثل "git shell" (للمساعدة التسمم (لإدارة الوصول دون الحاجة إلى حسابات shell منفصلة) ، و https مع WebDav ، مع مصادقة HTTP العادية.

مع CVS هناك خيار بين العرف غير مشفر (نص عادي) المزلاج بروتوكول ، أو استخدام قذيفة عن بعد (حيث يجب أن تستخدم حقًا SSH) لنشر التغييرات الخاصة بك ، والتي ل مركزية نظام التحكم في الإصدار يعني ارتكاب التغييرات الخاصة بك (إنشاء ارتباطات). حسنًا ، يمكنك أيضًا نفق بروتوكول "pserver" باستخدام SSH ، وهناك أدوات Thir Party تتم أتمتة هذا ... لكنني لا أعتقد أن هذا سهل مثل التنسيق.

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

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

HTH (امل ان يساعد)

نصائح أخرى

git هو DVCs, ، على عكس CVS كونها مركزية. سيكون الوصف البسيط: تحصل على جميع فوائد التحكم في الإصدار عندما لا تكون متصلاً بـ أي من العديد من المستودعات الممكنة ، بالإضافة إلى العمليات أسرع.

موقع GIT يشرح هذا الأفضل على الأرجح.

ميزة الحيوانات الأليفة الخاصة بي هي القدرة على القيام بالالتزامات عند عدم الاتصال بالإنترنت. والسرعة ، سرعة الحارقة الشديدة التي يحدث فيها كل شيء باستثناء الدفع والسحب. (وهذه العمليات حسب التصميم غير المدمرة ، بحيث يمكنك الدفع/السحب عند الذهاب لتناول القهوة إذا كان الريبو المركزي متخلفًا) gitk هو عارض تاريخ جيد بما فيه الكفاية. git gui هي أداة الالتزام جيدة بما فيه الكفاية. مع تلوين الإخراج ، git add -i, git add -p, git rebase -i هي واجهات تفاعلية جيدة بما يكفي. git daemon و git instaweb هي جيدة بما يكفي للتعاون المخصص إذا كنت لا ترغب في / لا يمكنك التغلب على ريبو المركزي.

أنا أيضًا مستخدم سعيد أكثر من 10 سنوات من CVS ، على الرغم من أنني أحب أيضًا GIT ، ومع مرور الوقت سوف تفضل ذلك ، على الرغم من أن معظم المشاريع التي أعمل عليها تستخدم CVS حاليًا ، أو SVN ، ولا يمكننا أن نتمكن من ذلك للحصول على bureacracy حيث أعمل مقتنعا بالسماح لنا بضرب حفرة من خلال جدار الحماية.

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

"لحسن الحظ باستخدام CVS لأكثر من سنتات X" ، هي فكرة مثيرة للاهتمام :-) إنها خطوة كبيرة من الحفاظ على الكثير من النسخ ، ولكن ...

أظن أنك قد اعتدت على كل ما هو المراوغات ، أو لا تفعل الكثير من المتفرعة والاندماج. هناك احتمال أسوأ.

اعتاد الأشخاص في مؤسستك على قيود CVS وتكييف ممارسات عملك وفقًا لذلك ؛

على سبيل المثال ، لم يكن لديك أكثر من عمل مطور واحد على حزمة واحدة في كل مرة ، فقط باستخدام المتفرعة في حالات الطوارئ وما إلى ذلك.

المبدأ الأساسي هو الشيء الأكثر صعوبة ، كلما قلت الناس يفعلون ذلك.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow