احترف Git

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

هذا أيضا خيار ظريف وسريع لجلب عمل شخص آخر من مستودعه. فإذا كنت وزميلك تعملان على مشروع واحد ويريدك أن تسحب شيئا ما، فتنفيذ أمر مثل git pull /home/badr/project أسهل كثيرا في الغالب من أن يدفع عمله إلى خادوم بعيد ثم تستحضره أنت بعد ذلك.

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

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

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

يعمل الميفاق الذكي بطريقة كبيرة الشبه بميفاقَي SSH و Git، لكنه يعمل عبر منافذ HTTPS (الآمن) المعيارية ويستعمل آليّات استيثاق HTTP المتنوعة، ما يعني أنه غالبا أسهل للمستخدم من شيء مثل SSH، لأنك مثلا تستطيع استعمال اسم المستخدم وكلمة المرور بدلا من الاضطرار إلى إعداد مفاتيح SSH.

لعله أشهر طريقة لاستعمال جت اليوم، لأن من الممكن إعداده ليتيح المستودع بغير هُوية مثل ميفاق Git، وكذلك ليتيح الدفع إليه بهُوية وتعمية مثل ميفاق SSH. فبدلا من الاضطرار إلى إعداد رابطَين (URL) مختلفين للعمليتين، يمكنك الآن استعمال رابط واحد لكليهما. وإذا حاولت الدفع فطلبَ المستودعُ الاستيثاقَ منك (وهو ما يجب أن يحدث في المعتاد)، فسيسألك الخادوم عن اسم المستخدم وكلمة المرور. والأمر نفسه للقراءة وحدها.

وفي الواقع، في خدمات مثل جت‌هب، الرابط الذي تستعمله لتصفح المستودع عبر المتصفح (مثلا https://github.com/schacon/simplegit) يمكنك استعماله هو نفسه للاستنساخ، وكذلك للدفع إليه إذا كان لديك الإذن.

إن لم يستجب الخادوم لطلب ميفاق HTTP الذكي من جت، فسيحاول عميل جت استعمال ميفاق HTTP البليد الأيسر. يتوقع الميفاق البليد أن يقدَّم له مستودع جت المجرد كما تُقدَّم الملفات العادية من خادوم الوب. فجمال الميفاق البليد هو سهولة إعداده. فليس عليك إلا وضع مستودع جت مجرد في مكانٍ ما في جذر مستندات HTTP، وإعداد خطاف post-update، وتكون قد أتممت المهمة (انظر فصل خطاطيف جت). عندئذٍ يستطيع استنساخ المستودع كل مَن يستطيع الوصول إلى خادوم الوب الذي وضعته عليه. فللسماح بقراءة مستودعك عبر HTTP، افعل شيئًا مثل هذا:

هذا كل ما في الأمر. وخطاف post-update الذي يأتي مبدئيا مع جت ينفذ الأمر المناسب (git update-server-info) لجعل الاستحضار والاستنساخ عبر HTTP يعمل بطريقة صحيحة. ويعمل هذا الأمر عندما تدفع إلى المستودع (عبر SSH مثلا). عندئذٍ يستطيع الآخرون الاستنساخ بمثل هذا الأم‍ر:

نستعمل في حالتنا هذه مسار /var/www/htdocs وهو الشائع مع خواديم Apache. لكن يمكنك استعمال أي خادوم وب سكونيّ (استاتيكي)؛ ليس عليك سوى وضع المستودع المجرد في مساره، فبيانات جت تقدَّم لطالبها مثل أي ملفات ساكنة عادية (انظر باب دواخل جت للتفاصيل عن كيف تُقدَّم بالتحديد).

وفي العموم ستختار إما تشغيل خادوم HTTP ذكي للقراءة والتحرير، وإما جعل الملفات متاحة للقراءة فقط بالطريقة البليدة. فمن النادر تشغيل نوعَي الخدمتين معا.

سنركز على مزايا النسخة الذكية من ميفاق HTTP.

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

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

شيء جميل آخر هو أن HTTP و HTTPS مستعملان بكثرة حتى إن جدران الحماية (firewalls) الخاصة بالمؤسسات تُضبط في الغالب لتتيح مرورهما عبر منافذها.

قد يكون إعداد جت عبر HTTPS أصعب قليلا من SSH على بعض الخواديم. ولكن غير ذلك، فلا تكاد توجد مزية لأحد الموافيق الأخرى على HTTP الذكي في تقديم محتوى جت.

فإذا كنت تستعمل HTTP للدفع المستوثَق، فإعطاء اسم المستخدم وكلمة المرور قد يكون في بعض الأحيان أعقد قليلا من استعمال المفاتيح عبر SSH. ولكن توجد عدة أدوات للاحتفاظ بهما يمكنك استعمالها لجعل العملية أخف كثيرا، مثل Keychain Acess على نظام ماك أو إس و Credential Manager على نظام ويندوز. اقرأ فصل تخزين الاسم وكلمة المرور لترى كيف تضبط نظامك للاحتفاظ بكلمة مرور HTTP آمن على نظامك.

مزايا SSH عديدة. أولا، سهل الإعداد نسبيا؛ فعفاريته (daemons) منتشرة، ولأكثر مديري الشبكات خبرة فيها، وأغلب أنظمة التشغيل تأتي بها معدَّة أو بأدوات لإدراتها. ثانيا، التواصل عبره آمن؛ فكل البيانات تُنقل بعد التعمية والاستيثاق. وأخيرا، إنه كفؤ، فيجعل البيانات ذات أقل حجم ممكن قبل نقلها، مثل موافيق HTTPS و Git والمحلي.

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

ميفاق Git غالبا ما يكون أسرع ميفاق نقل شبكي متاح. فإن كنت تخدم كمًّا كبيرًا من النقل الشبكي لمشروع عمومي، أو تقدّم مشروعًا كبيرًا لا يحتاج استيثاق المستخدمين للاطلاع عليه، فغالبا ستودّ إعداد عفريت جت ليقدّمه. فهو يستعمل الآلية نفسها التي يستعملها SSH لنقل البيانات، لكن بغير عبء التعمية والاستيثاق.

بسبب عدم وجود TLS أو أي نوع من التعمية، فإن الاستنساخ عبر git:// قد يسبب ثغرة تنفيذ تعليمات برمجية عشوائية (arbitrary code execution)، لذا ينبغي تجنبه إلا إن كنت تعي جيدا ماذا تفعل.

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