نظام التحكم في الإصدار

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

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

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

تعتبر مجموعات السلاسل التي تم تغييرها والتي لا تتقاطع متوافقة ويتم دمجها تلقائيًا. إذا كانت الملفات المدمجة تحتوي على تغييرات تؤثر على نفس سطر الملف، فهذا يؤدي إلى حدوث تعارض. ولا يمكن دمج هذه الملفات إلا يدويًا. تعتبر أي ملفات بخلاف الملفات النصية ثنائية من وجهة نظر VCS ولا تسمح بالدمج التلقائي.

الصراعات وحلها

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

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

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

أقفال

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

الاستخدام المكثف للأقفال، عندما تكون جميع أو معظم الملفات في المشروع قابلة للقفل ولأي تغييرات يكون من الضروري قفل مجموعة الملفات المقابلة، يُطلق عليه أيضًا استراتيجية "الخروج المقفل". دعمت أنظمة التحكم في الإصدارات المبكرة هذه الإستراتيجية بشكل حصري، وبالتالي منع حدوث الصراعات في المقام الأول. في VCS الحديثة، يُفضل استخدام عمليات الاسترجاع غير المحظورة، في حين يعتبر الحظر شرًا ضروريًا يجب الحد منه كلما أمكن ذلك. عيوب استخدام الأقفال واضحة:

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

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

إصدارات المشروع، العلامات

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

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

بالنسبة للأنظمة الأخرى، لا يشير مفهوم "الإصدار" إلى ملف فردي، بل إلى مخزنتماما. يحتوي المستودع الفارغ الذي تم إنشاؤه حديثًا على الإصدار 1 أو 0، وأي التزام بالتغييرات يؤدي إلى زيادة في هذا الرقم (أي، حتى إذا تغير ملف واحد بمقدار بايت واحد، فإن المستودع بأكمله يعتبر متغيرًا ويتلقى رقم إصدار جديد). هذه هي الطريقة التي يتم بها تفسير أرقام الإصدارات، على سبيل المثال، بواسطة نظام Subversion. في الواقع، رقم إصدار الملف الفردي هنا غير موجود، يمكننا أن نعتبر رقم الإصدار الحالي للمستودع كذلك (أي، نفترض أنه مع كل تغيير يتم إجراؤه على المستودع، فإن جميع ملفاته تغير الإصدار؛ الرقم، حتى تلك التي لم تتغير). في بعض الأحيان، عند الحديث عن "إصدار ملف" في مثل هذه الأنظمة، فإنهم يقصدون إصدار المستودع الذي تم تعديل الملف فيه آخر مرة (قبل اللحظة التي تهمنا).

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

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

المبادئ الأساسية لتطوير البرمجيات في VCS

يتم تحديد إجراءات استخدام نظام التحكم في الإصدار في كل حالة محددة من خلال اللوائح والقواعد الفنية المعتمدة من قبل الشركة أو المؤسسة المحددة التي تقوم بتطوير المشروع. ومع ذلك، فإن المبادئ العامة للاستخدام الصحيح لـ VCS قليلة وهي نفسها لجميع أنظمة التطوير والتحكم في الإصدار.

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

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

فرعالفرع هو اتجاه التطور المستقل عن الآخرين. الفرع عبارة عن نسخة من جزء (عادةً دليل واحد) من المستودع الذي يمكنك إجراء تغييراتك عليه دون التأثير على الفروع الأخرى. المستندات في الفروع المختلفة لها نفس التاريخ قبل نقطة الفرع وأخرى مختلفة بعدها. التغييرات, نشاطمجموعة من التغييرات. يمثل مجموعة مسماة من التعديلات التي تم إجراؤها على نسخة محلية لبعض الأغراض المشتركة. في الأنظمة التي تدعم مجموعات التحرير، يمكن للمطور تجميع عمليات التحرير المحلية وتنفيذ التغييرات المرتبطة منطقيًا باستخدام أمر واحد، مع تحديد مجموعة التحرير المطلوبة كمعلمة. ومع ذلك، ستبقى التعديلات الأخرى دون إصلاح. مثال نموذجي: أنت تعمل على إضافة وظائف جديدة، وفي هذه اللحظة تم اكتشاف خطأ فادح يجب إصلاحه على الفور. يقوم المطور بإنشاء مجموعة تغيير للعمل المنجز بالفعل ومجموعة جديدة للتصحيحات. عند الانتهاء من تصحيح الخطأ، يتم إعطاء أمر بتنفيذ المجموعة الثانية فقط من التعديلات. تحقق في, يقترف, يُقدِّمإنشاء نسخة جديدة، وإجراء التغييرات. نشر التغييرات التي تم إجراؤها في نسخة العمل إلى مخزن المستندات. وفي الوقت نفسه، يتم إنشاء نسخة جديدة من المستندات التي تم تغييرها في المستودع. الدفع, استنساخاسترجاع مستند من التخزين وإنشاء نسخة عمل. صراعالتعارض هو موقف يقوم فيه العديد من المستخدمين بإجراء تغييرات على نفس القسم من المستند. يتم اكتشاف التعارض عندما يقوم أحد المستخدمين بتنفيذ تغييراته، ويحاول المستخدم الثاني تنفيذها، ولا يتمكن النظام نفسه من دمج التغييرات المتعارضة بشكل صحيح. نظرًا لأن البرنامج قد لا يكون ذكيًا بما يكفي لتحديد التغيير "الصحيح"، يحتاج المستخدم الثاني إلى حل التعارض بنفسه ( حل). رأسالإصدار الرئيسي هو الإصدار الأحدث للفرع/الجذع في المستودع. هناك العديد من الإصدارات الرئيسية كما توجد فروع. دمج, اندماجالدمج - دمج التغييرات المستقلة في نسخة واحدة من المستند. يحدث عندما يقوم شخصان بتغيير نفس الملف أو عند دفع التغييرات من فرع إلى آخر. rebaseنقل نقطة الفرع (الإصدار الذي يبدأ منه الفرع) إلى إصدار أحدث من الفرع الرئيسي. على سبيل المثال، بعد إصدار الإصدار 1.0 من المشروع، تستمر التحسينات في الجذع (إصلاحات الأخطاء، وتحسينات على الوظائف الحالية)، وفي نفس الوقت يبدأ العمل على وظائف جديدة في فرع جديد. بعد مرور بعض الوقت، تم إصدار الإصدار 1.1 (مع التصحيحات) في الفرع الرئيسي؛ من المرغوب الآن أن يتضمن فرع تطوير الوظائف الجديدة التغييرات التي حدثت في صندوق السيارة. بشكل عام، يمكن القيام بذلك باستخدام الأدوات الأساسية، باستخدام الدمج، واختيار مجموعة من التغييرات بين الإصدارين 1.0 و1.1 ودمجها في فرع. ولكن إذا كان النظام يدعم إعادة تعيين الفروع، فإن هذه العملية تتم بشكل أسهل، باستخدام أمر واحد: باستخدام أمر rebase (مع المعلمات: الفرع والإصدار الأساسي الجديد)، يحدد النظام بشكل مستقل مجموعات التغييرات الضرورية ويدمجها، وبعد ذلك الإصدار 1.1 يصبح الإصدار الأساسي للفرع؛ عندما يتم دمج فرع لاحقًا في صندوق الأمتعة، فإن النظام لا يعيد النظر في التغييرات التي تم إجراؤها بين الإصدارين 1.0 و1.1، نظرًا لأنه يعتبر منطقيًا أن الفرع قد تم تخصيصه بعد الإصدار 1.1. مخزن, مستودعتخزين المستندات هو المكان الذي يقوم فيه نظام التحكم في الإصدار بتخزين جميع المستندات بالإضافة إلى سجل التعديلات ومعلومات الخدمة الأخرى. مراجعةنسخة الوثيقة. تقوم أنظمة التحكم في الإصدار بتمييز الإصدارات بالأرقام التي يتم تعيينها تلقائيًا. رفوفتأجيل التغييرات. توفر بعض الأنظمة القدرة على إنشاء مجموعة تغييرات وحفظها على الخادم دون الالتزام بها. مجموعة التغييرات المؤجلة متاحة للقراءة من قبل أعضاء المشروع الآخرين، ولكن لا يتم تضمينها في الفرع الرئيسي حتى يقوم فريق خاص بذلك. يتيح دعم تأجيل التغييرات للمستخدمين حفظ العمل غير المكتمل على الخادم دون إنشاء فروع منفصلة لذلك. بطاقة شعار, ملصقتسمية يمكن تعيينها لإصدار معين من المستند. التسمية هي اسم رمزي لمجموعة من المستندات، حيث تصف التسمية ليس فقط مجموعة من أسماء الملفات، ولكن أيضًا إصدار كل ملف. قد تنتمي إصدارات المستندات المضمنة في العلامة إلى نقاط زمنية مختلفة. صُندُوق, الخط الرئيسي, يتقنالجذع هو الفرع الرئيسي لتطوير المشروع. قد تختلف سياسة الجذع من مشروع إلى آخر، ولكنها بشكل عام هي كما يلي: يتم إجراء معظم التغييرات على الجذع؛ إذا كان هناك حاجة إلى تغيير كبير يمكن أن يؤدي إلى عدم الاستقرار، يتم إنشاء فرع يندمج مع الجذع عندما يتم اختبار الابتكار بشكل كافٍ؛ قبل إصدار الإصدار التالي، يتم إنشاء فرع "الإصدار"، حيث يتم إجراء التصحيحات فقط. تحديث, مزامنةمزامنة نسخة العمل مع بعض حالات التخزين المحددة. في أغلب الأحيان، يعني هذا الإجراء تحديث نسخة العمل إلى أحدث حالة للمستودع. ومع ذلك، إذا لزم الأمر، يمكنك مزامنة نسخة العمل إلى حالة أقدم من الحالة الحالية. نسخة العملنسخة العمل (المحلية) من الوثائق.

أنظر أيضا

• إدارة التكوين (إدارة تكوين البرامج)، أدوات إدارة التكوين (أدوات إدارة تكوين البرامج)
• منتجات برمجية ذات تحكم شفاف في الإصدار
  • بعض التطبيقات

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

لماذا هذا ضروري؟

أنا نفسي طالب في إحدى الجامعات التقنية وأعمل بشكل دائم تقريبًا مع المستندات (النصوص والرسومات والرسومات)، وأغيرها ثلاث (عشرة، مائة) مرات في اليوم. في بعض الأحيان يتبين أنه يجب التراجع عن التعديلات التي تم إجراؤها خلال الأسبوع الماضي وإعادة المستندات إلى الحالة التي كانت عليها قبل أسبوع. من الجيد أن يتم إجراء بعض التعديلات فقط، وفي هذه الحالة يمكن أن تساعد خمسون زيارة على Ctrl+Z. ومع ذلك، إذا كان هناك عمل أكثر أو أقل نشاطًا مع المستند خلال هذا الأسبوع، فلن يكون من الممكن ببساطة استعادة الحالة "قبل إجراء تعديل مهم قبل أسبوع". للقيام بذلك، تحتاج إلى نسخة من المستند في ذلك الوقت "قبل إجراء تعديل مهم"، بالإضافة إلى اثنتي عشرة نسخة أخرى "قبل تعديل مهم آخر"، و"قبل تعديل مشكوك فيه"، و"قبل تعديل قد يؤدي إلى ضرر كبير". من المرجح أن يتم التراجع عنها." من حيث المبدأ، هذا النهج ممكن ويمارسه الكثيرون. حتى وقت قريب، كنت أحتفظ بنفسي بإصدارات مهمة من الملفات، وأحفظها ببادئات "date_time"، ويبدو أنني كنت سعيدًا. ميزة هذه الطريقة هي بساطتها، والعيب هو أن مجلدات العمل "تنتفخ" وغير مريحة للاستخدام. وإذا كان من الممكن التعامل مع أولها بطريقة ما (محركات الأقراص الصلبة الكبيرة و7zip)، فلا بد من فعل شيء حيال هذا الإزعاج.

ما الذي يمكن عمله حيال ذلك، أو ما هو مرض الذئبة الحمراء (SLE).

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

ما هي أنواع العملات الصعبة الموجودة؟

وتشير نفس ويكيبيديا إلى أن العملة الصعبة يمكن أن تكون مركزية وموزعة، كبيرة وصغيرة، مع أو بدون أجراس وصفارات. نحن لسنا مهتمين بشكل خاص بهذا، لأننا سنستخدم (على الأقل في البداية) جزءًا فقط من وظائف نظام صرف العملات. دعونا نفكر في هذه الوظيفة بالذات.
تعد جميع وحدات VCS تقريبًا بمثابة نوع من التخزين يتم فيه تخزين جميع إصدارات الملفات التي نعمل بها. من الضروري هنا توضيح أن إصدارات الملفات المخزنة يتم تحديدها في أغلب الأحيان بواسطة المستخدم. لقد أجرينا، على سبيل المثال، عشرات التغييرات الصغيرة وقررنا أن الوقت قد حان لحفظ نتائج أنشطتنا في المستودع. يتبادر إلى الذهن تشبيه بالضغط بشكل دوري على Ctrl+S، مع الاختلاف الوحيد وهو أنه يمكن الوصول إلى هذا الإصدار من الملف في المستقبل. وبطبيعة الحال، يمكنك في ضربة واحدة إضافة إصدارات من أي عدد تريده من الملفات إلى المستودع. يُطلق على هذا الإجراء اسم "الالتزام" أو "إجراء التغييرات" بطريقة بسيطة.
في أي وقت، يمكنك إضافة ملف جديد أو حذف ملف موجود إلى المستودع (هذا هو ما يسمى المستودع بذكاء)، وسوف "يتذكر" VCS متى وما أضفناه/حذفناه. وبفضل التعليقات أثناء الالتزامات، يمكنك أيضًا وصف سبب تنفيذ هذا الالتزام المحدد ("أضفت قطعة حلية هناك"/"أزلت قطعة ربما تكون ضرورية من هناك").
عندما ندرك أخيرًا أن الوقت قد حان للعودة إلى الإصدار الذي كان موجودًا قبل أسبوع، أصبح لدينا تاريخ التغييرات بالكامل. وهنا يمكننا اختيار ما يجب القيام به. إذا كنت بحاجة إلى نسخ القطعة المطلوبة من ملف قديم ولصقها في الإصدار الحالي، فما عليك سوى إزالة الملف القديم من التخزين ونسخ ما تحتاجه منه. إذا كنا بحاجة إلى التراجع تمامًا ومواصلة العمل مع الإصدار القديم، فإن SKV يأتي لمساعدتنا مرة أخرى - يمكننا العودة إلى الإصدار السابق وإنشاء ما يسمى بالفرع الجديد ("الفرع")، مع الاحتفاظ بكل ما "قدمناه" up" عن طريق الرجوع إلى الإصدارات السابقة قبل أسبوع. وبالتالي، يمكن تمثيل تاريخ إصدارات المشروع بيانيًا على شكل شجرة - من "الجذور" (بداية المشروع) إلى "الفروع" (التحريرات الناجحة وغير الناجحة). بالإضافة إلى ذلك، يمكن أيضًا إنشاء "فرع" بشكل مصطنع، على سبيل المثال، في الحالة عندما نقرر تطوير نسختين مختلفتين من نفس الملفات المصدر - في الأول نعمل على بعض الحلي، وفي الثانية نعمل على الآخرين. علاوة على ذلك، إذا كانت ملفات العمل عبارة عن مستندات نصية (وفي بعضها الآخر)، فمن الممكن دمج فروع مختلفة في فرع واحد - ما يسمى بالدمج. لنتخيل الآن أن العديد من الأشخاص يعملون في المشروع، وكل منهم يعمل على "حليته" الخاصة. وجود مستودع مشترك في هذه الحالة يبسط عملية التطوير إلى حد كبير.

من النظرية إلى التطبيق، أو البدء في استخدام SLE

لذا، آمل أن أكون قد أقنعتك بأن استخدام SLE أمر جيد. كل ما تبقى هو تعلم كيفية استخدام VCS. هذا ما سنفعله
هناك أنظمة مختلفة للتحكم في الإصدار تختلف عن بعضها البعض في جوانب الاستخدام المختلفة. نظرا لأننا لسنا مهتمين (على الأقل في البداية) بتعقيدات تشغيل الأنظمة المختلفة، فسوف نركز على أبسطها وأكثرها ودية. في رأيي المتواضع، فإن مثل هذا النظام، بشكل غريب بما فيه الكفاية، هو Mercurial - "نظام تحكم في الإصدار الموزع عبر الأنظمة الأساسية مصمم للعمل بكفاءة مع مستودعات الأكواد الكبيرة جدًا" مع واجهة TortoiseHg GUI الأمامية. يمكن استخدام النظام تحت أنظمة Windows وLinux وMac OS X.
اسمحوا لي أن أقوم على الفور بالحجز الذي سأصف فيه العمل مع النظام في Windows. بالنسبة لأولئك الذين أتقنوا Linux، لن يكون من الصعب تعلم كل شيء عن طريق القياس.
بالإضافة إلى ذلك، في الوقت نفسه، سنتعلم كيفية العمل مع الاستضافة المجانية لمستودعات Mercurial - bitbucket.org، وهو أمر ضروري إذا كنت لا تعمل في مشروع بمفردك، أو، وهو أمر مريح للغاية، تريد الوصول إليه لجميع إصدارات المشروع عبر الإنترنت. في الأساس، يعد هذا بديلاً مناسبًا لصندوق الإسقاط إذا كنت قد استخدمته من قبل.
أولاً، قم بتثبيت Mercurial + TortoiseHg من هنا: tortoisehg.bitbucket.org.
يعمل هذا النظام في وحدة التحكم، لذا، ولتسهيل الاستخدام لاحقًا، سنكتب عدة ملفات *.bat للعمليات النموذجية.
يتم تنفيذ كافة العمليات بواسطة الأمر hg. يتم استدعاؤه بدون معلمات، ويعرض قائمة بالأوامر الأساسية.
المستودع هو أي دليل نختاره (سأستخدم المجلد "C:\project\")، حيث يجب تخزين جميع ملفات مشروعنا المستقبلي. بالطبع، لا أحد يمنع وجود عدة مستودعات على جهاز كمبيوتر واحد.
لكي "يفهم" النظام أننا نريد إنشاء مستودع، نقوم بتشغيل الأمر:
hg init c:\project
وبعد ذلك سيتم إنشاء المجلد "c:\project\"، إذا لم يتم إنشاؤه مسبقًا، والمجلد "c:\project\.hg\"، حيث سيقوم Mercurial بتخزين جميع معلومات الخدمة.
نتذكر على الفور أننا لا نريد الحصول على مستودع محلي على جهاز الكمبيوتر الخاص بنا فحسب، بل نريد أيضًا الحصول على مستودع بعيد سنرسل إليه جميع تغييراتنا (أو، كما يقول الأذكياء، "دفع" التغييرات إلى مستودع بعيد، من الإنجليزية "دفع"). للقيام بذلك، انتقل إلى bitbucket.org، وقم بالتسجيل وإنشاء مستودعك الأول (المستودعات - إنشاء مستودع جديد). قم بتسمية المستودع (سأسميه Remote_project ليكون محددًا) وانقر فوق إنشاء مستودع.
لدينا الآن مستودعان - أحدهما محلي، يقع في المجلد "c:\project\" والآخر بعيد، يقع في "bitbucket.org/your_account_name/remote_project/"، حيث يكون your_account_name هو الاسم المحدد عند التسجيل في bitbucket، Remote_project هو اسم المستودع الذي تم تحديده عند إنشائه.
من أجل مواصلة الاستكشاف، نحتاج إلى دفع شيء ما إلى مستودعنا المحلي. ما عليك سوى إنشاء أي ملف لمشروعك المستقبلي فيه (في حالتي، في المجلد "c:\project\") أو انسخ مشروعك الحالي هناك.
الآن، بالمعنى الدقيق للكلمة، نحتاج إلى إخبار Mercurial: "لقد أضفنا ملفات كذا وكذا ومجلدين جديدين إلى مجلد المشروع"، يتم توفير الأمر "hg add" لهذا الغرض. ومع ذلك، هناك طريقة أخرى أكثر ملاءمة - في الالتزام التالي، سنطلب من Mercurial التقاط جميع الملفات التي تم إنشاؤها حديثًا من مجلد المشروع ونسيان الملفات المحذوفة، وهذا أسهل بكثير من القيام بـ "hg add c:\project\new_document" .doc" في كل مرة تقوم فيها بإنشاء مستند جديد "
لذلك، دعونا ننتقل إلى التزامنا الأول. يتم تنفيذه باستخدام الأمر التالي:
التزام hg –A –m “تعليق للالتزام”
دعونا ننظر إلى كل شيء بالترتيب. يجب إدخال الأمر عندما نكون في المستودع (أي أنه يجب علينا أولاً تنفيذ "cd c:\project"). يعد الخيار "-A" ضروريًا لـ Mercurial "لالتقاط" الملفات التي تم إنشاؤها حديثًا (انظر أعلاه)، ويسمح لك الخيار "-m" بإضافة تعليق إلى الالتزام. سيتم عرض هذه التعليقات عند عرض الإصدارات (أو مجموعات التغييرات - قوائم التغييرات) في TortoiseHg وعلى صفحة المشروع في bitbucket.org. من المهم جدًا تقديم تعليقات ذات مغزى حتى لا تعاني لاحقًا، وتذكر متى تم إجراء هذا التعديل أو ذاك.
الآن يقوم مستودعنا بتخزين الإصدار الأولي لمشروعنا. يتم تنفيذ كافة الالتزامات الإضافية بنفس الطريقة بعد أن نقرر أن الوقت قد حان لحفظ الإصدار الحالي.
يمكن "دفع" الالتزام المكتمل إلى المستودع البعيد باستخدام الأمر:
دفع الزئبق https://bitbucket.org/your_account_name/remote_project
في هذه الحالة، يجب أيضًا أن تكون في المجلد المقابل للمستودع. بعد إدخال الأمر، سيطلب منك الاسم وكلمة المرور الخاصة بحسابنا على bitbucket.org، حتى لا تدخلهما مع كل ضغطة، يمكن استبدال الأمر بما يلي:
دفع hg دفع hg https://your_account_name:[email protected]/your_account_name/remote_project
نظرًا لأننا سنكتب جميع الأوامر في ملف *.bat، ففي هذه الحالة سيتم تخزين كلمة المرور بنص واضح، مما يشكل نوعًا من المخاطر الأمنية، لكنه مقبول بالنسبة لي.
لذلك، من أجل الراحة، نقوم بإنشاء ملفات التزام.bat، وpush.bat، وcommit&push.bat في منطقة الوصول المباشر بالمحتوى التالي:
[محتويات ملف الالتزام.bat]
إذا !%1==! انتقل إلى الخروج 1
القرص المضغوط C:\project
التزام hg -A -m "%*"
انتقل إلى الخروج0
:خروج1
صدى "لا يوجد أرج سطر الأوامر!"
:خروج0
هذا الملف، الذي يتم استدعاؤه بالوسائط، سيلزم المشروع بالوسائط المضمنة في التعليقات على الالتزام. على سبيل المثال: قم بتنفيذ "commit.bat التزامي الأول" واحصل على التزام مع التعليق "التزامي الأول". في FAR، من الملائم استخدام مجموعة Ctrl+Enter لهذا الغرض.
[محتويات ملف Push.bat]
القرص المضغوط C:\project
دفع الزئبق https://your_account_name:[email protected]/your_account_name/remote_project
سيتم دفع هذا الملف إلى المستودع البعيد.
[محتويات الملف الالتزام&push.bat]
إذا !%1==! انتقل إلى الخروج 1
القرص المضغوط C:\project
التزام hg -A -m "%*"
انتقل إلى الخروج0
:خروج1
صدى "لا يوجد أرج سطر الأوامر!"
:خروج0
اتصل ./push.bat
هذا الملف، الذي يتم استدعاؤه باستخدام الوسائط، سيقوم بتنفيذ التزام متسلسل ودفع المشروع باستخدام الوسائط المدخلة في التعليقات على الالتزام.
بالإضافة إلى ذلك، بالنسبة للالتزامات المتوسطة الصغيرة، أوصي بإنشاء ملف التزام_تاريخ_وقت.بات:
[محتويات الملف الالتزام_date_time.bat]
القرص المضغوط C:\project
التزام hg -A -m "%DATE% %TIME%"
سيتم حفظ هذا الملف بالتاريخ والوقت الحاليين كتعليق، وهو أمر مناسب غالبًا.
يقرر الجميع عدد مرات الالتزام والدفع بشكل فردي، اعتمادًا على شدة التعديلات التي يتم إجراؤها وتعقيدها. على الرغم من أنه يوصى باتباع قاعدة "في كثير من الأحيان يكون أفضل".
من خلال النقر بزر الماوس الأيمن على ملف/مجلد المستودع، يمكنك تشغيل مستكشف المستودع (TortoiseHg - Repository Explorer)، الذي يعرض جميع التزاماتنا مع التعليقات عليها. تعرض هذه النافذة البنية الشجرية لمستودعنا، ومن هنا يمكنك تنفيذ عمليات الالتزام والدفع والتراجع إلى الإصدارات السابقة (النسخ الاحتياطي) والعمليات الأخرى.
يوجد في bitbucket.org/your_account_name/remote_project مجموعة مماثلة من مجموعات التغييرات، ويمكنك تنزيل أي إصدار من المشروع في أرشيف واحد، وهو أمر مريح جدًا في بعض الأحيان.
بشكل عام، أنا أعتبر هذا نهاية التعارف الأولي مع Mercurial. لمزيد من المعلومات التفصيلية، يرجى زيارة الموقع التالي:translator.by/you/mercurial-the-definitive-guide/into-ru/trans/

لمن هذه المقالة؟

ربما سأنتهي بما كان يجب أن أبدأ به – لمن هذه المقالة؟ الجواب بسيط - لأولئك الذين يريدون تعلم كيفية استخدام العملة الصعبة. تمكنت من جذب العديد من المصممين والمهندسين وحتى الكاتب إلى VCS. جربه أيضًا - فمن المحتمل أن يجعل هذا عملك أسهل بكثير.

ملاحظة: تم النقل إلى مدونة "أنظمة التحكم في الإصدار".

العلامات:

• أنظمة التحكم في الإصدار
• زئبقي
• bitbucket

اضف اشارة

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

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

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

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

لحل هذه المشكلة، قام المبرمجون منذ فترة طويلة بتطوير أنظمة VCS محلية بقاعدة بيانات بسيطة يتم فيها تخزين جميع التغييرات في الملفات الضرورية (انظر الشكل 1-1).

الشكل 1-1. مخطط SLE المحلي.

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

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

كان التحدي الرئيسي التالي هو الحاجة إلى التعاون مع المطورين على أجهزة كمبيوتر أخرى. لحل هذه المشكلة، تم إنشاء أنظمة التحكم في الإصدار المركزي (CVCS). تمتلك مثل هذه الأنظمة، مثل CVS، وSubversion، وPerforce، خادمًا مركزيًا يقوم بتخزين جميع الملفات تحت التحكم في الإصدار، وعدد من العملاء الذين يتلقون نسخًا من الملفات منه. لقد كان هذا هو المعيار لأنظمة التحكم في الإصدار لسنوات عديدة (انظر الشكل 1-2).

الشكل 1-2. نظام التحكم في الإصدار المركزي.

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

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

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

وفي هذه الحالة، يأتي دور أنظمة التحكم في الإصدار الموزع (DVCS). في أنظمة مثل Git أو Mercurial أو Bazaar أو Darcs، لا يقوم العملاء ببساطة بفحص أحدث الإصدارات من الملفات، بل يقومون بنسخ المستودع بأكمله. لذلك، في حالة "وفاة" الخادم الذي كان يتم العمل من خلاله، يمكن نسخ أي مستودع عميل مرة أخرى إلى الخادم لاستعادة قاعدة البيانات. في كل مرة يقوم فيها العميل بفحص أحدث إصدار من الملفات، يقوم بإنشاء نسخة كاملة من جميع البيانات لنفسه (انظر الشكل 1-3).

الشكل 1-3. رسم تخطيطي لنظام التحكم في الإصدار الموزع.

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

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

ما هو نظام التحكم في الإصدار؟

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

لحل هذه المشكلات، يتم استخدام نظام التحكم في الإصدار، فهو يسمح لك بالعمل بشكل مريح في المشروع سواء بشكل فردي أو ضمن فريق. VCSيتتبع التغييرات في الملفات، ويوفر فرصًا لإنشاء فروع جديدة ودمج الفروع الحالية للمشروع، ويتحكم في وصول المستخدم إلى المشروع، ويسمح لك باستعادة التصحيحات وتحديد من ومتى وما هي التغييرات التي تم إجراؤها على المشروع. المفهوم الرئيسي VCSهو المستودع ( مخزن) – مخزن خاص لملفات ومجلدات المشروع، والتي يتم تتبع التغييرات فيها. لدى المطور تحت تصرفه ما يسمى "نسخة العمل" ( نسخة العمل) للمشروع الذي يعمل به مباشرة. يجب أن تتم مزامنة نسخة العمل بشكل دوري مع المستودع؛ تتضمن هذه العملية إرسال التغييرات التي أجراها المستخدم على نسخة العمل الخاصة به (تسمى هذه العملية يقترف) وتحديث نسخة العمل، حيث يتم خلالها تنزيل أحدث إصدار من المستودع إلى المستخدم (تسمى هذه العملية تحديث).

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

يمكن تقسيم أنظمة التحكم في الإصدار إلى مجموعتين: موزعة ومركزية.

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

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

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

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

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

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

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

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

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

كانت هذه محاضرة تمهيدية عن أنظمة التحكم في الإصدار. في ما يلي، كل العرض سوف يتعلق فقط شخص سخيف.

إذا كنت تفضل تعلم من محاضرات الفيديو، فإننا نوصي بدورة تدريبية رائعة حول شخص سخيفمن GeekBrains ، اذهب إلى وصلةوابحث عن الدورة التدريبية في قسم "الدورات التدريبية". “شخص سخيف. بداية سريعة". هو حر، ما عليك سوى التسجيل في الموقع. نوصي بإلقاء نظرة فاحصة على هذا المورد؛ فهو يحتوي على الكثير من الأشياء المثيرة للاهتمام!

هل لديك فكرة عمل جديدة رائعة تتعلق بتطوير البرمجيات؟هل تحتاج إلى تطوير حل معقد من الناحية التكنولوجية؟ أو هل لديك فريق كبير من المبرمجين الذين يعملون على نفس المهمة؟ ثم تذكر هذه الكلمات الثلاث:نظام التحكم في الإصدار .

نظام التحكم في الإصدار (cvs)، 2017 - قارن: Git، SVN، Mercurial

, أو vcs- وهذا ما يمنع المشروع من الانهيار عندما يكون هناك الكثير من الأشخاص الذين يعملون عليه. يمكن لكل من المبرمجين والمديرين ومؤلفي النصوص العمل على قطعة خاصة بهم دون التدخل في بعضهم البعض ودون التسبب في أضرار لا يمكن تصحيحها.

إذا لم تكن على دراية بهذا المفهوم بعدأنظمة التحكم في الإصدار، ثم هنا كل شيء يظهر بوضوح شديد.

أو شاهد الفيديو من GitHub.

إذًا ما هو نظام التحكم في الإصدار المناسب لمشروعك؟

لقد قمنا بمقارنة العديد من الحلول الشائعة لتسهيل الاختيار عليك.

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

أنظمة التحكم في الإصدار، بما في ذلك SVN (Subversion) وGit المشهورين، تم إنشاؤها في الأصل للسماح لفرق المطورين بالعمل في مشاريع تعاونية دون خلق أي ارتباك. في نظام التحكم، لا تحتاج إلى تتبع فروع التعليمات البرمجية بشكل مستقل ودراسة الملاحظات عليها. بدلاً من ذلك، يتم استخدام مستودع مركزي حيث يتم تنظيم كل شيء وتنظيمه. من السهل تحديث الملفات وإضافة التعليقات وحتى دمج فروع المشروع.

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

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

ومن الجدير أيضًا أن نأخذ في الاعتبار السرعة والوظيفة والعتبة للدخول/إتقان شيء معينأنظمة التحكم. دعونا ننظر إلى الأكثر شيوعاأنظمة التحكم في الإصداروأسباب تفضيل المبرمجين لحلول معينة.

نظام الإصدار المتزامن (CVS)

CVS ظهرت في الثمانينيات وما زالت تحظى بشعبية كبيرة بين مطوري المنتجات التجارية ومطوري المصادر المفتوحة.

CVS موزعة بموجب الشروطاتفاقية ترخيص GNU المفتوحة وتسمح لك بالحصول على الإصدار المطلوب من المشروع من الخادم - "تسجيل الخروج" (مقتطف) ، ثم أرسله مرة أخرى إلى الخادم، "تسجيل الوصول" (العودة) ،مع التغييرات التي تم إجراؤها.

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

الآن CVS لديه دعم للعمل في المشاريع ذات فروع التعليمات البرمجية. وينتج عن ذلك العديد من خيارات المنتجات ذات الخصائص المختلفة التي يمكن دمجها لاحقًا.

خوادم CVS تعمل عادة تحت يونيكس، ولكن CVS -العملاء متوفرون أيضًا في أنظمة التشغيل الشائعة الأخرى. CVS - "ناضج" ، تم اختباره عبر الزمننظام التحكم في الإصدار. لا يزال نظامًا مفتوح المصدر، ولكن نادرًا ما تتم إضافة ميزات جديدة اليوم.

وفي الوقت نفسه، CVSNT هو إصدار منفصل في مشروع منفصل CVS لخوادم Windows - تعمل الآن على توسيع وظائفها بنشاط كبير.

مزايا:

• التكنولوجيا التي تم اختبارها عبر الزمن والتي كانت موجودة في السوق منذ عقود.

عيوب:

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

تخريب أباتشي (SVN)

SVN تم إنشاؤه كبديل CVS من أجل تصحيح أوجه القصور CVS وفي نفس الوقت ضمان التوافق العالي معها.

مثل CVS SVN هو نظام مجانيالتحكم في الإصدار مفتوح المصدر. والفرق الوحيد هو أنه يتم توزيعه بموجب ترخيص Apache، وليس بموجب ترخيص Apacheبموجب اتفاقية الترخيص العامة GNU.

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

لقد تحول العديد من المطورين إلىSVN، حيث ترث التكنولوجيا الجديدة ميزات أفضل CVS وفي الوقت نفسه توسيعها.

أثناء وجوده في CVS العمليات مع فروع التعليمات البرمجية باهظة الثمن ولا يتم توفيرها بواسطة بنية النظام؛ تم إنشاء SVN لهذا الغرض فقط. وهذا يعني بالنسبة للمشاريع الأكبر حجمًا التي تحتوي على تفرع التعليمات البرمجية والعديد من مجالات التطوير.

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

مزايا:

• قائم على النظام CVS
• يسمح بالعمليات الذرية
• عمليات تفرع التعليمات البرمجية أقل تكلفة
• مجموعة واسعة من ملحقات IDE
• لا يستخدم نموذج نظير إلى نظير

عيوب:

• الأخطاء لا تزال قائمة المتعلقة بإعادة تسمية الملفات والدلائل
• مجموعة أوامر غير مرضية للعمل مع المستودع
• سرعة منخفضة نسبيا

شخص سخيف

تم إنشاء هذا النظام لإدارة تطوير Linux kernel ويستخدم أسلوبًا مختلفًا تمامًا عن CVS وSVN.

الاساسيات شخص سخيف تم وضع المفاهيم لتوزيعها بشكل أسرعنظام التحكم في الإصدار، على عكس القواعد والحلول المستخدمة في CVS . نظرًا لأنه تم تطوير Git بشكل أساسي لنظام التشغيل Linux، فهو يعمل بشكل أسرع على نظام التشغيل هذا.

يعمل Git أيضًا على أنظمة تشبه Unix (مثل MacOS)، ويتم استخدام حزمة mSysGit للتشغيل على نظام Windows الأساسي.

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

يحتوي Git أيضًا على العديد من الأدوات للتنقل في سجل التغييرات. تحتوي كل نسخة عمل من التعليمات البرمجية المصدر على تاريخ التطوير بأكمله، وهو أمر مفيد للغاية عند البرمجة دون اتصال بالإنترنت.

مزايا:

• عظيم لأولئك الذين يكرهون CVS/SVN
• زيادة كبيرة في الأداء
• عمليات رخيصة مع فروع الكود
• تاريخ التطوير الكامل متاح دون اتصال بالإنترنت
• النموذج الموزع من نظير إلى نظير

عيوب:

• حاجز مرتفع أمام الدخول (التعلم) لأولئك الذين سبق لهم استخدام SVN
• دعم محدود لنظام التشغيل Windows (مقارنة بنظام التشغيل Linux)

زئبقي

زئبقي تم إصداره في نفس وقت إصدار Git. هو نفسهوزعت نظام التحكم في الإصدار.

تم إنشاء Mercurial كبديل لـ Git لتطوير وحدات Linux kernel. ولكن بما أننا اخترنا Git، فقد تم استخدام Mercurial بشكل أقل. ومع ذلك، يعمل العديد من المطورين الرائدين مع هذا النظام، على سبيل المثالOpenOffice.org .

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

نظرًا لأن النظام لا مركزي ومكتوب بلغة بايثون، فإن العديد من مبرمجي بايثون يميلون إلى التحول إلى ميركوريال.

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

أحد العيوب الهامة لـ Mercurial هو أنه، على عكس Git، لا يمكنه دمج فرعين رئيسيين، حيث أن Mercurial يستخدم نظام المكونات الإضافية بدلاً من دعم البرنامج النصي. يعد هذا أمرًا رائعًا لبعض المبرمجين، لكن الكثير منهم لا يريدون التخلي عن قوة Git.

مزايا:

• أسهل للتعلم مقارنة بـ Git
• وثائق مفصلة
• النموذج الموزعأنظمة التحكم في الإصدار

عيوب:

• لا يوجد خيار لدمج الفرعين الأصليين
• استخدام المكونات الإضافية بدلاً من البرامج النصية
• فرص أقل للحلول غير القياسية

أيّالتحكم في الإصدار يعمل بالنسبة لي?

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

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

اليوم SVN يحمل راحة اليد بين خوادم الخادمأنظمة التحكم في الإصدار. ويشمل الفوائد CVS ويتفوق عليهم. إذا كنا نتحدث عن انتشار، فمن المرجح أن تواجه في كثير من الأحيان CVS أو SVN مقارنة بـ Git أو Mercurial. لذا، فإن المعرفة بتكنولوجيا خادم واحد، على الرغم من أنها ليست ضرورية، ستسهل عملية الانتقال.

نظرًا للاستخدام الواسع النطاق ونضج التكنولوجيا، تتمتع SVN بقاعدة معرفية كبيرة، مما يسهل على المستخدمين الحصول على المساعدة.

من الواضح أن Git أسرع من منافسيه. بالنسبة للمشاريع التي تم إنشاؤها للتوزيعأنظمة التحكم في الإصدار، وهذا تحسن واضح.

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

بالنسبة لأولئك الذين يكرهون Git (ولديها منتقدون بين المطورين)، فإن Mercurial هو حل وسط بين SVN وGit. يُستخدم هذا النظام في العديد من المشاريع الشهيرة كما أنه يتمتع بتوثيق جيد.

يتقدم إصدار Git المتوافق مع Windows أيضًا نحو سرعة إصدار Linux، لذلك قد يكون مناسبًا لك حتى إذا لم تقم بالتطوير على Linux.

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

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

إذا كنت تطلق مشروعًا مفتوح المصدر سيعمل عليه العديد من المبرمجين في أوقات مختلفة أو إذا كنت تخطط لتحديث الكود باستمرار، فاختر Git. تعد إدارة السرعة وشجرة المصدر أفضل بكثير هنا مما كانت عليه في SVN.

إذا كنت على مفترق طرق أو لا تحب الطريقة التي يعمل بها SVN أو Git، فإن Mercurial هو الخيار المناسب لك.

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

بادئ ذي بدء، تقرر ما إذا كان واحدا أو آخر مناسبانظام التحكمإصدارات لعملك، وبعد ذلك - بنفس القدر من الأهمية - تأكد من أن هذا الاختيار لن يثير حفيظة المبرمجين.

الشروع في العمل مع SVN

إذا لم يسبق لك العمل مع SVN أو Git وليس لديك أي فكرة عن كيفية البدء، إذنحل الاستضافة مدمج مع واجهة المستخدم الرسوميةسوف تساعدك على التعود عليه بسرعة.

كما هو الحال في معظم الحالات، فإن الشيء الأكثر أهمية هو البدء في العمل، وبعد ذلك سيأتي الفهم. يشبه تشغيل نظام التحكم في الإصدار إلى حد كبير العمل مع الملفات الموجودة على الخادم باستخدام عميل FTP.

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

استضافة SVN وGIT

إنشاء المستودع الأول

بعد إنشاء الحساب، تحتاج إلى إنشاء مستودع - لكل منصة على حدة. عادة ما يبدو مثل هذا:

• قم بتسجيل الدخول إلى حسابك، ثم انقر على مشاريعك.
• إنشاء مشروع:

• في سطر "إنشاء مشروع جديد"، أدخل اسم مشروعك
• انقر على زر "إنشاء مشروع".

• اتصال SVN:

• بعد إنشاء المشروع، حدد علامة التبويب "التحكم في المصدر" (إصدارات التعليمات البرمجية المصدر)
• انقر على الرابط "تمكين التحكم بالمصدر"
• أعط المستودع اسمًا
• انقر فوق "حفظ"

العملاء الرسوميين SVN وGIT

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

—برنامج مناسب للعمل معأنظمة التحكم في الإصدارعلى نظام التشغيل Microsoft Windows وربما يكون أفضل عميل متاح لـ Apache Subversion. يتم تنفيذ TortoiseSVN كملحق لـ Windows Shell، مما يجعل من السهل الاندماج فيه browser. وهو أيضًا برنامج مفتوح المصدر مع 34 حزمة لغة متاحة

سمارتجيت

– عميل Git الرسومي (مفتوح المصدر موزعنظام التحكم في الإصدار). يعمل على أنظمة التشغيل Windows وMac OS X وLinux.تكلفة الترخيص - 39 دولارًا

"التحقق من" المستودع ("الدفع")

لذلك، تم اختيار العميل. أنت الآن بحاجة إلى إنشاء مستودع لنظام التحكم. بحاجة للدخولعنوان URL للمستودع الخاص بك واسم المستخدم وكلمة المرور.

عادةً ما يبدو عنوان URL كما يلي:https://svn .hostname.com/svn/ > (يمكنك استخدام https:// (SSL) إذا كان لديك حساب مدفوع)

1. انتقل إلى المجلد الجذر، وانقر فوق الزر "سحب" وقم بإنشاء مجلد عمل للعميل. الآن يمكنك إضافة الملفات إليه.
2. بمجرد استخراج ملفات المشروع، يمكنك تحريرها في دليل محلي على جهاز الكمبيوتر الخاص بك.

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

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