البحث في الموقع

نظام التحكم بالإصدارات Gitإن Git هو نظام تحكم بالإصدارات موزَّع (distributed) ومفتوح المصدر مطوَّر من لينوس تورفالدس لدعم تطوير نواة لينُكس؛ حيث يكون كل مجلد في Git عبارة عن مستودع مع تأريخ كامل وإمكانيات لتتبع الإصدارات، وليس متعمِدًا على الوصول على الشبكة أو على خادوم مركزي. التثبيتيمكن تثبيت نظام التحكم بالإصدارات git باستخدام الأمر الآتي: sudo apt-get install gitالضبطيجب لكل مستخدم git أن يعرِّف نفسه أولًا إلى git، وذلك بتنفيذ الأمرّين الآتيين: git config --global user.email "you@example.com" git config --global user.name "Your Name"الاستخدام الأساسيما سبق يكفي لاستخدام git في طريقة موزعة وآمنة، حيث يُفترَض أنَّ المستخدمين يستطيعون الوصول إلى الخادوم عبر SSH؛ حيث يمكن إنشاء مستودع جديد على الخادوم بالأمر: git init --bare /path/to/repositoryملاحظة: الأمر السابق يُنشِئ مستودعًا «فارغًا» (bare)، أي أنه ليس بالإمكان استخدامه للتعديل على الملفات مباشرةً. إذا أردت الحصول على نسخة من محتويات المستودع على الخادوم، فاحذف الخيار ‎--bare. يمكن لأي عميل يملك وصولًا عبر SSH إلى الخادوم أن ينسخ المستودع بالأمر: git clone username@hostname:/path/to/repositoryبعد نسخ الملفات إلى جهاز العميل، يمكنه تعديلها ثم إيداعها ومشاركتها بالأوامر: cd /path/to/repository # edit some files git commit -a # Commit all changes to the local version of the repository git push origin master # Push changes to the server's version of the repositoryتثبيت خادوم gitoliteعلى الرغم من أنّ ما سبق كافٍ لإنشاء ونسخ وتعديل المستودعات، لكن المستخدمين الذين يريدون تثبيت git على خادوم سيريدون عمومًا إنجاز المهام في git كنظام إدارة التحكم بالأكواد المصدرية تقليدي؛ وعند وجود عدِّة مستخدمين وامتيازات وصول لهم، فالحل الأمثل هو تثبيت gitolite كما يلي: sudo apt-get install gitoliteضبط Gitoliteضبط خادوم Gitolite مختلف قليلًا عن معظم الخواديم في الأنظمة الشبيهة بِيونكس؛ فبدلًا من ملفات الضبط التقليدية في ‎/etc/‎، فإن gitolite يُخزِّن الضبط في مستودع git؛ أول خطوة لضبط تثبيت جديد هي السماح بالوصول إلى مستودع الضبط. أولًا، علينا إنشاء مستخدم لأجل gitolite لكي نصل إليه عبره: sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git gitسنترك الآن gitolite لكي يعرف عن مفتاح SSH العمومي لمدير المستودع؛ هنا نفترض أن المستخدم الحالي هو مدير المستودع؛ إذا لم تضبط مفتاح SSH بعد، فراجع الدرس الخاص بخادوم OpenSSH لمزيدٍ من التفاصيل: cp ~/.ssh/id_rsa.pub /tmp/$(whoami).pubلنبدِّل إلى المستخدم git ونستورد مفتاح المدير إلى gitolite: sudo su - git gl-setup /tmp/*.pubسيسمح Gitolite لك بعمل تغيرات مبدئية لضبطه أثناء عملية الإعداد؛ يمكنك الآن نسخ وتعديل مستودع ضبط gitolite من المستخدم المدير (المستخدم الذي استوردت مفتاح SSH العمومي الخاص به)؛ عُد إلى ذاك المستخدم، ثم انسخ مستودع الضبط: exit git clone git@$IP_ADDRESS:gitolite-admin.git cd gitolite-adminالمجلد gitolite-admin فيه مجلدين فرعيين، المجلد «conf» و «keydir»؛ ملفات الضبط موجودة في مجلد conf، ويحتوي مجلد keydir على مفاتيح SSH العمومية للمستخدم. إدارة مستخدمي ومستودعات gitoliteإضافة مستخدمين جدد إلى gitolite هي عملية سهلة: احصل على مفتاح SSH العمومي لهم ثم أضفه إلى مجلد keydir بالاسم USERNAME.pub، لاحظ أن أسماء مستخدمي gitolite لا تطابق بالضرورة أسماء مستخدمي النظام، حيث تُستخدَم أسمائهم في ملف ضبط gitolite فقط، وذلك لإدارة التحكم بالوصول؛ وبشكل مشابه، يمكن حذف المستخدمين بحذف ملف المفتاح العمومي الخاص بهم؛ ولا تنسَ أن تودع التغييرات وتدفعها إلى خادوم git بعد كل تعديل: git commit -a git push origin masterتُدار المستودعات بتعديل الملف conf/gitolite.conf؛ الشكل العام له هو قيود مفصولة بفراغات تُحدِّد ببساطة قائمةً بالمستودعات ثم بعض قواعد الوصول؛ ما يلي هو المثال الافتراضي لهذا الملف: repo gitolite-admin RW+ = admin R = alice repo project1 RW+ = alice RW = bob R = deniseاستخدام خادومكلاستخدام الخادوم المُنشَأ حديثًا، يجب أن يستورد مدير gitolite مفاتيح المستخدمين العمومية إلى مستودع ضبط gitolite، ثم يمكنهم الوصول إلى أي مستودع لهم حق الوصول إليه عبر الأمر الآتي: git clone git@$SERVER_IP:$PROJECT_NAME.gitأو إضافة مشروع في الخادوم عن بعد: git remote add gitolite git@$SERVER_IP:$PROJECT_NAME.gitترجمة -وبتصرف- للمقال Ubuntu Server Guide: Git.

