الباب الرابع: جت على الخادوم
تستطيع الآن فعل معظم مهامك اليومية التي تستخدم فيها جت. ولكن عليك استعمال مستودع بعيد لأي عمل تعاوني به. ومع أنك نظريا تستطيع دفع التعديلات إلى مستودعات الآخرين الشخصية المحلية والجذب منها، إلا أن فعل هذا متجنَّب لأن من السهل التسبب في خلط الأمور ومَن يعمل على ماذا، إن لم تكن حذرا. وكذلك إذا أردت أن يصل زملاؤك إلى مستودعك حتى عندما يكون حاسوبك مغلقًا أو غير متصل بالشبكة؛ فكثيرا ما يفيد وجود مستودع مشترك مضمون. لذا فالمستحب للتعاون مع غيرك أن تعدّ مستودعًا وسيطًا يستطيع كلاكما الوصول إليه، وتجذبا منه وتدفعا إليه.
تشغيل خادوم جت عملية يسيرة. أولًا تحدد الموافيق (البروتوكولات) التي تريد منه دعمها. وسيتناول الفصل الأول من هذا الباب الموافيق المتاحة ومزايا وعيوب كل منها. ثم تشرح الفصول التالية بعض الترتيبات المعتادة العاملة بهذه الموافيق وكيف تشغّل خادومك بها. وأخيرا سنرى بعض الخيارات المستضافة، إذا لم تمانع استضافة مشاريعك البرمجية على خواديم الآخرين وكنت لا تريد المعاناة بإعداد خادومك الخاص ورعايته.
إن لم تكن مهتمًا بتشغيل خادومك الخاص، فيمكنك تخطي هذه الفصول والانتقال إلى الفصل الأخير من هذا الباب، الذي يريك بعض الخيارات لإعداد حساب مستضاف، ثم انتقل إلى الباب التالي، الذي نناقش فيه التفاصيل الدقيقة المختلفة للعمل في بيئة إدارة موزعة للنسخ.
المستودع البعيد هو عموما مستودع مجرد، أيْ مستودع جت ليس له مجلد عمل.
ولأن المستودع لا يُستعمل إلا ملتقًى للتعاون، فلا داعي إلى سحب لقطة منه على الحاسوب؛ إنما هو لبيانات جت وحدها.
أي بأيسر الكلمات: المستودع المجرد هو محتويات مجلد .git الخاص بمشروعك، ولا شيء غير ذلك.
الموافيق (البروتوكولات)
يتيح جت أربعة موافيق مختلفة لنقل البيانات: المحلي، و HTTP، و SSH (أي Secure Shell)، و Git. سنناقش ما هم وما الظروف التي فيها ستود (أو لا تود) استعمالهم.
الميفاق المحلي
الأكثر بدائية هو الميفاق المحلي (“Local protocol”)، الذي يكون المستودع البعيد فيه هو مجلد آخر على الحاسوب نفسه. ويُستعمل غالبا إذا كان كل مَن في فريقك لديه وصول إلى نظام ملفات مشترك مثل NFS مضموم (mounted)، أو في الحالة الأندر أن يكون كل شخص مستخدما لحاسوب واحد. ولكن تلك الأخيرة ليست حالة مثالية لأن وقتئذٍ ستبيت كل مشاريعك البرمجية على جهاز واحد، وهذا يُزيد احتمال فقد البيانات فقدا كارثيا.
إذا كان لديك نظام ملفات مشترك مضموم، فيمكنك إذًا استنساخ مستودع محلي مكوَّن من ملفات عادية، والدفع إليه، والجذب منه. فلاستنساخ مستودع مثل هذا، أو لإضافته مستودعًا بعيدًا في مشروع موجود بالفعل، فاستعمل مسار المستودع كأنه رابط URL. مثلا، لاستنساخ مستودع محلي، يمكنك فعل شيء مثل هذا:
$ git clone /srv/git/project.gitأو مثل هذا:
$ git clone file:///srv/git/project.gitولكن تصرف جت يختلف قليلا إذا بدأت العنوان بالميفاق file:// صريحا.
فإذا كتبت المسار فقط، فإن جت يحاول صنع روابط صلبة (hardlinks) أو نسخ الملفات التي يحتاجها مباشرةً.
أما إذا كتبت file://، فإن جت ينفّذ العمليات التي يستعملها في المعتاد لنقل الملفات عبر الشبكة، ويكون هذا في الغالب أقل كثيرا في الكفاءة.
السبب الرئيسي لكتابة البادئة file:// هي إذا كنت تريد نسخة نظيفة من المستودع بغير الإشارات أو الكائنات الإضافية — وغالبا ما يكون ذلك بعد الاستيراد من نظام إدارة نسخ آخر أو أمر شبيه (انظر دواخل جت لعمليات الصيانة).
سنستعمل المسار العادي هنا لأنه أسرع في أغلب الأحيان.
لإضافة مستودع محلي إلى مشروع جت موجود، نفّذ أمرًا مثل هذا:
$ git remote add local_proj /srv/git/project.gitعندئذٍ يمكنك الدفع إلى ذلك البعيد والجذب منه بالاسم المختصر الجديد local_proj كما كنت تفعل تمامًا عبر الشبكة.
المزايا
مزايا المستودعات «الملفاتية» أنها سهلة وتستعمل تصاريح الملفات واتصال الشبكة الموجودين فعلا. وإذا كان لديك نظام ملفات مشترك يصل إليه جميع فريقك، فإعداد مستودع عملية سهلة جدا: تضع نسخة المستودع المجرد في مكانٍ يستطيع الجميع الوصول إليه، وتضبط أذونات القراءة والتحرير كما تفعل لأي مجلد مشترك آخر. سنناقش كيفية تصدير نسخة مستودع مجردة لهذا الهدف في تثبيت جت على خادوم.
هذا أيضا خيار ظريف وسريع لجلب عمل شخص آخر من مستودعه.
فإذا كنت وزميلك تعملان على مشروع واحد ويريدك أن تسحب شيئا ما، فتنفيذ أمر مثل git pull أسهل كثيرا في الغالب من أن يدفع عمله إلى خادوم بعيد ثم تستحضره أنت بعد ذلك.
العيوب
عيوب هذه الطريقة هي أن الوصول المشترك غالبا ما يكون أصعب كثيرا من الوصول الشبكي العادي، في إعداده وفي الوصول إليه من أماكن مختلفة. فإذا أردت أن تدفع من حاسوبك المحمول عندما تكون في المنزل، فستحتاج إلى ضم القرص البعيد، وهذا قد يكون صعبًا وبطيئًا مقارنةً بوصول عبر الشبكة.
من المهم ذكر أن هذا ليس بالضرورة الخيار الأسرع إذا كنت تستعمل نوعًا من الضم (mount) المشترك. فالمستودع المحلي لا يكون سريعا إلا إذا كان لديك وصول سريع إلى البيانات. فإن مستودع على NFS يكون في الغالب أبطأ من مستودع عبر SSH على الخادوم نفسه، بفرض أن جت يعمل من الأقراص المحلية في كل نظام.
وأخيرا، لا يحمي هذا الميفاق المستودعَ من الإتلاف غير المقصود. فكل مستخدم لديه وصول صَدفي كامل للمجلد «البعيد»، فلا شيء يمنعه من تعديل ملفات جت الداخلية أو إزالتها وتخريب المستودع.
ميفاقا HTTP
يستطيع جت التواصل عبر HTTP بطريقتين مختلفتين. لم يعرف جت قبل النسخة 1.6.6 منه إلا واحدة منهما، وكانت ساذجة جدا وعموما للقراءة فقط. ولكن في نسخة 1.6.6، جاء ميفاق جديد جعل جت يتفاوض بذكاء في شأن نقل البيانات، بطريقة تشبه ما كان يفعل عبر SSH. وصار ميفاق HTTP الجديد هذا في الأعوام الأخيرة أشهر كثيرا لأنه أيسر للمستخدم وأذكي في تواصله. فانتشرت تسمية النسخة الجديدة «ميفاق HTTP الذكي» (Smart HTTP)، والقديمة «ميفاق HTTP البليد» (Dumb HTTP). وسنتناول الميثاق الذكي أولا.
ميفاق HTTP الذكي
يعمل الميفاق الذكي بطريقة كبيرة الشبه بميفاقَي SSH و Git، لكنه يعمل عبر منافذ HTTPS (الآمن) المعيارية ويستعمل آليّات استيثاق HTTP المتنوعة، ما يعني أنه غالبا أسهل للمستخدم من شيء مثل SSH، لأنك مثلا تستطيع استعمال اسم المستخدم وكلمة المرور بدلا من الاضطرار إلى إعداد مفاتيح SSH.
لعله أشهر طريقة لاستعمال جت اليوم، لأن من الممكن إعداده ليتيح المستودع بغير هُوية مثل ميفاق Git، وكذلك ليتيح الدفع إليه بهُوية وتعمية مثل ميفاق SSH. فبدلا من الاضطرار إلى إعداد رابطَين (URL) مختلفين للعمليتين، يمكنك الآن استعمال رابط واحد لكليهما. وإذا حاولت الدفع فطلبَ المستودعُ الاستيثاقَ منك (وهو ما يجب أن يحدث في المعتاد)، فسيسألك الخادوم عن اسم المستخدم وكلمة المرور. والأمر نفسه للقراءة وحدها.
وفي الواقع، في خدمات مثل جتهب، الرابط الذي تستعمله لتصفح المستودع عبر المتصفح (مثلا https://github.com/schacon/simplegit) يمكنك استعماله هو نفسه للاستنساخ، وكذلك للدفع إليه إذا كان لديك الإذن.
ميفاق HTTP البليد
إن لم يستجب الخادوم لطلب ميفاق HTTP الذكي من جت، فسيحاول عميل جت استعمال ميفاق HTTP البليد الأيسر.
يتوقع الميفاق البليد أن يقدَّم له مستودع جت المجرد كما تُقدَّم الملفات العادية من خادوم الوب.
فجمال الميفاق البليد هو سهولة إعداده.
فليس عليك إلا وضع مستودع جت مجرد في مكانٍ ما في جذر مستندات HTTP، وإعداد خطاف post-update، وتكون قد أتممت المهمة (انظر خطاطيف جت).
عندئذٍ يستطيع استنساخ المستودع كل مَن يستطيع الوصول إلى خادوم الوب الذي وضعته عليه.
فللسماح بقراءة مستودعك عبر HTTP، افعل شيئًا مثل هذا:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-updateهذا كل ما في الأمر.
وخطاف post-update الذي يأتي مبدئيا مع جت ينفذ الأمر المناسب (git update-server-info) لجعل الاستحضار والاستنساخ عبر HTTP يعمل بطريقة صحيحة.
ويعمل هذا الأمر عندما تدفع إلى المستودع (عبر SSH مثلا). عندئذٍ يستطيع الآخرون الاستنساخ بمثل هذا الأمر:
$ git clone https://example.com/gitproject.gitنستعمل في حالتنا هذه مسار /var/www/htdocs وهو الشائع مع خواديم Apache. لكن يمكنك استعمال أي خادوم وب سكونيّ (استاتيكي)؛ ليس عليك سوى وضع المستودع المجرد في مساره،
فبيانات جت تقدَّم لطالبها مثل أي ملفات ساكنة عادية (انظر باب دواخل جت للتفاصيل عن كيف تُقدَّم بالتحديد).
وفي العموم ستختار إما تشغيل خادوم HTTP ذكي للقراءة والتحرير، وإما جعل الملفات متاحة للقراءة فقط بالطريقة البليدة. فمن النادر تشغيل نوعَي الخدمتين معا.
المزايا
سنركز على مزايا النسخة الذكية من ميفاق HTTP.
بساطة الرابط الواحد للوصول بنوعيه تسهّل الأمور كثيرا على المستخدم النهائي، وكذلك عدم الاستثياق إلا عند الحاجة. والاستيثاق باسم مستخدم وكلمة مرور لهو أيضا مزية كبيرة فيه على SSH، فلا يحتاج المستخدمون أن يوّلدوا مفاتيح SSH محليًّا ثم يرفعوا مفاتيحهم العمومية إلى الخادوم ليسمح لهم بالتواصل. وإن هذه لمزية عظيمة في قابلية الاستخدام، للمستخدمين الأقل حنكة، وللمستخدمين على أنظمة عليها SSH غير موجود أو غير شائع. وهو أيضا كفؤ وسريع جدا، مثل SSH.
ويمكنك كذلك إتاحة مستودعاتك للقراءة فقط عبر HTTPS الآمن، ما يعني أن بإمكانك تعمية المحتوى خلال نقله، أو حتى جعل العملاء يستعملون شهادات SSL موقّعة مخصوصة.
شيء جميل آخر هو أن HTTP و HTTPS مستعملان بكثرة حتى إن الجدران النارية (firewalls) الخاصة بالمؤسسات تُضبط في الغالب لتتيح مرورهما عبر منافذها.
العيوب
قد يكون إعداد جت عبر HTTPS أصعب قليلا من SSH على بعض الخواديم. ولكن غير ذلك، فلا تكاد توجد مزية لأحد الموافيق الأخرى على HTTP الذكي في تقديم محتوى جت.
فإذا كنت تستعمل HTTP للدفع المستوثَق، فإعطاء اسم المستخدم وكلمة المرور قد يكون في بعض الأحيان أعقد قليلا من استعمال المفاتيح عبر SSH.
ولكن توجد عدة أدوات للاحتفاظ بهما يمكنك استعمالها لجعل العملية أخف كثيرا، مثل Keychain Acess على نظام ماك أو إس و Credential Manager على نظام ويندوز.
اقرأ Credential Storage لترى كيف تضبط نظامك للاحتفاظ بكلمة مرور HTTP آمن على نظامك.
ميفاق SSH
النقل عبر SSH شائع عند استضافة جت ذاتيا. هذا لأن معظم الخواديم مُعدَّة فعلا لقَبول الوصول عبره، وإن لم تكن معدة فإعدادها سهل. أيضا SSH هو ميفاق شبكي استيثاقي، ويوجد في كل مكان، وسهل عموما إعداده واستعماله.
لاستنساخ مستودع جت عبر SSH، استعمل رابط ssh:// مثل:
$ git clone ssh://[user@]server/project.gitأو استعمل الصيغة المختصرة شبيهة scp لميفاق SSH:
$ git clone [user@]server:project.gitوفي كلتا الحالتين، إن لم تحدد اسم المستخدم الاختياري، فسيعدّه جت مطابقًا لاسم مستخدم النظام الحالي على حاسوبك.
المزايا
مزايا SSH عديدة. أولا، سهل الإعداد نسبيا؛ فعفاريته (daemons) منتشرة، ولأكثر مديري الشبكات خبرة فيها، وأغلب أنظمة التشغيل تأتي بها معدَّة أو بأدوات لإدراتها. ثانيا، التواصل عبره آمن؛ فكل البيانات تُنقل بعد التعمية والاستيثاق. وأخيرا، إنه كفؤ، فيجعل البيانات ذات أقل حجم ممكن قبل نقلها، مثل موافيق HTTPS و Git والمحلي.
العيوب
نقيصة SSH أنه لا يدعم وصول المجهولين إلى مستودعك. فإذا كنت تستعمل SSH، فيجب على الناس الحصول على وصول SSH لجهازك، حتى لرؤيتها فحسب، وهذا لا يجعل SSH مستحسَنًا للمشروعات المفتوحة، التي يود الناس أن يستنسخوها للنظر فيها فقط. أما إذا كنت لا تستعمله إلا داخل شبكة مؤسستك، فقد يكون SSH هو الميفاق الوحيد الذي تحتاج إلى التعامل معه. وإذا وددت أن تأذن للمجهولين بالاطلاع فقط على مشروعاتك ولكن تريد SSH أيضا، فعليك إعداد SSH للدفع ثم إعداد ميفاق آخر للآخرين حتى يستحضروا منه.
ميفاق Git
أخيرا، لدينا ميفاق Git.
هذا عفريت (daemon) مخصوص مرفق مع جت، ويستمع على منفذ مخصص (9418) ليتيح خدمة شبيهة بميفاق SSH، لكن بغير استيثاق أو تعمية.
وعليك إنشاء ملف اسمه git-daemon-export-ok في مستودعك لتجعل جت يقدّمه عبر ميفاق Git؛ فالعفريت لن يقدّم مستودعًا ليس فيه هذا الملف، ولكن غير ذلك لا يوجد أمان.
إما أن يكون المستودع متاحا للجميع لاستنساخه، وإما لا يكون.
هذا يعني أنه عموما لا يمكن الدفع عبر هذا الميفاق.
يمكنك تفعيل إذن الدفع، ولكن لانعدام الاستيثاق، فأي شخص على الإنترنت يجد رابط مشروعك يستطيع الدفع إليه.
يكفي أن نقول أن هذا نادر.
المزايا
ميفاق Git غالبا ما يكون أسرع ميفاق نقل شبكي متاح. فإن كنت تخدم كمًّا كبيرًا من النقل الشبكي لمشروع عمومي، أو تقدّم مشروعًا كبيرًا لا يحتاج استيثاق المستخدمين للاطلاع عليه، فغالبا ستودّ إعداد عفريت جت ليقدّمه. فهو يستعمل الآلية نفسها التي يستعملها SSH لنقل البيانات، لكن بغير عبء التعمية والاستيثاق.
العيوب
بسبب عدم وجود TLS أو أي نوع من التعمية، فإن الاستنساخ عبر git:// قد يسبب ثغرة تنفيذ تعليمات برمجية عشوائية (arbitrary code execution)، لذا ينبغي تجنبه إلا إن كنت تعي جيدا ماذا تفعل.
-
عندما تنفذ
git clone git://example.com/project.git، فإن مخترقا يتحكم في جهاز التوجيه (router) الخاص بك سيستطيع تعديل المستودع الذي استنسخته للتو، مثلا يضيف تعليمات برمجية خبيثة فيه. وعندما تصرّف (compile) أو تشغل ما في هذا المستودع الذي استنسخته للتو، فستنفذ تلك التعليمات البرمجية الخبيثة. ابتعد عن تنفيذgit clone http://example.com/project.gitللسبب نفسه (أي ميفاق HTTP غير الآمن). -
تنفيذ
git clone https://example.com/project.git(الآمن) لا يعاني من تلك العلة (إلا إن استطاع المخترق أن يحضر شهادة TLS للنطاق الذي تتصل به،example.comفي هذا المثال).
تنفيذgit clone git@example.com:project.git(بميفاق SSH) لا يعاني من تلك العلة أيضا، إلا إن كنت قبلت بصمة مفتاح SSH خاطئة.
وكذلك لا يدعم الاستيثاق، فأي أحد سيستطيع استنساخ المستودع (ولكن غالبا هذا ما تريده بالتحديد).
ولعله أيضا من أصعب الموافيق في الإعداد.
فيجب أن يشغّل عفريته الخاص، الذي يحتاج تهيئة xinetd أو systemd أو ما يشبههما. وليس هذا يسيرًا دائما.
ويحتاج أيضا وصولًا عبر الجدار الناري إلى منفذ 9418، وهذا ليس منفذًا معتادًا تسمح به دائما الجدران النارية الخاصة بالمؤسسات؛
فخلف تلك الجدران الكبيرة، هذا المنفذ الغامض غالبا ما يُحظر.
تثبيت جت على خادوم
سنتناول الآن إعداد خدمة جت لتشغيل هذه الموافيق على خادومك.
|
سنعرض هنا الأوامر والخطوات اللازمة لتثبيت أساسي مبسط على خادوم لينكسي، لكن ممكن أيضا تشغيل هذه الخدمات على ماك أو إس أو ويندوز. وفي الحقيقة إعداد خادوم إنتاجي ضمن بنيتك التحتية بالتأكيد سيشمل اختلافات في التدابير الأمنية أو أدوات نظام التشغيل، ولكننا نرجو أن يعطيك هذا فكرة عامة عما ينطوي عليه الأمر. |
حتى تعد أي خادوم جت، عليك أولا تصدير مستودع موجود إلى مستودع جديد مجرد، والمستودع المجرد هو مستودع ليس فيه مجلد عمل.
هذا في المعتاد عملية سهلة.
فلاستنساخ مستودع لإنشاء مستودع جديد مجرد، نفّذ أمر الاستنساخ بالخيار --bare («مجرد»):
والعُرف أن أسماء مجلدات المستودعات المجردة تنتهي باللاحقة .git، مثل هذا:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.سيكون لديك الآن نسخة من بيانات مجلد جت في مجلد my_project.git.
هذا يكافئ تقريبا شيئا مثل هذا:
$ cp -Rf my_project/.git my_project.gitتوجد بعض الاختلافات الطفيفة في ملف التهيئة (“config”)، ولكن لغرضنا اليوم فيكادا يتطابقان. فهذا الأخير يأخذ مستودع جت وحده بغير مجلد عمله وينشئ مجلدا مخصصا له وحده.
وضع المستودع المجرد على خادوم
الآن وقد صار لديك نسخة مجردة من مستودعك، فلا تحتاج سوى وضعه على الخادوم وضبط الموافيق (البروتوكولات).
لنقُل إنك أعددت خادوما يسمى git.example.com، ولديك وصول SSH له، وتريد تخزين كل مستودعات جت الخاصة بك في مجلد /srv/git فيه.
إذا كان مجلد /srv/git موجودا على هذا الخادوم، يمكنك إعداد مستودعك الجديد بنسخ مستودعك المجرد إليه:
$ scp -r my_project.git user@git.example.com:/srv/gitيستطيع الآن المستخدمين الذين لديهم إذن قراءة مجلد /srv/git عبر SSH أن يستنسخوا مستودعك بالأمر:
$ git clone user@git.example.com:/srv/git/my_project.gitوإذا كان لمستخدمٍ إذن تحرير هذا المجلد، ودخل عبر SSH إلى الخادوم، فسيستطيع الدفع إليه متى شاء.
وسيضيف جت إذن التحرير للمجموعة إلى المستودع بطريقة صحيحة إذا استخدمت خيار --shared («مشترك») مع أمر الابتداء git init.
لاحظ أن هذا لن يُتلف أي إيداعات أو إشارات أو أي شيء آخر.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --sharedقد رأيت كم هو سهل إنشاء نسخة مجردة من مستودع جت ووضعها على خادوم عندكم وصول SSH إليه. فيمكنكم الآن التعاون في مشروع واحد.
مهمٌ ملاحظة أنك حقا لا تحتاج غير هذا لتشغيل خادوم جت مفيد يصل إليه العديدون: تنشئ حسابات SSH، وتضع مستودعًا مجردًا في مكانٍ للجميع إذن قراءته وتحريره. وتمت العملية بنجاح؛ لا شيء آخر مطلوب.
سنرى في الفصول القليلة التالية كيف يمكنك التوسع لإعدادات أكثر تعقيدا. وسيشمل هذا عدم الاضطرار إلى إنشاء حساب مستخدم لكل مستخدم، وإضافة إذن القراءة للجميع للمستودعات، وإعداد واجهات الوب، والمزيد. لكن تذكر أن للتعاون مع بعض الناس على مشروع خصوصي، كل ما تحتاجه هو خادوم SSH ومستودع مجرد.
الترتيبات الصغيرة
إذا كانت شركتك صغيرة أو كنت تجرب جت في مؤسسة ولستم إلا عددا قليلا من المطورين، فقد تكون الأمور يسيرة عليك. فأحد أعقد مناحي إعداد خادوم جت هو إدارة المستخدمين. فإن أردت لبعض المستودعات ألا يقرأها إلا مستخدمون معينون وألا يحررها إلا جماعة أخرى، فقد تجد ترتيب الأذونات والوصول أصعب.
الوصول عبر SSH
إذا كان لديك خادومٌ يستطيع جميع المطورين الوصول إليه عبر SSH، فمن الأسهل عموما إعداد مستودعك الأول عليه، لأنك بهذا لن تحتاج إلى عمل شيء تقريبا (كما شرحنا في الفصل السابق). وإذا احتجت إلى أذونات وصول أعقد لمستودعاتك، فيمكنك تحقيقها بأذونات نظام الملفات العادية الخاص بنظام تشغيل خادومك.
وإذا أردت وضع مستودعاتك على خادوم ليس فيه حساب لكل مطور يحتاج إذن التحرير في فريقك، فعليك إعداد وصول SSH لكلٍ منهم. إذا كنت تريد فعل هذا على خادوم لديك، فسنفترض أن لديك بالفعل خادوم SSH مثبت عليه، وأنه وسيلتك للتواصل مع الخادوم الجهاز.
توجد أكثر من طريقة لإعطاء إذن الوصول لكل واحد في فريقك.
الأولى هي إعداد حساب لكل واحد، وهي عملية سهلة لكن قد تكون مرهقة.
فربما لا تريد تنفيذ adduser (أو بديله المحتمل useradd) والاضطرار إلى ضبط كلمة مرور مؤقتة لكل مستخدم جديد.
الطريقة الثانية هي إنشاء حساب مستخدم git واحد على الجهاز، وطلب مفتاح SSH العمومي من كل مستخدم تريد إعطاءه إذن التحرير، ثم إضافة هذه المفاتيح إلى ملف ~/.ssh/authorized_keys في حساب git الجديد هذا.
وعندئذٍ سيستطيع كل شخص الوصول إلى ذلك الجهاز عبر حساب git.
وهذا لا يؤثر على بيانات الإيداعات بأي شكل؛ فحساب مستخدم SSH الذي تتصل عبره لا يؤثر على الإيداعات التي تسجلها.
طريقة أخرى هي أن يستوثق خادوم SSH الخاص بك من خادوم LDAP أو مصدر استيثاق مركزي آخر أعددته. وما دام لكل مستخدم وصول صَدَفي إلى الجهاز، فأي آلية استيثاق SSH تخطر على بالك ستعمل.
توليد مفتاح SSH عمومي لك
العديد من خواديم جت تستوثق باستعمال مفاتيح SSH العمومية.
فعلى كل مستخدم توليد مفتاح إن لم يكن لديه مفتاح فعلا.
تتشابه هذه العملية عبر أنظمة التشغيل المختلفة.
أولا عليك التحقق أنك لا تملك مفتاحًا فعلا.
المكان المبدئي لتخزين مفاتيح SSH الخاصة بالمستخدم هو مجلد ~/.ssh.
فانظر فيه لتعرف إذا كان لديك مفتاحٌ فعلا:
$ cd ~/.ssh
$ ls
authorized_keys2 id_dsa known_hosts
config id_dsa.pubعليك البحث عن ملفين اسم أحدهما يشبه id_dsa أو id_rsa، والآخر هو الاسم نفسه لكن بالامتداد .pub.
فملف .pub هو مفتاحك العمومي، والملف الآخر هو نظيره الخصوصي.
وإذا لم يكن لديك هذين الملفين (أو لم يكن لديك مجلد .ssh من الأساس)، فيمكنك إنشاءهما بتشغيل برنامج يسمى ssh-keygen («توليد مفتاح SSH»)، والذي يأتي مع حزمة SSH على أنظمة لينكس وماك أو إس ومع Git for Windows على ويندوز:
$ ssh-keygen -o
Generating public/private rsa key pair.
Enter file in which to save the key (/home/schacon/.ssh/id_rsa):
Created directory '/home/schacon/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/schacon/.ssh/id_rsa.
Your public key has been saved in /home/schacon/.ssh/id_rsa.pub.
The key fingerprint is:
d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.localهو أولا يتحقق المكان الذي تريد حفظ المفتاح فيه (.ssh/id_rsa)، ثم يطلب مرتين إدخال عبارة المرور (passphrase)، ويمكنك تركها فارغة إذا لم تشأ إدخال عبارة مرور عند استعمال المفتاح.
أما إذا أردتها، فعليك إضافة الخيار -o؛ فهو يحفظ المفتاح الخصوصي بصيغة أفضل من الصيغة المبدئية في مقاومة كسر عبارات المرور بالقوة العمياء.
ويمكنك أيضا استخدام أداة ssh-agent («عميل SSH») لمنع الحاجة إلى إدخال عبارة المرور في كل مرة.
الآن، على كل مستخدم فَعَلَ هذا أن يرسل مفتاحه العمومي إليك أو إلى من يدير خادوم جت (بفرض أنك أعدت خادوم SSH ليستعمل المفاتيح العمومية).
وليس عليهم سوى نسخ محتويات ملف .pub وإرسالها إليك بالبريد الإلكتروني.
تبدو المفاتيح العمومية مثل هذا:
$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== schacon@mylaptop.localلشرح أعمق لإنشاء مفتاح SSH على أنظمة التشغيل المختلفة، انظر دليل جتهب لمفاتيح SSH (بالإنجليزية):
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent.
إعداد الخادوم
لنعدّ معا وصولَ SSH على الخادوم.
سنستعمل في هذا المثال طريقة authorized_keys («المفاتيح المستوثَقة») لاستيثاق مستخدميك.
سنفترض أيضا أنك تستعمل توزيعة لينكس معتادة مثل أوبنتو.
|
معظم المشروح هنا يمكن عمله آليًّا بأمر |
أولا، أنشئ حساب مستخدم باسم git وأنشئ مجلد .ssh له.
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keysسنحتاج الآن إلى إضافة بعض مفاتيح SSH العمومية للمطورين إلى ملف المفاتيح المستوثَقة الخاص بالمستخدم git.
لنفرض أن لديك بعض المفاتيح الموثوقة وأنك حفظتها في ملفات مؤقتة.
للتذكير، تبدو المفاتيح العمومية هكذا:
$ cat /tmp/id_rsa.badr.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypairليس عليك إلا إضافتها إلى ملف authorized_keys الخاص بالمستخدم git الموجود في مجلد .ssh الخاص به:
$ cat /tmp/id_rsa.badr.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.shams.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.wafaa.pub >> ~/.ssh/authorized_keysأعدّ الآن مستودع مجرد لهم بأمر الابتداء git init مع الخيار --bare، لتنشئ المستودع بلا مجلد عمل:
$ cd /srv/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /srv/git/project.git/عندئذٍ يستطيع بدر أو شمس أو وفاء دفع النسخة الأولى من مشروعهم إلى المستودع بإضافته مستودعًا بعيدًا في نسختهم المحلية، ودفع الفرع الذي لديهم إليه.
لاحظ أن في كل مرة تريد فيها إضافة مشروع، على شخصٍ ما الوصول إلى الجهاز عبر الصدفة وإنشاء مستودع مجرد.
لنجعل gitserver اسم المضيف (“hostname”) للخادوم الذي أعددت عليه المستودع ومستخدم git.
إذا كنت تشغّل الخادوم داخليا وأعددت DNS ليشير الاسم gitserver إلى هذا الخادوم، فيمكنك استعمال الأوامر كما هي تقريبا (بفرض أن myproject هو مشروع موجود وفيه مِلفات):
# على حاسوب بدر
$ cd myproject
$ git init
$ git add .
$ git commit -m 'Initial commit'
$ git remote add origin git@gitserver:/srv/git/project.git
$ git push origin masterالآن سيستطيع الآخرون استنساخه إلى أجهزتهم ودفع تعديلاتهم إليه بالسَهولة نفسها:
$ git clone git@gitserver:/srv/git/project.git
$ cd project
$ vim README
$ git commit -am 'Fix for README file'
$ git push origin masterبهذه الطريقة ستحصل سريعا على خادوم جت يتيح إذنَي القراءة والتحرير لبضعة مطورين.
عليك أيضا ملاحظة أن حتى الآن، أولئك المستخدمين جميعهم يمكنهم أيضا الولوج إلى الخادوم والحصول على صدفة المستخدم git.
إذا أردت تقييد هذا، فعليك تغيير الصدفة إلى شيء آخر في ملف /etc/passwd.
يمكنك بسَهولة تقييد حساب المستخدم git إلى الأنشطة المرتبطة بـجت باستعمال أداة صدفة مقيَّدة اسمها git-shell («صدفة جت») وهي مرفقة مع جت.
فإذا ضبطتها لتكون صدفة ولوج لحساب المستخدم git فإن هذا الحساب لن يكون له وصول صدفة طبيعي إلى خادومك.
لاستعمالها، حدد git-shell لتكون صدفة ولوج لهذا الحساب بدلا من bash أو csh.
ولفعل هذا، عليك أولا إضافة المسار الكامل لأمر git-shell إلى مِلف /etc/shells إذا لم يكن موجودا فيه بالفعل:
$ cat /etc/shells # انظر إن كانت صدفة جيت هنا، وإلا…
$ which git-shell # فتحقق أن صدفة جيت مثبتة على نظامك
$ sudo -e /etc/shells # ثم أضف مسارها من الأمر السابق إلى ملف الصدفاتيمكنك الآن تغيير صدفة المستخدم بالأمر chsh <username> -s <shell>:
$ sudo chsh git -s $(which git-shell)عندئذٍ يستطيع المستخدم git استعمال SSH للدفع والجذب من مستودعات جت، بغير أن يكون له وصولًا صدفيًّا إلى خادومك.
وإن حاول، فسيرى رسالة رفض ولوج مثل هذه:
$ ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.ولكن حتى الآن لدى المستخدمين القدرة على توجيه منفذ SSH (أي “port forwarding”) للوصول إلى أي خادوم آخر يستطيع ذلك الخادوم الاتصال به.
فإذا أردت منع هذا، فأضف الخيارات التالية في أول كل مفتاح تريد تقييده في ملف المفاتيح المستوثقة (authorized_keys):
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-ptyستبدو نتيجة التعديل مثل هذا:
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...عندئذٍ ستظل تعمل أوامر جت الشبكية، ولكن المستخدمين لن يعودوا قادرين على الوصول إلى صدفة.
وكما ترى في رسالة الرفض، يمكنك أيضا إعداد مجلد في مجلد منزل المستخدم git لتخصيص أمر git-shell قليلا.
فيمكنك مثلا تقييد أوامر جت التي يقبلها الخادوم، أو تخصيص الرسالة التي يراها المستخدمين عندما يحاولون الوصول عبر SSH.
نفّذ الأمر git help shell للحصول على معلومات مزيدة عن تخصيص الصدفة.
عفريت جت
|
(من المترجم) كلمة “daemon” ظهرت في MIT اسمًا للعمليات الخدمية التي تعمل في خلفية نظام التشغيل ولا يلاحظها المستخدم. جاءت التسمية نسبة إلى «عفريت ماكسويل» في الفيزياء، الذي يستعمل المعنى القديم للكلمة (في اليونانية والعربية)، وهو الكائن الغَيْبي الذي يعمل في الخفاء، وليس بالضرورة شيطانًا. فأترجمها «عفريت»، وأترجم فعل الصيرورة منها (“daemonize”) إلى «عفرتة». الاسم المناظر على ويندوز هو «خدمة» (“service”)، وقد بدأ استخدامه حديثًا في لينكس كذلك. |
سنعدّ الآن عفريتًا ليقدِّم المستودعات بميفاق “Git”. هذا هو الخيار الشائع لإتاحة وصول سريع بغير استيثاق لبيانات جت. تذكر أنه غير مستوثَق، فأي شيء تتيحه عبر هذا الميفاق سيكون عموميا للجميع داخل الشبكة.
فإذا كنت تستخدمه على خادوم خارج جدارك الناري، فعليك ألا تستخدمه إلا للمشروعات التي يمكن أن يراها العالم. وإذا كان خادومك داخل جدارك الناري، فيمكنك استخدامه للمشروعات التي يحتاج الكثير من الناس أو الأجهزة الوصولَ إليه وصول قراءة فقط (مثل خواديم البناء أو التكامل المستمر)، إن لم تكن تريد إضافة مفتاح SSH لكلٍ منهم.
وفي جميع الأحوال، إن ميفاق Git سهل الإعداد نسبيا. فلستَ تحتاج إلا إلى عفرتة هذا الأمر:
$ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/خيار --reuseaddr («أعد استخدام العنوان») يسمح بإعادة تشغيل الخادوم بغير انتظار انتهاء وقت (timeout) الاتصالات القديمة. وخيار --base-path («أساس المسار») يتيح للناس استنساخ المشروعات بغير تحديد المسار بكامله. أما المسار الذي في آخر الأمر يخبر عفريت جت مكان المستودعات التي سيُصدِّرها.
وإذا كنت تستخدم جدارا ناريا، فستحتاج أيضا إلى فتح منفذ 9418 فيه على الجهاز الذي تعدّه عليه.
طريقة عفرتة هذه العملية تختلف حسب نظام تشغيلك.
لأن systemd هو نظام الابتداء (init) الأكثر شيوعا على توزيعات لينكس الحديثة، فيمكنك استخدامه لهذا الغرض.
ليس عليك سوى إنشاء الملف /etc/systemd/system/git-daemon.service بهذه المحتويات:
[Unit]
Description=Start Git Daemon
[Service]
ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
Restart=always
RestartSec=500ms
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=git-daemon
User=git
Group=git
[Install]
WantedBy=multi-user.targetربما لاحظت أن اسم المستخدم واسم المجموعة اللذين يشتغل تحتهما عفريت جت هما git.
يمكنك تغييرهما إلى ما يناسبك، ولكن تأكد من وجود اسم المستخدم المختار على نظامك.
وتأكد أيضا من أن الملف التنفيذي لبرنامج جت موجود فعلا في المسار /usr/bin/git وإلا فغيّره إلى ما يناسب.
وأخيرا، نفّذ systemctl enable git-daemon لبَدء تشغيل الخدمة (العفريت) آليًّا مع بدء تشغيل النظام، ويمكنك تشغيل الخدمة بالأمر systemctl start git-daemon وإيقافها بالأمر systemctl stop git-daemon.
على الأنظمة الأخرى، قد يناسبك xinetd أو بُرَيمج في نظام sysvinit أو شيئًا آخر — طالما أنك جعلت هذا الأمر مُعَفرَت ومُراقَب بطريقةٍ ما.
ثم تحتاج إلى إخبار جت بأي المستودعات التي يسمح بالوصول إليها بغير استيثاق عبر خادوم جت.
يمكنك فعل هذا بإنشاء ملف اسمه git-daemon-export-ok في كل مستودع.
$ cd /path/to/project.git
$ touch git-daemon-export-okوجود هذا الملف يخبر جت بقَبول إتاحة هذا المشروع بغير استيثاق.
ميفاق HTTP الذكي
لدينا الآن وصولا مستوثَقا عبر SSH ووصولا غير مستوثَق عبر git://، ولكن يوجد أيضا ميفاق يمكنه عمل كِلا الأمرين في وقت واحد.
إعداد HTTP الذكي هو ببساطة مجرد تفعيل بُرَيمج CGI الآتي مع جت المسمى git-http-backend على الخادوم.
يقرأ هذا البريمج المسار والترويسات (headers) التي يرسلها أمر الاستحضار git fetch أو الدفع git push إلى رابط HTTP ويحدد إذا كان العميل يستطيع التواصل عبر HTTP (وهذا صحيح لأي عميل جت منذ الإصدارة 1.6.6).
وإذا رأي البريمج أن العميل ذكي، فسيتواصل معه بذكاء؛ وإلا فسيتواصل معه بالميفاق البليد (ولذا فهو متوافق مع الإصدارات القديمة التي تريد القراءة فحسب).
لنرَ إعدادا بسيطا جدا. سنستخدم فيه أباتشي (Apache) كخادوم CGI. إن لم يكن لديك أباتشي مُعدًّا، فيمكنك إعداده على حاسوب لينكسي بفعل شيءٍ كهذا:
$ sudo apt-get install apache2 apache2-utils
$ a2enmod cgi alias envهذا أيضا يفعّل وِحدات mod_cgi و mod_alias و mod_env، والتي تحتاجها جميعها حتى يعمل هذا الإعداد بشكل صحيح.
سنحتاج أيضا إلى ضبط مجموعة المستخدمين اليونكسية الخاصة بمجلدات /srv/git إلى www-data، حتى يتسنّى لخادوم الوب قراءة المستودعات وتحريرها، لأن عملية أباتشي التي تشغّل بُريمج CGI الخاص بنا تعمل (مبدئيا) تحت هذا المستخدم:
$ chgrp -R www-data /srv/gitوكذلك سنحتاج إلى إضافة بعض الأشياء إلى تهيئة أباتشي لتشغيل git-http-backend معالجًا (“handler”) لأي شيء يأتي من المسار /git على خادومك.
SetEnv GIT_PROJECT_ROOT /srv/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/إن أهملت متغير البيئة GIT_HTTP_EXPORT_ALL، فلن يتيح جت للعملاء غير المستوثَقين إلا تلك المستودعات التي فيها الملف git-daemon-export-ok، تماما مثلما فعل عفريت جت.
وأخيرا سنحتاج إلى إخبار أباتشي أن يسمح بالطلبات إلى git-http-backend وأن يستوثق عمليات التحرير بطريقةٍ ما، مثلا بكتلة Auth كهذه:
<Files "git-http-backend">
AuthType Basic
AuthName "Git Access"
AuthUserFile /srv/git/.htpasswd
Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#)
Require valid-user
</Files>يتطلب هذا إنشاء ملف .htpasswd فيه كلمات المرور لجميع المستخدمين المقبولين.
هذا مثال على إضافة المستخدم “schacon” إليه:
$ htpasswd -c /srv/git/.htpasswd schaconلدى أباتشي طرائق عديدة لاستيثاق المستخدمين؛ عليك اختيار إحداها وتطبيقها. ليس هذا إلا أيسر مثال استطعنا الإتيان به. ومن شبه المؤكد أنك أيضا ستحتاج إلى إعداد هذا عبر SSH حتى تكون هذه البيانات كلها معمّاة.
لا نود الخوض عميقا في دوامة دقائق تهيئة أباتشي، لأنك قد تستخدم خادوما آخر أو أن لديك احتياجات استيثاق مختلفة.
وإنما الأمر أن مع جت بريمج CGI اسمه git-http-backend، والذي عند ندائه يفعل كل المفاوضات لإرسال واستقبال البيانات عبر HTTP.
ولكنه لا ينفذ أي استيثاق بنفسه. لكن هذا سهل التحكم فيه في مرحلة خادوم الوب الذي يناديه.
يمكنك فعل هذا مع ربما أي خادوم وب يدعم CGI، لذا فانطلق مع الخادوم الذي تعرفه حق المعرفة.
|
لمزيد من المعلومات عن تهيئة الاستيثاق في أباتشي، انظر وثائق أباتشي (بالإنجليزية) هنا: https://httpd.apache.org/docs/current/howto/auth.html. |
GitWeb
تستطيع الآن الوصول إلى مشروعك مع إذن التحرير أو مع إذن القراءة فقط. وقد تود الآن إعداد واجهة وب رسومية يسيرة له. يأتي جت مع بُريْمج CGI يسمى جتوِب والذي يُستخدم أحيانا لهذا الغرض.
فإذا أردت رؤية كيف يبدو جتوب لمشروعك، فمع جت أمر يشغّل نسخة مؤقتة منه إذا كان لديك خادوم وب خفيف على نظامك مثل lighttpd أو webrick.
على الأنظمة اللينكسية غالبا يكون lighttpd مثبتًا، فقد تستطيع تشغيله بتنفيذ git instaweb في مجلد مشروعك.
وإن كنت على ماك، فإن نسخة Leopard تأتي بلغة Ruby مثبتة مبدئيا، فيكون webrick هو الظن الأقرب.
لـبَدء instaweb بشيء غير lighttpd، فعليك تشغيله بخيار --httpd.
$ git instaweb --httpd=webrick
[2009-02-21 10:02:21] INFO WEBrick 1.3.1
[2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0]فهذا يشغّل خادوم HTTPD على منفذ 1234 ويفتح متصفح الوب على تلك الصفحة آليًّا.
فهو يسهّل عليك.
وعندما تقضي ما تريد وتود إيقاف الخادوم، نفّذ الأمر نفسه لكن بالخيار --stop:
$ git instaweb --httpd=webrick --stopوإذا كنت تود تشغيل واجهة الوب على خادوم طوال الوقت لفريقك أو لمشروع مفتوح تستضيفه، فستحتاج إلى إعداد بريمج الـ CGI ليقدّمه خادوم الوب العادي الذي تستخدمه.
بعض توزيعات لينكس تأتي بحزمة gitweb والتي قد تستطيع تثبيتها بأمر مثل apt أو dnf، لذا فقد تود تجربة هذا أولا.
سنمر سريعا جدا على تثبيت جتوب يدويا.
عليك أولا الحصول على مصدر جت، الذي فيه جتوب، ثم توليد بُرَيمج CGI المخصص:
$ git clone https://git.kernel.org/pub/scm/git/git.git
$ cd git/
$ make GITWEB_PROJECTROOT="/srv/git" prefix=/usr gitweb
SUBDIR gitweb
SUBDIR ../
make[2]: `GIT-VERSION-FILE' is up to date.
GEN gitweb.cgi
GEN static/gitweb.js
$ sudo cp -Rf gitweb /var/www/لاحظ أنك تحتاج إلى إخبار هذا الأمر بمكان مستودعاتك في المتغير GITWEB_PROJECTROOT.
والآن، تحتاج إلى جعل أباتشي يستخدم CGI لهذا البريمج، ويمكنك فعل ذلك بإضافة مستضيف وهمي (VirtualHost) له:
<VirtualHost *:80>
ServerName gitserver
DocumentRoot /var/www/gitweb
<Directory /var/www/gitweb>
Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
AllowOverride All
order allow,deny
Allow from all
AddHandler cgi-script cgi
DirectoryIndex gitweb.cgi
</Directory>
</VirtualHost>مجددا، لتقديم جتوب تستطيع استخدام أي خادوم وب يدعم CGI أو Perl. وإذا أردت شيئا آخر فليس إعداده بالصعب.
يمكنك الآن زيارة http://gitserver/ لرؤية مستودعاتك على الشابكة.
GitLab
لعلك وجدت أن جتوب GitWeb ساذجا قليلا أو كثيرا. فإذا كنت تبحث عن خادوم جت حديث ومكتمل الخصائص، فيوجد عدد من الحلول مفتوحة المصدر والتي يمكنك تثبيتها بدلا منه. ولأن جتلاب من أشهرها، فإننا سنتناول تثبيته واستخدامه مثالا. هذا الخيار أصعب من جتوب وسيحتاج منك رعاية أكثر، لكنه مكتمل الخصائص.
التثبيت
جتلاب هو تطبيق وب مبني على قاعدة بيانات، لذا فتثبيته أعقد من بعض خواديم جت الأخرى. لكن لحسن الحظ هذه العملية موثقة بالكامل ومدعومة جيدا. يوصي جتلاب بقوة بتثبيته على خادومك عبر الحزمة الرسمية الحافلة، المسماة حزمة “Omnibus GitLab”.
خيارات التثبيت الأخرى هي:
-
GitLab Helm chart، لاستخدامه مع Kubernetes.
-
حزم Docker لـ GitLab، لاستخدامها مع Docker.
-
من مِلفات المصدر.
-
موفِّرو الخدمات السحابية، مثل AWS و Google Cloud Platform و Azure و OpenShift و Digital Ocean.
للمزيد من المعلومات (بالإنجليزية) انظر GitLab Community Edition (CE) readme.
الإدارة
واجهة إدارة جتلاب هي واجهة وب.
ليس عليك إلا توجيه متصفحك إلى اسم المُضيف (“hostname”) أو عنوان IP الذي ثبتَّ عليه جتلاب، ثم لُج بحساب المدير.
اسم المستخدم المبدئي هو admin@local.host، وكلمة المرور المبدئية هي 5iveL!fe (والتي عليك تغييرها فورا).
بعد الولوج، اضغط على رمز “Admin area” (منطقة الإدارة) في القائمة التي على اليمين بالأعلى.
المستخدمون
على كل من يريد استخدام خادوم جتلاب الخاص بك الحصول على حساب مستخدم.
حسابات المستخدمين أمر يسير؛ هي في الأساس معلومات شخصية مرتبطة ببيانات الولوج.
كل حساب مستخدم لديه مساحة أسماء (“namespace”)، وهي تجميع منطقي للمشروعات الخاصة به.
فمثلا إذا كان لدى المستخدم shams مشروع اسمه project، فإن رابط ذلك المشروع سيكون http://server/shams/project.
يمكنك إزالة حساب مستخدم بطريقتين: «حظر» (“block”) حساب مستخدم يمنعه من الولوج إلى خادومك، ولكن كل بياناته التي في مساحة أسمائه ستبقى، والإيداعات الموقَّعة ببريده ستظل تشير إلى صفحته الشخصية على خادومك.
أما «محو» (“destroy”) مستخدمٍ فيزيله تماما من قاعدة البيانات ومن نظام الملفات؛ ستُزال كل المشروعات والبيانات التي في مساحة أسمائه، وكذلك كل المجموعات التي يملكها. طبعا هذا الفعل مستديم الأثر وأشد إتلافا، ونادرا ما ستحتاجه.
المجموعات
المجموعة في جتلاب هي تجميعة من المشروعات، مع معلومات عن كيفية وصول المستخدمين إلى هذه المشروعات.
كل مجموعة لديها «مساحة أسماء مشروعات»، تماما مثلما للمستخدمين، لذا فإن كان في المجموعة training مشروع اسمه materials، فسيكون رابطه http://server/training/materials.
ترتبط كل مجموعة بعدد من المستخدمين، ولكل منهم مستوى من الصلاحيات لمشروعات المجموعة وكذلك المجموعة نفسها. وتتراوح هذه المستويات من “Guest” («زائر»: للمسائل “issues” والمحادثات “chat” فقط)، إلى “Owner” («مالك»: للتحكم الكامل في المجموعة وأعضائها ومشروعاتها). وهذه المستويات كثيرة يصعب سردها هنا، لكنّ شاشة الإدارة في جتلاب فيها رابطا مفيدا.
المشروعات
المشروع في جتلاب هو تقريبا مستودع جت واحد. ينتمي كل مشروع إلى مساحة أسماء واحدة، إما لمستخدم وإما لمجموعة. وإذا كان المشروع ينتمي إلى مستخدم، فلدى مالك المشروع تحكم مباشر في من لديه حق الوصول إلى المشروع. وإذا كان ينتمي إلى مجموعة، فصلاحيات أعضاء المجموعة هي التي تحدد.
كل مشروع له مستوى ظهور، ليحدد من يستطيع رؤية صفحات هذا المشروع ومستودعه.
فإذا كان المشروع «خصوصيا» (“Private”)، فلا يظهر إلا لمن يحددهم مالك المشروع بالاسم.
وإذا كان «داخليا» (“Internal”)، فإنه لا يظهر إلا للمستخدمين الوالِجين. وإذا كان «عموميا» (“Public”) فإنه يظهر للجميع.
لاحظ أن هذا يتحكم في الوصول عبر git fetch وكذلك عند الوصول عبر واجهة الوب لهذا المشروع.
الخطاطيف
يدعم جتلاب الخطاطيف، على مستوى المشروع وعلى مستوى النظام ككل. سيرسل خادوم جتلاب طلب HTTP بطريقة POST مع JSON وصفي كلما حدثَ حدثٌ مناسب. وهذه طريقة عظيمة لربط مستودعات جت وخادوم جتلاب بباقي الأدوات الآلية التي تستخدمها ضمن التطوير، مثل خواديم التكامل المستمر CI، وغرف المحادثة، وأدوات النشر (“deployment”).
الاستخدام الأساسي
أول ما قد تود عمله على جتلاب هو إنشاء مشروع، وذلك بالضغط على رمز “+” على شريط الأدوات. ستُسأل عن اسم المشروع، ومساحة الأسماء التي ينتمي إليها، ومستوى ظهوره. معظم ما تحدده هنا ليس مستديمًا، فتستطيع تغييره فيما بعد من واجهة الإعدادات. اضغط على “Create Project” («إنشاء المشروع») لإتمام العملية.
وما إن يكون المشروع حيًّا، قد تود ربطه بمستودع محلي.
يمكن التواصل مع أي مشروع عبر HTTPS أو SSH. ويمكنك استعمال أي منهما لإضافة مستودع جت بعيد في مستودعك المحلي.
ستجد الروابط في أعلى الصفحة الرئيسية للمشروع.
فمثلا تنفيذ هذا الأمر في مستودع محلي سينشئ بعيدا بالاسم gitlab مربوطا بالمشروع المستضاف:
$ git remote add gitlab https://server/namespace/project.gitأما إذا لم يكن لديك نسخة محلية من المستودع، فيمكنك استنساخه بسهولة هكذا:
$ git clone https://server/namespace/project.gitأيضا تتيح واجهة الوب طرائق مختلفة مفيدة للنظر إلى المستودع نفسه. فتُظهر الصفحة الرئيسية لكل مشروع آخر الأنشطة، والروابط التي في أعلى الصفحة تُريك ملفات المشروع وتاريخ إيداعاته.
التعاون
أسهل طريقة للتعاون على مشروع على جتلاب هي إعطاء كل مستخدم إذن الدفع مباشرةً إلى المستودع. يمكنك إضافة المستخدمين إلى المشروع بالذهاب إلى قسم الأعضاء (“Members”) في إعدادات هذا المشروع، وربط المستخدمين الجدد بمستويات الوصول المناسبة. (مررنا على مستويات الوصول في المجموعات). إذا كان للمستخدم مستوى وصول «مطور» (“Developer”) فيستطيع دفع الإيداعات والفروع مباشرةً إلى المستودع.
لكن طريقة أخرى للتعاون بغير ضم المطورين إلى المستودع هي طلبات الدمج (“merge request”). فتتيح هذه الميزة لأي مستخدم يستطيع رؤية المشروع أن يساهم فيه بطريقة محكومة. فالمستخدمون ذوو الوصول المباشر يمكنهم إنشاء فرع ودفع إيداعاتهم إليه ثم إنشاء طلب لدمج فرعهم في الفرع الرئيس أو أي فرع آخر. أما المستخدمون الذين ليس لديهم إذن الدفع للمستودع، فيمكنهم «اشتقاق» (“fork”) المستودع لإنشاء نسختهم الخاصة منه، ودفع إيداعاتهم إلى نسختهم الخاصة بهم، ثم إنشاء طلب لدمج اشتقاقهم في المشروع الأصلي. يسمح هذا النموذج للمالك بالتحكم الكامل في كل ما يدخل المستودع ومتى يدخل، وفي الوقت نفسه يسمح بمساهمات المستخدمين غير الموثوق فيهم.
طلبات الدمج والمسائل هما أهم وحدات النقاشات الطويلة في جتلاب. فكل طلب دمج يسمح بنقاش على كل سطر من سطور التعديل المقترح (والذي يدعم نوعا خفيفا من مراجعة الكود)، إضافةً إلى نقاش عام. يمكن تكليف مستخدم بإتمام طلب دمج أو مسألة، أو جعلهما ضمن مرحلة (“milestone”).
ركّز هذا الفصل في معظمه على خصائص جتلاب المرتبطة بـجت. ولكنه مشروع ناضج ومكتمل الخصائص، ويتيح ميزات أخرى ليساعد فريقك في العمل معا، مثل موسوعات المشروعات وأدوات رعاية الأنظمة. من محاسن جتلاب أنك ما إن تتم إعداد الخادوم وتشغيله، فيندر أن تحتاج إلى تعديل ملف تهيئة أو الوصول إلى الخادوم عبر SSH؛ فواجهة الوب تتيح معظم أفعال الإدارة والاستخدام العام.
خيارات الاستضافة الخارجية
إن لم تشأ خوض غمار العمل المطلوب لإعداد خادوم جت الخاص بك، فلديك عدة خيارات لاستضافة مشروعاتك على مواقع استضافة خارجية متخصصة. لهذا منافع عديدة: أن مواقع الاستضافة عموما أسرع في الإعداد وأسهل في بدء المشروعات عليها، وليس عليك رعاية الخادوم ولا صيانته ولا مراقبته. حتى إن أعددت وشغّلت خادومك الخاص داخليا، فقد تود استخدام موقع استضافة عمومي لمشاريعك البرمجية المفتوحة؛ فهذا يسهّل على المجتمع أن يجدها ويساعدك فيها.
لدينا اليوم عدد مهول من الاستضافات، كلٌ له مزايا وعيوب مختلفة. تجد قائمة محدَّثة في صفحة الاستضافات في موسوعة جت الرسمية: https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitHosting.html.
سنتناول جتهب بالتفصيل في GitHub، لأنه أكبر استضافة جت مطلقا، وقد تحتاج إلى التعامل مع مشروعات مستضافة عليه على أيّ حال، ولكن توجد عشرات الخيارات الأخرى إذا لم تشأ إعداد خادوم جت الخاص بك.
الخلاصة
لديك عدة خيارات لإعداد وتشغيل مستودع جت بعيد حتى يمكنك التعاون من الآخرين أو مشاركة عملك.
يتيح لك تشغيل خادومك الخاص تحكمًا كبيرًا ويسمح لك بتشغيله داخل جدارك الناري (firewall) الخاص، لكن مثل هذا الخادوم يحتاج قدرًا لا بأس به من الوقت لإعداده ورعايته. أما إذا وضعت مشاريعك البرمجية على خادوم مستضاف، فستجده أسهل إعدادًا ورعايةً. لكن يجب أن يكون مسموحًا لك بذلك، فإن بعض المؤسسات لا تسمح.
نتوقع أن من السهل نسبيا تحديد الحل أو توليفة الحلول الأنسب لك ولمؤسستك.