git-receive-pack - عبر الإنترنت في السحابة

برنامج:

اسم

git-receive-pack - تلقي ما تم دفعه إلى المستودع

موجز

بوابة-استقبال-حزمة

الوصف

تحتج به طائرة نفاثة إرسال حزمة وتحديث المستودع بالمعلومات التي يتم تغذيتها من
نهاية بعيدة.

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

يسمح الأمر بإنشاء sha1 refs (الرؤوس / العلامات) وإعادة توجيهها سريعًا على ملف
النهاية البعيدة (بالمعنى الدقيق للكلمة ، إنها النهاية المحلية بوابة-استقبال-حزمة يعمل ، ولكن للمستخدم
الذي يجلس في نهاية حزمة الإرسال ، يقوم بتحديث جهاز التحكم عن بعد. مشوش؟)

هناك أمثلة أخرى من العالم الواقعي لاستخدام خطافات التحديث وما بعد التحديث الموجودة في ملف
التوثيق / دليل howto.

بوابة-استقبال-حزمة يكرم خيار التكوين الذي تم تلقيه
يجب رفض التحديثات التي يتم إجراؤها على المرجع إذا لم تكن تقدم سريعًا.

OPTIONS

المستودع المراد المزامنة فيه.

استقبال مسبق HOOK

قبل تحديث أي مرجع ، إذا كان الملف $ GIT_DIR / hooks / pre-Receive موجودًا وقابل للتنفيذ ، فإنه
سيتم استدعاؤه مرة واحدة بدون أي معلمات. سيكون الإدخال القياسي للخطاف سطرًا واحدًا
لكل مرجع يتم تحديثه:

sha1 القديم SP sha1-new اسم المرجع SP LF

قيمة refname ذات صلة بـ $ GIT_DIR ؛ على سبيل المثال لرئيس السيد هذا
"المراجع / الرؤساء / الماجستير". قيمتا sha1 قبل كل refname هي أسماء الكائنات لـ
refname قبل التحديث وبعده. ستحتوي المراجع المراد إنشاؤها على sha1 القديم يساوي 0 {40} ،
بينما المراجع المراد حذفها سيكون لها sha1-new يساوي 0 {40} ، وإلا sha1 القديم و
يجب أن يكون sha1-new كائنات صالحة في المستودع.

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

GIT_PUSH_CERT_SIGNER
الاسم وعنوان البريد الإلكتروني لمالك المفتاح الذي وقع الدفع
شهادة.

GIT_PUSH_CERT_KEY
معرف مفتاح GPG للمفتاح الذي وقع على شهادة الدفع.

GIT_PUSH_CERT_STATUS
حالة تحقق GPG من شهادة الدفع ، باستخدام نفس ذاكري
المستخدمة في٪ G؟ تنسيق عائلة أوامر git log (انظر بوابة الدخول(1)).

GIT_PUSH_CERT_NONCE
سلسلة nonce التي طلبت العملية من الموقّع تضمينها في شهادة الدفع. لو
هذا لا يتطابق مع القيمة المسجلة على العنوان "nonce" في شهادة الدفع ،
قد يشير ذلك إلى أن الشهادة صالحة يتم إعادة عرضها من ملف
جلسة منفصلة "git push".

GIT_PUSH_CERT_NONCE_STATUS

الغير مرغوب فيها
أرسل "git push --signed" رسالة nonce عندما لم نطلبه لإرسال واحد.

مفقود
لم ترسل "git push --signed" أي رأس nonce.

سيئة
أرسل "git push --signed" رسالة غير صحيحة زائفة.

OK
أرسل "git push --signed" رقم nonce الذي طلبناه من إرساله.

انحدار
أرسل "git push --signed" رسالة nonce مختلفة عما طلبناه من إرساله الآن ، ولكن
في جلسة سابقة. انظر GIT_PUSH_CERT_NONCE_SLOP متغير البيئة.

GIT_PUSH_CERT_NONCE_SLOP
أرسل "git push --signed" رسالة nonce مختلفة عما طلبناه من إرساله الآن ، ولكن في
جلسة مختلفة يختلف وقت بدئها بهذه الثواني العديدة عن
الدورة الحالية. يكون ذا مغزى فقط عندما يقول GIT_PUSH_CERT_NONCE_STATUS SLOP. اقرأ أيضا
حول المتغير ReceertNonceSlop في بوابة التكوين(1).

يتم استدعاء هذا الخطاف قبل تحديث أي اسم ref وقبل إجراء أي عمليات تحقق سريعة
نفذت.

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

قم HOOK

قبل تحديث كل مرجع ، إذا كان الملف $ GIT_DIR / hooks / update موجودًا وقابل للتنفيذ ، فهو كذلك
يتم استدعاؤه مرة واحدة لكل مرجع ، بثلاث معاملات:

$ GIT_DIR / خطاف / تحديث اسم المرجع sha1-old sha1-new

معلمة refname متعلقة بـ $ GIT_DIR ؛ على سبيل المثال لرئيس السيد هذا
"المراجع / الرؤساء / الماجستير". الوسيطتان sha1 هما أسماء الكائنات لـ refname من قبل
وبعد التحديث. لاحظ أنه يتم استدعاء الخطاف قبل تحديث refname ، لذلك
إما أن يكون sha1 القديم هو 0 {40} (بمعنى أنه لا يوجد مثل هذا المرجع بعد) ، أو يجب أن يتطابق مع ما هو موجود
مسجل في refname.

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

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

بعد الاستلام HOOK

بعد تحديث جميع المراجع (أو محاولة تحديثها) ، إذا تم تحديث أي مرجع
ناجحًا ، وإذا كان الملف $ GIT_DIR / hooks / post-Rece موجودًا وقابل للتنفيذ ، فسيكون كذلك
تم استدعاؤه مرة واحدة بدون معلمات. سيكون الإدخال القياسي للخطاف سطرًا واحدًا لكل منهما
تم تحديث المرجع بنجاح:

sha1 القديم SP sha1-new اسم المرجع SP LF

قيمة refname ذات صلة بـ $ GIT_DIR ؛ على سبيل المثال لرئيس السيد هذا
"المراجع / الرؤساء / الماجستير". قيمتا sha1 قبل كل refname هي أسماء الكائنات لـ
refname قبل التحديث وبعده. المراجع التي تم إنشاؤها سيكون لها sha1 القديم يساوي
0 {40} ، بينما المراجع التي تم حذفها سيكون لها sha1-new يساوي 0 {40} ، وإلا فإن sha1 القديم
يجب أن يكون و sha1-new كائنات صالحة في المستودع.

يمكن فحص متغيرات البيئة GIT_PUSH_CERT * ، تمامًا كما هو الحال في ربط الاستلام المسبق ،
بعد قبول الدفع الموقع.

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

#!/ بن / ش
# إرسال معلومات التحديث بالبريد.
أثناء قراءة المرجع nval البيضاوي
do
إذا كان expr "$ oval": '0 * $'> / dev / null
then
صدى "تم إنشاء مرجع جديد ، مع الالتزامات التالية:"
قائمة مراجعة git - جميلة "$ nval"
آخر
صدى "التزامات جديدة:"
قائمة مراجعة git - جميلة "$ nval" "^ $ oval"
فاي |
mail -s "التغييرات في المرجع $ ref" الالتزام - list @ mydomain
فعل
# شهادة دفع موقعة من السجل ، إن وجدت
إذا كان الاختبار -n "$ {GIT_PUSH_CERT-}" && اختبار $ {GIT_PUSH_CERT_STATUS} = G
then
(
الصدى المتوقع nonce هو $ {GIT_PUSH_NONCE}
git cat-file blob $ {GIT_PUSH_CERT}
) | "دفع شهادة البريد من $ GIT_PUSH_CERT_SIGNER" push-log @ mydomain
fi
خروج 0

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

لاحظ أنه من الممكن أن لا يحتوي refname على sha1-new عند تشغيل هذا الخطاف. هذا يمكن
تحدث بسهولة إذا قام مستخدم آخر بتعديل المرجع بعد تحديثه بواسطة بوابة-استقبال-حزمة,
ولكن قبل أن يتمكن الخطاف من تقييمه. من المستحسن أن تعتمد الخطافات على sha1-new
بدلاً من القيمة الحالية لـ refname.

تحديث منشور HOOK

بعد كل المعالجات الأخرى ، إذا تم تحديث مرجع واحد على الأقل ، وإذا كان
ملف $ GIT_DIR / hooks / post-update موجود وقابل للتنفيذ ، ثم سيتم استدعاء التحديث اللاحق
مع قائمة الحكام التي تم تحديثها. يمكن استخدام هذا لتنفيذ أي مستودع
مهام تنظيف واسعة.

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

يمكن استخدام هذا الخطاف ، على سبيل المثال ، لتشغيل git update-server-info إذا كان المستودع
معبأة ويتم تقديمها عبر وسيلة نقل غبية.

#!/ بن / ش
exec git تحديث معلومات الخادم

استخدم git-تلقي-pack عبر الإنترنت باستخدام خدمات onworks.net