ما هو نظام التحكّم في النسخ Git، ولماذا حرّي بك أن توليه اهتماما؟ إن التحكّم في النّسخ، هو نظام يسجل التغيرات التي تحدث عبر الزمن على ملف أو مجموعة ملفات بحيث يمكنك الرجوع إلى مرحلة معينة (إصدار) لاحقًا. عمليا، يمكنك أن تقوم بهذا على جُل أنواع ملفات الحاسوب. إذا كنت تعمل كمصمم رسوميات أو ويب، مبرمج أو ما شابه وتريد طريقة لمتابعة جميع الإصدارات والتعديلات التي تجريها على صورة أو قالب ما (الأمر الذي سيعجبك بالتأكيد)، فإنه من الحكمة استعمال نظام إدارة الإصدارات VCS. حيث يمكّنك من إرجاع الملفات إلى حالٍ كانت عليه سابقًا، أو إرجاع مشروع بأكمله، يمكنك أيضًا مقارنة التغيرات الحاصلة مع مرور الزمن، أو معرفة من قام بآخر تعديل قد يكون سبب خطأ ما، من أشَارَ إلى خطْبٍ ما ومتى، وغيرهم المزيد. استخدامك لنظام إدارة الإصدارات يعني أيضًا أنه إذا قمت بعبث وتبعثرت أشياء، أو خسرت ملفات المشروع لسبب ما، يمكنك استرجاعها إلى حالها بسهولة. بل وبأدنى مشقة منك. أنظمة إدارة إصدارات المصدر المحلية الطريقة المثلى لدى كثير من الناس في التحكّم النسخ، هي نَسخ الملفات في مجلد مغاير (قد يكون مُعّلما بالزمن، في حالة كان الشخص حذِقا). هذا النهج منتشر بكثرة لبساطته، لكنه وبشكل مفرط، مَدعاة للغلط. فمن السهل نسيان أيٌ من المجلدات أنت فيها فتكتب عن غير قصد في الملف الخطأ، أو تنسخ فوق ملفات لم تكن تعنيها. للتعامل مع هذا المشكل، عمل المبرمجون قديما على تطوير VCSs مزودة بقاعدة بيانات بسيطة تحفظ جميع التغيرات التي تطرأ على الملفات التي هي تحت إدارة المراجعة (انظر الصورة). إحدى أدوات VCS الأكثر شعبية كان نظاما تدعى rcs والتي لا تزال تُوّزع مع العديد من حواسيب اليوم. حتى نظام OS X المشهور يحوي أمر rcs عند تنصيبك لأدوات المطور، تعمل هذه الأداة أساسا بحفظ مجموع الرقع (أي الاختلافات الحاصلة بين الملفات) بين كل عملية تغيير واحدة ومثيلتها في هيئة خاصة على القرص الصلب، يمكنها بهذا إعادة إنشاء أي ملف بنفس الهيئة التي كان عليها في نقطة ما من الزمن عن طريق دمج الرقع. أنظمة إدارة إصدارات المصدر المركزية المشكل الكبير التالي الذي واجه المستخدمين هو حاجتهم إلى التعاون مع مُبرمجين آخرين على أنظمة تشغيل أخرى. ولحل هذا المُشكل تم تطوير أنظمة لإدارة إصدارات المصدر مركزية (CVCSs). تستخدم هذه الأنظمة، مثل كل من CVS ،Subversion أو Perforce خادوما واحدا يحتوي كل الملفات التي نقوم بإدارة إصداراتها، إضافة إلى مجموعة من العملاء الذين يقومون باسترجاع الملفات من هذا الخادوم المركزي. ظلت هذه الأنظمة لسنوات عديدة المعيار القياسي لأنظمة إدارة إصدارات المصدر. توفر هذه الأنظمة مزايا عديدة خاصة إذا ما قارناها بأنظمة إدارة الإصدارات المحلية، فعلى سبيل المثال يُمكن للجميع –إلى حد مُعين من الدقة- معرفة ما الذي يقوم به الجميع على المشروع، كما أن للمدراء القدرة على التحكم بشكل دقيق فيما يُمكن لأي مشارك أن يقوم به. دون أن ننسى أنه من الأسهل التعامل مع نظام إدارة إصدارات مركزي مقارنة مع إدارة قواعد بيانات على جهاز كل مشارك. في المقابل، تأتي هذه الأنظمة مرفقة ببعض العيوب والتي قد يكون أخطرها هو اعتماد النظام على نقطة مركزية وحيدة، فإن تعطل الخادوم لساعة من الزمن، فإنه من غير المُمكن لأي كان أن يتشارك التحديثات التي تمت خلال تلك الفترة. أما لو تعرض القرص الصلب على الخادوم لعطب، فإنه -ما لم يتم أخذ نسخ احتياط قبل حصول ذلك- فإن احتمال فقدان المشروع بكامل تاريخه أمر وارد جدا، باستثناء النسخ المحلية المتواجدة على أجهزة المتعاونين في المشروع. أنظمة إدارة الإصدارات الموزعة ولمثل هذه الأوضاع ظهرت أنظمة إدارة الإصدارات المُوزعة (DVCSs). في مثل هذه الأنظمة كـ Git ،Mercurial ،Bazaar أو Darcs فإن ما يقوم به المستخدمون ليس مُجرد التحقق من آخر إصدار للملفات، لكن يقومون بإخذ نسخ كاملة عن المستودعات التي يعملون عليها. وعليه، فإن تعرض الخادوم لأي خلل فإنه يُمكن مواصلة العمل عبر نسخ المستودع الموجود على أي من أجهزة المستخدمين بحكم أن أي عملية تحقق يقوم بها المستخدم هي عبارة عن عملية نسخ احتياطي كامل لكامل بيانات المشروع (انظر الصورة التالية). وعلاوة على ذلك، فإن العديد من هذه الأنظمة المُوزعة تتعامل بشكل جيد مع المشاريع التي تملك عدة مستودعات تعمل عليها مجموعات مختلفة من المستخدمين بطرق مختلفة وضمن نفس المشروع. هذا الأمر يسمح باعتماد مهام لسير العمل لم يكن بالإمكان اعتمادها على الأنظمة المركزية مثل النماذج الهرمية. ترجمة -وبتصرف- لـ About Version Control من كتاب Pro Git لصاحبه Scott Chacon.

إن CVS هو خادوم تحكم بالإصدارات؛ تستطيع استخدامه لتسجيل تاريخ ملفات المصدر. التثبيتنفِّذ الأمر الآتي في الطرفية لتثبيت CVS: sudo apt-get install cvsبعد تثبيت cvs، يجب عليك تثبيت xinetd لتشغيل أو إيقاف خادوم cvs؛ وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install xinetdالضبطبعد أن تثبت cvs، فإنه سيُهيّء مستودعًا تلقائيًا؛ يقبع المستودع افتراضيًّا في مجلد ‎/srv/cvs؛ ويمكنك تغيير هذا المسار بتنفيذ الأمر الآتي: cvs -d /your/new/cvs/repo initتستطيع ضبط xinetd لبدء خادوم CVS بعد أن يُضبَط المستودع الابتدائي؛ يمكنك نسخ الأسطر الآتية إلى ملف ‎/etc/xinetd.d/cvspserver: service cvspserver { port = 2401 socket_type = stream protocol = tcp user = root wait = no type = UNLISTED server = /usr/bin/cvs server_args = -f --allow-root /srv/cvs pserver disable = no }ملاحظة: تأكد أن تعدِّل المستودع إذا غيرت مجلد المستودع الافتراضي (‎/srv/cvs). بعد أن تضبط xinetd؛ يمكنك بدء خادوم CVS بإدخال الأمر الآتي: sudo service xinetd restartيمكنك التأكد من عمل خادوم CVS بإدخال الأمر الآتي: sudo netstat -tap | grep cvsيجب أن ترى مخرجاتٍ شبيهةً بالمخرجات الآتية بعد تنفيذ الأمر السابق: tcp 0 0 *:cvspserver *:* LISTENمن هنا يمكنك المتابعة في إضافة المستخدمين والمشاريع الجديدة وإدارة خادوم CVS. تحذير: يسمح CVS للمستخدم بإضافة مستخدمين بشكل مستقل عن نظام التشغيل؛ وربما أسهل طريقة هي استخدام مستخدمي لينُكس لخادوم CVS، على الرغم من أن لها مساوئ أمنية؛ راجع دليل CVS للتفاصيل. إضافة مشاريعيشرح هذا القسم كيفية إضافة مشاريع جديدة إلى مستودع CVS؛ أنشِئ مجلدًا وأضف المستندات والملفات المصدرية إليه؛ ثم نفِّذ الأمر الآتي لإضافة هذا المشروع إلى مستودع CVS: cd your/project cvs -d :pserver:username@hostname.com:/srv/cvs import -m "Importing my project to CVS repository" . new_project startتنويه: يمكن استخدام متغير البيئة CVSROOT لتخزين المجلد الجذر لخادوم CVS؛ يمكنك تجنب استخدام الخيار ‎-d في أمر cvs السابق بعد أن «تُصدِّر» (export) متغير البيئة CVSROOT. السلسلة النصية new_project هي وسم «vendor»، و start هي وسم «release»، لا يخدمان أي هدف في هذا السياق، لكن ولما كان خادوم CVS يتطلب وجودهما؛ فيجب أن تضعهما. تحذير: عندما تضيف مشروعًا جديدًا، فيجب أن يملك مستخدم CVS إذن الوصول إلى مستودع (CVS (/srv/cvs‎؛ تملك المجموعة src افتراضيًا إذن الكتابة إلى مستودع CVS؛ لذلك تستطيع إضافة المستخدم إلى هذه المجموعة، ثم سيستطيع إضافة وإدارة المشاريع في مستودع CVS.

التحكم بالإصدارات (Version Control) هو فن إدارة التغييرات إلى المعلومات؛ وهي أداة محورية للمبرمجين، الذين يمضون وقتهم بإجراء تعديلات صغيرة إلى البرمجيات ومن ثم يتراجعون عنها في اليوم التالي! لكن فائدة برمجيات التحكم بالإصدارات تمتد خارج حدود عالم تطوير البرمجيات؛ في أي مكان تجد فيه أشخاصًا يستخدمون الحواسيب لإدارة معلومات تتغير عادةً، فهنالك مكان للتحكم بالإصدارات. Bazaarإن Bazaar هو نظام جديد للتحكم بالإصدارات ممول من كانوكيال – الشركة التجارية التي تقف خلف أوبنتو، وعلى النقيض من Subversion و CVS اللذان يدعمان نمط المستودع المركزي، فإن Bazaar يدعم أيضًا «التحكم الموزَّع بالإصدارات» (distributed version control)، مما يسمح للناس بالتعامل بطريقة تعاونية أكثر فعاليةً؛ وخصوصًا أن Bazaar مصمم لتعظيم درجة اشتراك المجتمع في المشاريع المفتوحة المصدر. التثبيتأدخِل الأمر الآتي في الطرفية لتثبيت bzr: sudo apt-get install bzrالضبطلكي «تُعرِّف نفسك» إلى bzr، فاستخدم الأمر whoami كما يلي: bzr whoami 'Joe Doe <joe.doe@gmail.com>'تعلم Bazaarيأتي Bazaar مع توثيق مدمج مثبَّت في ‎/usr/share/doc/bzr/html افتراضيًا؛ يأتي الأمر bzr أيضًا مع مساعدة مدمجة فيه: bzr helpلتعلم المزيد عن أمرٍ ما: bzr help fooالدمج مع Launchpadعلى الرغم من أنه مفيد كنظام يعمل بمفرده، لكنه يملك قابلية الدمج الاختياري مع Launchpad، الذي هو نظام التطوير التعاوني المستخدم من كانوكيال ومجتمع البرمجيات المفتوحة المحيط بها لإدارة وتوسيع أوبنتو؛ للمزيد من المعلومات حول كيفية استخدام Bazaar مع Launchpad للتعاون في البرمجيات مفتوحة المصدر، راجع هذا الرابط. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Bazaar.