في هذه المقالة ، نقارن من وجهة نظر تقنية أنظمة التحكم في الإصدار الأكثر شهرة (نخطط في المستقبل لتوسيع القائمة):
- الجيل الأول
- الجيل الثاني
- الجيل الثالث
تتبع أنظمة التحكم في الإصدار الأول (VCS) التغييرات في الملفات الفردية ، وتم دعم التحرير محليًا ومستخدم واحد فقط في كل مرة. تم بناء الأنظمة على افتراض أن جميع المستخدمين سوف يسجلون الدخول إلى حساباتهم على نفس عقدة يونيكس المشتركة.
قدم الجيل الثاني من VCS دعمًا للشبكة ، مما أدى إلى وجود مستودعات مركزية مع إصدارات "رسمية" من المشروعات. كان هذا تقدمًا كبيرًا ، حيث يمكن لعدة مستخدمين العمل مع الكود في نفس الوقت ، مع الالتزام بنفس المستودع المركزي. ومع ذلك ، يرتكب الوصول المطلوب إلى الشبكة.
يتكون الجيل الثالث من VCS الموزعة ، حيث تعتبر جميع نسخ المستودع متساوية ، ولا يوجد مستودع مركزي. يمهد هذا الطريق لعمليات التعيينات والفروع وعمليات الدمج التي يتم إنشاؤها محليًا دون الوصول إلى الشبكة ونقلها إلى مستودعات أخرى حسب الحاجة.
الجدول الزمني لإصدار VCS
بالنسبة للسياق ، إليك مخطط يوضح التواريخ التي ظهرت فيها هذه الأدوات:
SCCS (نظام التحكم في شفرة المصدر): الجيل الأول
يعتبر SCCS أحد أنظمة التحكم في الإصدار الناجحة الأولى. تم تطويره في عام 1972 بواسطة Mark Rochkind من Bell Labs. النظام مكتوب في C ومصمم لتتبع إصدارات الملفات المصدر. بالإضافة إلى ذلك ، سهلت إلى حد كبير البحث عن مصادر الأخطاء في البرنامج. تتيح البنية الأساسية وبناء جملة SCCS لفهم جذور أدوات VCS الحديثة.
هندسة معمارية
مثل معظم الأنظمة الحديثة ، لدى SCCS مجموعة من الأوامر للعمل مع إصدارات الملفات:
- تحقق في الملفات لتتبع التاريخ في SCCS.
- تحقق من إصدارات محددة من الملفات للمراجعة أو تجميع.
- استخراج إصدارات محددة للتحرير.
- تقديم إصدارات جديدة من الملفات مع تعليقات تشرح التغييرات.
- تجاهل التغييرات التي تم إجراؤها على الملف المستخرج.
- التغييرات المتفرعة ودمج كبير.
- ملف سجل التغيير.
عند إضافة ملف التتبع إلى SCCS ، يتم إنشاء نوع خاص من الملف ، والذي يسمى
s- أو
. يشار إليها باسم الملف المصدر ، فقط مع بادئة
s. ، ويتم تخزينها في الدليل الفرعي
SCCS . وبالتالي ، بالنسبة إلى ملف
test.txt ، سيتم إنشاء ملف محفوظات
test.txt في دليل
./SCCS/ . في وقت الإنشاء ، يحتوي ملف المحفوظات على المحتويات الأولية للملف المصدر ، وكذلك بعض البيانات الوصفية التي تساعد على تتبع الإصدارات. يتم تخزين المجموع الاختباري هنا لضمان عدم تعديل المحتويات. محتويات ملف المحفوظات غير مضغوطة أو مشفرة (كما في الجيل القادم من VCS).
نظرًا لأن محتويات الملف المصدر يتم تخزينها الآن في ملف المحفوظات ، فيمكن استخراجها في دليل العمل للعرض أو التجميع أو التحرير. يمكنك إجراء تغييرات على ملف السجل ، مثل إضافة خطوط وتغيير وحذف ، مما يزيد من رقم الإصدار الخاص به.
إضافات الملفات اللاحقة تخزن فقط
أو تغييرات ، وليس كل محتوياتها. هذا يقلل من حجم ملف السجل. يتم تخزين كل دلتا داخل ملف محفوظات في بنية تسمى
- . كما ذكرنا سابقًا ، فإن المحتويات الفعلية للملف يتم نسخها حرفيًا إلى حد ما ، مع تسلسل هروب خاص لتمييز بداية ونهاية أقسام المحتوى المضافة والمحذوفة. نظرًا لأن ملفات محفوظات SCCS لا تستخدم الضغط ، فعادة ما تكون أكبر من الملف الفعلي الذي يتم تتبع التغييرات فيه. تستخدم SCCS طريقة تسمى
، والتي تضمن وقت استرجاع ثابت بغض النظر عن عمر الإصدار الذي تم استرداده ، أي ، يتم استرداد الإصدارات القديمة بنفس سرعة النسخ الجديدة.
من المهم ملاحظة أن جميع الملفات يتم تعقبها وتسجيلها بشكل منفصل. لا يمكن التحقق من التغييرات في ملفات متعددة ككتلة ذرية واحدة ، مثل الالتزامات في Git. يحتوي كل ملف متعقب على ملف محفوظات خاص به ، حيث يتم تخزين محفوظات التغيير الخاصة به. في الحالة العامة ، هذا يعني أن أرقام إصدارات الملفات المختلفة في المشروع عادةً لا تتطابق. ومع ذلك ، يمكن الاتفاق على هذه الإصدارات من خلال تحرير جميع الملفات في المشروع في وقت واحد (دون حتى إجراء تغييرات حقيقية عليها) وإضافة جميع الملفات في نفس الوقت. سيؤدي هذا إلى زيادة رقم الإصدار في وقت واحد لجميع الملفات ، مع الحفاظ على تناسقها ، لكن لاحظ أن هذا ليس هو نفسه بما في ذلك تضمين ملفات متعددة في التزام واحد ، كما في Git. في SCCS ، تتم إضافة محفوظات فردية إلى كل ملف ، على عكس التزام كبير واحد يشمل جميع التغييرات في وقت واحد.
عندما يتم استخراج ملف للتحرير في SCCS ، يتم وضع قفل عليه ، بحيث لا يمكن لأي شخص آخر تحريره. هذا يمنع الكتابة فوق التغييرات من قبل مستخدمين آخرين ، ولكن أيضًا يحد من التطوير ، لأنه في أي وقت محدد يمكن لمستخدم واحد فقط العمل مع هذا الملف.
SCCS يدعم الفروع التي تخزن تسلسل التغيير في ملف معين. يمكنك دمج فرع بالإصدار الأصلي أو بفرع آخر.
الفرق الرئيسية
فيما يلي قائمة بأوامر SCCS الأكثر شيوعًا.
sccs create <filename.ext> : إضافة ملف جديد إلى SCCS وإنشاء ملف محفوظات جديد له (افتراضيًا في دليل ./SCCS/ ).
sccs get <filename.ext> : قم باستخراج الملف من ملف المحفوظات المناظر ووضعه في دليل العمل في وضع القراءة فقط.
sccs edit <filename.ext> : قم باستخراج الملف من ملف السجل المقابل للتحرير. قفل ملف السجل بحيث لا يمكن للمستخدمين الآخرين تعديله.
sccs delta <filename.ext> : إضافة التغييرات إلى الملف المحدد. سيطلب النظام تعليقًا ، ويحفظ التغييرات في ملف المحفوظات ويحرر القفل.
sccs prt <filename.ext> : عرض سجل التغيير للملف المراقبة.
sccs diffs <filename.ext> : إظهار الاختلافات بين نسخة العمل الحالية للملف وحالة الملف عند استخراجها.
لمزيد من المعلومات حول SCCS الداخلية ، راجع
دليل Eric Allman ودليل Oracle Programming Utility .
مثال ملف سجل SCCS
^Ah20562 ^As 00001/00001/00002 ^Ad D 1.3 19/11/26 14:37:08 jack 3 2 ^Ac Here is a comment. ^Ae ^As 00002/00000/00001 ^Ad D 1.2 19/11/26 14:36:00 jack 2 1 ^Ac No. ^Ae ^As 00001/00000/00000 ^Ad D 1.1 19/11/26 14:35:27 jack 1 0 ^Ac date and time created 19/11/26 14:35:27 by jack ^Ae ^Au ^AU ^Af e 0 ^At ^AT ^AI 1 Hi there ^AE 1 ^AI 2 ^AD 3 This is a test of SCCS ^AE 2 ^AE 3 ^AI 3 A test of SCCS ^AE 3
RCS (نظام التحكم في المراجعة): الجيل الأول
كتب RCS في عام 1982 من قبل والتر Tihey في C كبديل لنظام SCCS ، والذي في ذلك الوقت لم يكن مفتوح المصدر.
هندسة معمارية
لدى RCS الكثير من الأشياء المشتركة مع سابقتها ، بما في ذلك:
- الإصدار بشكل منفصل لكل ملف.
- لا يمكن تجميع التغييرات في ملفات متعددة في التزام واحد.
- لا يمكن تحرير الملفات المتعقبة بواسطة عدة مستخدمين في نفس الوقت.
- لا يوجد دعم الشبكة.
- يتم تخزين إصدارات كل ملف متعقب في ملف السجل المقابل.
- المتفرعة ودمج الإصدارات للملفات الفردية فقط.
عند إضافة ملف لأول مرة إلى RCS ، يتم إنشاء ملف محفوظات مطابق له في التخزين المحلي في الدليل المحلي
./RCS/ . تتم إضافة ملحق
,v ، إلى هذا الملف ، أي ، ملف يسمى
test.txt سيتم تتبعه بواسطة ملف يسمى
test.txt,v .
يستخدم RCS نظام دلتا العكسي لتخزين التغييرات. عند إضافة ملف ، يتم حفظ لقطة كاملة لمحتوياته في ملف السجل. عند تعديل الملف وإعادته مرة أخرى ، يتم حساب دلتا بناءً على المحتويات الموجودة في ملف المحفوظات. يتم تجاهل الصورة القديمة ، ويتم حفظ الصورة الجديدة مع الدلتا للعودة إلى الحالة القديمة. يُسمى ذلك
، لأنه لاسترداد إصدار قديم ، يأخذ RCS أحدث إصدار ويطبق بالتتابع دلتا حتى يصل إلى الإصدار المطلوب. تسمح لك هذه الطريقة باسترداد الإصدارات الحالية بسرعة كبيرة ، نظرًا لأن لقطة كاملة من المراجعة الحالية متوفرة دائمًا. ومع ذلك ، كلما كان الإصدار أقدم ، كلما استغرق التحقق وقتًا أطول ، لأنك تحتاج إلى التحقق من المزيد والمزيد من الدلتا.
في SCCS ، الأمر مختلف: يستغرق الأمر نفس الوقت لاستخراج أي إصدار. بالإضافة إلى ذلك ، لا يتم تخزين المجموع الاختباري في ملفات محفوظات RCS ، لذلك لا يمكن ضمان تكامل الملف.
الفرق الرئيسية
فيما يلي قائمة بأوامر RCS الأكثر شيوعًا:
<filename.ext> : أضف ملفًا جديدًا إلى RCS وإنشاء ملف محفوظات جديد له (افتراضيًا في دليل ./RCS/ ).
co <filename.ext> : قم باستخراج الملف من ملف السجل المقابل ووضعه في دليل العمل في وضع القراءة فقط.
co -l <filename.ext> : استخرج الملف من ملف السجل المقابل للتحرير. قفل ملف السجل بحيث لا يمكن للمستخدمين الآخرين تعديله.
ci <filename.ext> : إضافة تغييرات الملف وإنشاء مراجعة جديدة له في ملف السجل المقابل.
merge <file-to-merge-into.ext> <parent.ext> <file-to-merge-from.ext> : دمج التغييرات من جهازي تعديل من نفس الملف الأصل.
rcsdiff <filename.ext> : عرض الاختلافات بين نسخة العمل الحالية للملف وحالة الملف عند استخراجها.
rcsclean : حذف ملفات العمل غير المؤمنة.
لمزيد من المعلومات حول مكونات RCS الداخلية ، انظر دليل
GNU RCS .
مثال ملف السجل RCS
head 1.2; access; symbols; locks; strict; comment @# @; 1.2 date 2019.11.25.05.51.55; author jstopak; state Exp; branches; next 1.1; 1.1 date 2019.11.25.05.49.02; author jstopak; state Exp; branches; next ; desc @This is a test. @ 1.2 log @Edited the file. @ text @hi there, you are my bud. You are so cool! The end. @ 1.1 log @Initial revision @ text @d1 5 a5 1 hi there @
CVS (نظام الإصدارات المتزامنة): الجيل الثاني
تم إنشاء CVS بواسطة Dick Grun في عام 1986 لإضافة دعم الشبكة إلى التحكم في الإصدار. كما أنه مكتوب بلغة C ويمثل ميلاد الجيل الثاني من أدوات VCS ، وذلك بفضل أن فرق التطوير الموزعة جغرافيا لديهم الفرصة للعمل في مشاريع معًا.
هندسة معمارية
CVS هي واجهة أمامية لـ RCS ، ولديها مجموعة جديدة من الأوامر للتفاعل مع الملفات في المشروع ، ولكن تحت غطاء الرأس يتم استخدام نفس تنسيق ملف محفوظات RCS وأوامر RCS. لأول مرة ، سمحت CVS لعدة مطورين للعمل مع نفس الملفات في وقت واحد. يتم تطبيق ذلك باستخدام نموذج مستودع مركزي. تتمثل الخطوة الأولى في تكوين مستودع مركزي باستخدام CVS على الخادم البعيد. يمكن بعد ذلك استيراد المشروعات إلى المستودع. عند استيراد مشروع إلى CVS ، يتم تحويل كل ملف إلى ملف محفوظات
,v وتخزينه في دليل مركزي:
. يوجد المستودع عادةً على خادم بعيد ، يمكن الوصول إليه عبر شبكة محلية أو الإنترنت.
يتلقى المطور نسخة من الوحدة النمطية ، التي يتم نسخها إلى دليل العمل على جهاز الكمبيوتر المحلي الخاص به. في هذه العملية ، لا يتم حظر أي ملفات ، لذلك لا يوجد حد لعدد المطورين الذين يمكنهم العمل في وقت واحد مع الوحدة النمطية. يمكن للمطورين تعديل ملفاتهم والالتزام بالتغييرات حسب الضرورة (الالتزام). إذا قام أحد مطوري البرامج بإجراء تغيير ، يجب على المطورين الآخرين تحديث نسخ العمل الخاصة بهم باستخدام عملية الدمج الآلي (عادة) قبل تنفيذ التغييرات. في بعض الأحيان ، عليك حل تعارضات الدمج يدويًا قبل الالتزام. يوفر CVS أيضًا القدرة على إنشاء فروع ودمجها.
الفرق الرئيسية
export CVSROOT=<path/to/repository> : قم بتعيين الدليل الجذر لمستودع CVS ، لذلك لا تحتاج إلى تحديده في كل أمر.
cvs import -m 'Import module' <module-name> <vendor-tag> <release-tag> : قم باستيراد الدلائل مع الملفات في وحدة CVS. قبل البدء في هذه العملية ، انتقل إلى الدليل الجذر للمشروع.
cvs checkout <module-name> : انسخ الوحدة النمطية إلى دليل العمل.
cvs commit <filename.ext> : قم بإعادة تشغيل الملف المعدل إلى الوحدة النمطية في المستودع المركزي.
cvs add <filename.txt> : إضافة ملف جديد لتتبع التغييرات.
cvs update : قم بتحديث نسخة العمل عن طريق دمج التغييرات التي تم الالتزام بها الموجودة في المستودع المركزي ولكن ليس في نسخة العمل.
cvs status : إظهار المعلومات العامة حول نسخة العمل المستخرجة من الوحدة.
cvs tag <tag-name> <files> : أضف علامة إلى ملف أو مجموعة من الملفات.
cvs tag -b <new-branch-name> : إنشاء فرع جديد في المستودع (تحتاج إلى استخراجه قبل العمل المحلي).
cvs checkout -r <branch-name> : استخراج فرع موجود إلى دليل العمل.
cvs update -j <branch-to-merge> : دمج فرع موجود مع نسخة عمل محلية.
لمزيد من المعلومات حول المكونات الداخلية لـ CVS ، راجع
كتيب GNU CVS ومقالة Dick Grohn .
السيرة الذاتية ملف التاريخ مثال
head 1.1; branch 1.1.1; access ; symbols start:1.1.1.1 jack:1.1.1; locks ; strict; comment @# @; 1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches 1.1.1.1; next ; commitid zsEBhVyPc4lonoMB; 1.1.1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches ; next ; commitid zsEBhVyPc4lonoMB; desc @@ 1.1 log @Initial revision @ text @hi there @ 1.1.1.1 log @Imported sources @ text @@
SVN (التخريب): الجيل الثاني
تم إنشاء Subversion في عام 2000 بواسطة Collabnet Inc. وهو مدعوم حاليًا بواسطة Apache Software Foundation. النظام مكتوب في C ومصمم كحل مركزي أكثر موثوقية من CVS.
هندسة معمارية
مثل CVS ، يستخدم Subversion نموذج مستودع مركزي. يحتاج المستخدمون عن بُعد إلى اتصال شبكة للالتزام بالمستودع المركزي.
أدخلت التخريب وظيفة الالتزامات الذرية مع ضمان أن يكون الالتزام ناجحًا تمامًا أو يتم إلغاؤه تمامًا في حالة حدوث مشكلة. في CVS ، في حالة حدوث عطل في منتصف الالتزام (على سبيل المثال ، بسبب فشل في الشبكة) ، يمكن أن يظل المستودع في حالة تالفة وغير متسقة. بالإضافة إلى ذلك ، قد يتضمن الالتزام أو الإصدار في Subversion العديد من الملفات والدلائل. هذا مهم لأنه يسمح لك بتتبع مجموعات التغييرات ذات الصلة معًا ككتلة مجمعة ، وليس بشكل منفصل لكل ملف ، كما في أنظمة الماضي.
يستخدم Subversion حاليًا نظام ملفات FSFS (نظام الملفات أعلى نظام الملفات). هنا يتم إنشاء قاعدة بيانات بهيكل الملفات والدلائل التي تتوافق مع نظام الملفات المضيف. من الميزات الفريدة في FSFS أنها مصممة لتتبع ليس فقط الملفات والدلائل ، ولكن أيضًا إصداراتها. هذا نظام ملفات حساس للوقت. الدلائل هي أيضا كائنات كاملة في التخريب. يمكنك إرسال أدلة فارغة إلى النظام ، في حين أن البقية (حتى Git) لا تلاحظها.
عند إنشاء مستودع Subversion ، يتم إنشاء قاعدة بيانات فارغة (تقريبًا) من الملفات والمجلدات بتكوينها. يتم إنشاء دليل
db/revs ، الذي يخزن جميع معلومات تتبع الإصدار للملفات (الملتزم بها) المضافة. يتم تخزين كل التزام (والذي قد يتضمن تغييرات في عدة ملفات) في ملف جديد في دليل
revs ، ويتم إعطاء اسم له معرف رقمي متسلسل يبدأ بـ 1. الالتزام الأول يحفظ المحتويات الكاملة للملف. لن تؤدي الالتزامات المستقبلية لنفس الملف إلا إلى حفظ التغييرات ، والتي تسمى أيضًا
أو deltas ، لتوفير المساحة. بالإضافة إلى ذلك ، يتم ضغط دلتا باستخدام خوارزميات ضغط
lz4 أو
zlib لتقليل الحجم.
مثل هذا النظام يعمل فقط حتى نقطة معينة. على الرغم من أن deltas توفر مساحة ، ولكن إذا كان هناك الكثير منها ، فهناك الكثير من الوقت اللازم للعملية ، حيث يجب معالجة جميع deltas لإعادة الحالة الحالية للملف. لهذا السبب ، بشكل افتراضي ، يحفظ Subversion ما يصل إلى 1023 دلتا لكل ملف ، ثم يقوم بعمل نسخة كاملة جديدة من الملف. هذا يوفر توازن جيد في التخزين والسرعة.
لا تستخدم SVN نظام التفرع والترميز المعتاد. يحتوي قالب مستودع Subversion العادي على ثلاثة مجلدات في الجذر:
يتم استخدام الدليل
trunk/ الدليل للإصدار الإنتاج من المشروع.
branches/ الدليل - لتخزين المجلدات الفرعية المقابلة للفروع الفردية.
tags/ الدليل لتخزين العلامات التي تمثل إصدارات محددة (عادة ما تكون مهمة) من المشروع.
الفرق الرئيسية
svn create <path-to-repository> : قم بإنشاء مستودع تخزين فارغ جديد في الدليل المحدد.
svn import <path-to-project> <svn-url> : قم باستيراد دليل الملفات إلى مستودع Subversion المحدد.
svn checkout <svn-path> <path-to-checkout> : انسخ المخزون إلى دليل العمل.
svn commit -m 'Commit message' : ارتكاب مجموعة من الملفات والمجلدات المعدلة مع الرسالة.
svn add <filename.txt> : أضف ملفًا جديدًا لتعقب التغييرات.
svn update : قم بتحديث نسخة العمل عن طريق دمج التغييرات الملتزمة الموجودة في المستودع المركزي ولكن ليس في نسخة العمل.
svn status : عرض قائمة بالملفات المراقبة التي تم تغييرها في دليل العمل (إن وجد).
svn info : svn info عامة حول النسخة المستخرجة.
svn copy <branch-to-copy> <new-branch-path-and-name> : إنشاء فرع جديد عن طريق نسخ فرع موجود.
svn switch <existing-branch> : بدّل دليل العمل إلى فرع موجود. هذا سيسمح لك بأخذ الملفات من هناك.
svn merge <existing-branch> : دمج الفرع المحدد مع الفرع الحالي الذي تم نسخه إلى دليل العمل. يرجى ملاحظة أنك سوف تحتاج إلى الالتزام في وقت لاحق.
svn log : عرض محفوظات التعيينات والرسائل المقابلة للفرع النشط.
لمزيد من المعلومات حول المكونات الداخلية لـ SVN ، راجع إصدار
التخريب .
عينة ملف محفوظات SVN
DELTA SVN^B^@^@ ^B ^A<89> hi there ENDREP id: 2-1.0.r1/4 type: file count: 0 text: 1 3 21 9 12f6bb1941df66b8f138a446d4e8670c 279d9035886d4c0427549863c4c2101e4a63e041 0-0/_4 cpath: /trunk/hi.txt copyroot: 0 / DELTA SVN^B^@^@$^B%^A¤$K 6 hi.txt V 15 file 2-1.0.r1/4 END ENDREP id: 0-1.0.r1/6 type: dir count: 0 text: 1 5 48 36 d84cb1c29105ee7739f3e834178e6345 - - cpath: /trunk copyroot: 0 / DELTA SVN^B^@^@'^B#^A¢'K 5 trunk V 14 dir 0-1.0.r1/6 END ENDREP id: 0.0.r1/2 type: dir pred: 0.0.r0/2 count: 1 text: 1 7 46 34 1d30e888ec9e633100992b752c2ff4c2 - - cpath: / copyroot: 0 / _0.0.t0-0 add-dir false false false /trunk _2.0.t0-0 add-file true false false /trunk/hi.txt L2P-INDEX ^A<80>@^A^A^A^M^H^@ä^H÷^Aé^FDÎ^Bzè^AP2L-INDEX ^A<91>^E<80><80>@^A?^@'2^@<8d>»Ý<90>^C§^A^X^@õ ½½^N= ^@ü<8d>Ôã^Ft^V^@<92><9a><89>Ã^E; ^@<8a>åw|I^@<88><83>Î<93>^L`^M^@ù<92>À^Eïú?^[^@^@657 6aad60ec758d121d5181ea4b81a9f5f4 688 75f59082c8b5ab687ae87708432ca406I
بوابة: الجيل الثالث
تم تطوير نظام Git في عام 2005 من قبل Linus Torvalds (خالق نظام Linux). هو مكتوب في المقام الأول في جيم بالاشتراك مع بعض البرامج النصية لسطر الأوامر. يختلف عن VCS في الوظائف والمرونة والسرعة. كتب Torvalds في الأصل نظام قاعدة كود Linux ، ولكن مع مرور الوقت تم توسيع نطاقه ، واليوم أصبح أكثر أنظمة التحكم في الإصدارات شيوعًا في العالم.
هندسة معمارية
بوابة هو نظام موزعة. لا يوجد مستودع مركزي: يتم إنشاء جميع النسخ على قدم المساواة ، والتي تختلف اختلافًا كبيرًا عن الجيل الثاني من VCS ، حيث يعتمد العمل على إضافة واستخراج الملفات من المستودع المركزي. هذا يعني أنه يمكن للمطورين تبادل التغييرات مع بعضهم البعض فورًا قبل دمج تغييراتهم في فرع رسمي.
بالإضافة إلى ذلك ، يمكن للمطورين إجراء تغييراتهم على النسخة المحلية من المستودع دون معرفة المستودعات الأخرى. يسمح هذا بعمليات ارتكاب دون الاتصال بشبكة أو الإنترنت. يمكن للمطورين العمل محليًا في وضع عدم الاتصال ، حتى يكونوا على استعداد لمشاركة عملهم مع الآخرين. في هذه المرحلة ، يتم إرسال التغييرات إلى مستودعات أخرى للتحقق أو الاختبار أو النشر.
عند إضافة ملف للتتبع في Git ، يتم ضغطه باستخدام خوارزمية ضغط
zlib . يتم تجزئة النتيجة باستخدام دالة تجزئة SHA-1. هذا يعطي تجزئة فريدة من نوعها يطابق على وجه التحديد محتويات هذا الملف. يخزنها Git في
، التي توجد في مجلد مخفي
.git/objects . اسم الملف هو التجزئة التي تم إنشاؤها ، ويحتوي الملف على محتوى مضغوط. تسمى هذه الملفات
ويتم إنشاؤها في كل مرة يتم فيها إضافة ملف جديد (أو نسخة معدلة من ملف موجود) إلى المستودع.
تنفذ Git فهرسًا مرحليًا ، يعمل كمنطقة وسيطة للتغييرات التي يتم إعدادها للالتزام. عند إعداد تغييرات جديدة ، تتم الإشارة إلى محتوياتها المضغوطة في ملف فهرس خاص ، والذي يأخذ شكل كائن
.
الشجرة هي كائن Git يربط النقاط مع أسماء الملفات الحقيقية وأذونات الملفات والروابط إلى الأشجار الأخرى ، وبالتالي يمثل حالة مجموعة معينة من الملفات والدلائل. عندما يتم إعداد جميع التغييرات ذات الصلة للالتزام ، يمكن أن تكون شجرة الفهرس ملتزمة بمستودع التخزين الذي ينشئ الكائن (أشياء فضفاضة). لا تُستخدم هنا فروق لتوفير مساحة ، مما يجعل Git سريعًا للغاية ، حيث أن المحتويات الكاملة لكل إصدار من الملف متاحة ككائن حر. ومع ذلك ، فإن بعض العمليات ، مثل إرسال عمليات الالتزام إلى مستودع بعيد ، أو تخزين عدد كبير جدًا من الكائنات ، أو تشغيل أمر Git garbage collection يدويًا ، تتسبب في إعادة تجميع الكائنات .packتحتوي على محتويات الكائن ، ويتم إنشاء ملف .idx(أو فهرس) لكل منهم مع ارتباط بالكائنات المحزومة وموقعها في ملف الدُفعات.عند نقل الفروع إلى المستودعات البعيدة أو استردادها منها ، يتم نقل هذه الملفات الدفعية عبر الشبكة. عند تمديد الفروع أو استخراجها ، يتم فك حزم ملفات الحزمة لإنشاء كائنات مجانية في مستودع تخزين الكائنات.الفرق الرئيسية
git init: تهيئة الدليل الحالي كمستودع Git ( .gitيتم إنشاء مجلد مخفي ومحتوياته).
git clone <git-url> : قم بتنزيل نسخة من مستودع Git على عنوان URL المحدد.
git add <filename.ext> : أضف ملفًا لم يتم تتبعه أو تعديله إلى منطقة التدريج (ينشئ السجلات المقابلة في قاعدة بيانات الكائنات).
git commit -m 'Commit message' : ارتكاب مجموعة من الملفات والمجلدات المعدلة مع رسالة الالتزام.
git status : عرض حالة دليل العمل ، الفرع الحالي ، الملفات التي لم يتم تعقبها ، الملفات المعدلة ، إلخ.
git branch <new-branch> : إنشاء فرع جديد على أساس الفرع المستخرج الحالي.
git checkout <branch> : استخراج الفرع المحدد إلى دليل العمل.
git merge <branch> : دمج الفرع المحدد مع الفرع الحالي ، والذي يتم استخراجه في دليل العمل.
git pull : قم بتحديث نسخة العمل عن طريق دمج التغييرات التي تم الالتزام بها الموجودة في المخزون البعيد ، ولكن ليس في نسخة العمل.
git push : حزمة كائنات مجانية لارتكاب الفرع المحلي النشط في ملفات الحزمة ونقلها إلى مستودع بعيد.
git log : إظهار محفوظات التعيينات والرسائل المقابلة للفرع النشط.
git stash : حفظ جميع التغييرات غير الملتزم بها من دليل العمل إلى ذاكرة التخزين المؤقت لاسترجاعها لاحقا.
إذا كنت تريد معرفة كيفية عمل رمز Git ، فراجع دليل Git Starter Guide . لمزيد من المعلومات حول المكونات الداخلية ، راجع الفصل المقابل في كتاب Pro Git .مثال blob ، شجرة والالتزام بوابة
النقطة مع التجزئة 37d4e6c5c48ba0d245164c4e10d5f41140cab980: hi there
كائن شجرة مع التجزئة b769f35b07fbe0076dcfc36fd80c121d747ccc04: 100644 blob 37d4e6c5c48ba0d245164c4e10d5f41140cab980hi.txt
تجزئة الالتزام dc512627287a61f6111705151f4e53f204fbda9b: tree b769f35b07fbe0076dcfc36fd80c121d747ccc04 author Jacob Stopak 1574915303 -0800 committer Jacob Stopak 1574915303 -0800 Initial commit
زئبقي: الجيل الثالث
تم إنشاء Mercurial في عام 2005 من قبل مات ماكول وكتب في بيثون. تم تصميمه أيضًا لاستضافة قاعدة كود Linux ، ولكن تم اختيار Git في النهاية لهذه المهمة. هذا هو ثاني أكثر أنظمة التحكم في الإصدارات شيوعًا ، على الرغم من أنه يتم استخدامه بشكل متكرر أقل.هندسة معمارية
Mercurial هو أيضًا نظام موزع يسمح لأي عدد من المطورين بالعمل مع نسختهم من المشروع بشكل مستقل عن الآخرين. يستخدم Mercurial العديد من نفس تقنيات Git ، بما في ذلك SHA-1 compression and hashing ، لكنه يفعل ذلك بطريقة مختلفة.عندما يتم الالتزام بملف جديد للتتبع في Mercurial ، يتم إنشاء ملف مطابق له revlogفي دليل مخفي .hg/store/data/. يمكنك اعتبار الملف revlog(سجل التغيير) كإصدار تمت ترقيته في VCS الأقدم مثل CVS و RCS و SCCS. بخلاف Git ، الذي ينشئ نقطة نشوء جديدة لكل إصدار من كل ملف معد ، يقوم Mercurial ببساطة بإنشاء إدخال تجديد جديد لهذا الملف. لتوفير مساحة ، يحتوي كل سجل جديد على دلتا من الإصدار السابق فقط. عندما يتم الوصول إلى الحد الأدنى من دلتا ، يتم حفظ لقطة كاملة من الملف مرة أخرى. هذا يقلل من وقت البحث عند معالجة عدد كبير من دلتا لاستعادة إصدار معين من الملف.تتم تسمية كل مدوَّنة وفقًا للملف الذي يتم تتبعه ، ولكن بالامتداد .iأو .d. .dتحتوي الملفات على دلتا مضغوطة. .iتستخدم الملفات كفهارس لتتبع الإصدارات المختلفة داخل الملفات بسرعة.d. بالنسبة للملفات الصغيرة ذات التغييرات القليلة ، يتم تخزين الفهارس والمحتوى داخل الملفات .i. يتم ضغط إدخالات تسجيل الدخول من أجل الأداء وتقسيمها لتحديد الهوية. تتم تسمية هذه القيم التجزئة nodeid.في كل التزام ، يتتبع Mercurial جميع إصدارات الملفات الموجودة في هذا الالتزام فيما يسمى بـ nodeid.أخيرًا ، يستخدم Mercurial نوعًا آخر من الإضافات يسمى سجل التغيير ، أي سجل التغيير. هذه قائمة بالإدخالات التي تربط كل التزام بالمعلومات التالية:- nodeid: مجموعة كاملة من إصدارات الملفات الموجودة في وقت معين من الوقت.
- واحد أو اثنين من العقيدات التي يرتكبها الوالد: هذا يسمح لـ Mercurial بإنشاء جدول زمني أو فرع من تاريخ المشروع. يتم تخزين معرّف أصل واحد أو اثنين حسب نوع الالتزام (عادي أو دمج).
- ارتكب المؤلف
- تاريخ الالتزام
- رسالة الالتزام
كل إدخال سجل التغيير يولد أيضا تجزئة المعروفة باسم nodeid.الفرق الرئيسية
hg init: تهيئة الدليل الحالي كمستودع Mercurial (ينشئ مجلدًا مخفيًا .hgومحتوياته).
hg clone <hg-url> : قم بتنزيل نسخة من مستودع Mercurial على عنوان URL المحدد.
hg add <filename.ext> : إضافة ملف جديد لتتبع التغييرات.
hg commit -m 'Commit message' : ارتكاب مجموعة من الملفات والمجلدات التي تم تغييرها مع رسالة الالتزام.
hg status : عرض المعلومات المتعلقة بحالة دليل العمل ، والملفات التي لم يتم تعقبها ، والملفات المعدلة ، إلخ.
hg update <revision> : استخراج الفرع المحدد إلى دليل العمل.
hg merge <branch> : دمج الفرع المحدد مع الفرع الحالي المستخرج إلى دليل العمل.
hg pull : قم بتنزيل إصدارات جديدة من مستودع تخزين بعيد ، ولكن لا تندمجها في دليل عمل.
hg push : نقل الإصدارات الجديدة إلى المستودع البعيد.
hg log : إظهار محفوظات التعيينات والرسائل ذات الصلة للفرع النشط.
مثال ملفات الزئبق
البيان: hey.txt208b6e0998e8099b16ad0e43f036ec745d58ec04 hi.txt74568dc1a5b9047c8041edd99dd6f566e78d3a42
تغيير السجل (سجل التغيير): b8ee947ce6f25b84c22fbefecab99ea918fc0969 Jacob Stopak 1575082451 28800 hey.txt Add hey.txt
معلومات إضافية حول جهاز Mercurial: