गिट-रिसीव-पैक - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

git-receive-pack - रिपॉजिटरी में जो डाला गया है उसे प्राप्त करें

SYNOPSIS

गिट-प्राप्त-पैक

वर्णन

द्वारा आमंत्रित किया गया Git भेज-पैक और रिपॉजिटरी को वहां से फीड की गई जानकारी से अपडेट करता है
दूरस्थ अंत.

यह आदेश आमतौर पर अंतिम उपयोगकर्ता द्वारा सीधे लागू नहीं किया जाता है। प्रोटोकॉल के लिए UI है
पर Git भेज-पैक साइड, और प्रोग्राम जोड़ी का उपयोग अपडेट को पुश करने के लिए किया जाता है
दूरस्थ भंडार. पुल संचालन के लिए, देखें गिट-फ़ेच-पैक(1).

कमांड पर sha1 रेफरी (हेड/टैग) बनाने और तेजी से अग्रेषित करने की अनुमति देता है
सुदूर अंत (सख्ती से कहें तो, यह स्थानीय अंत है गिट-प्राप्त-पैक चलता है, लेकिन उपयोगकर्ता के लिए
जो सेंड-पैक छोर पर बैठा है, वह रिमोट को अपडेट कर रहा है। अस्पष्ट?)

अपडेट और पोस्ट-अपडेट हुक का उपयोग करने के वास्तविक दुनिया के अन्य उदाहरण भी इसमें पाए गए हैं
दस्तावेज़ीकरण/कैसे करें निर्देशिका।

गिट-प्राप्त-पैक Receive.denyNonFastForwards कॉन्फिग विकल्प का सम्मान करता है, जो यह बताता है कि क्या
यदि रेफरी के अपडेट तेजी से आगे नहीं बढ़ रहे हैं तो उन्हें अस्वीकार कर दिया जाना चाहिए।

विकल्प

सिंक करने के लिए रिपॉजिटरी.

पूर्व प्राप्ति हुक

किसी भी रेफरी को अद्यतन करने से पहले, यदि $GIT_DIR/hooks/pre-receive फ़ाइल मौजूद है और निष्पादन योग्य है, तो यह
बिना किसी पैरामीटर के एक बार लागू किया जाएगा। हुक का मानक इनपुट एक लाइन होगा
प्रति संदर्भ अद्यतन किया जाना है:

sha1-पुराना SP sha1-नया SP रेफ़नाम LF

Refname मान $GIT_DIR से संबंधित है; उदाहरण के लिए मास्टर हेड के लिए यह है
"रेफ्स/प्रमुख/मास्टर"। प्रत्येक refname से पहले दो sha1 मान इसके लिए ऑब्जेक्ट नाम हैं
अद्यतन से पहले और बाद में नाम बदलें। बनाए जाने वाले रेफ़र्स में sha1-old 0{40} के बराबर होगा,
जबकि हटाए जाने वाले रेफरी में sha1-new 0{40} के बराबर होगा, अन्यथा sha1-पुराना और
sha1-new रिपॉजिटरी में वैध ऑब्जेक्ट होना चाहिए।

हस्ताक्षरित पुश स्वीकार करते समय (देखें गिट-पुश(1)), हस्ताक्षरित पुश प्रमाणपत्र एक में संग्रहीत है
इसके ऑब्जेक्ट नाम के लिए ब्लॉब और एक पर्यावरण चर GIT_PUSH_CERT से परामर्श लिया जा सकता है। देखना
एक उदाहरण के लिए पोस्ट-प्राप्त हुक का विवरण। इसके अलावा प्रमाण पत्र है
GPG का उपयोग करके सत्यापित किया गया है और परिणाम निम्नलिखित पर्यावरण चर के साथ निर्यात किया गया है:

GIT_PUSH_CERT_SIGNER
पुश पर हस्ताक्षर करने वाली कुंजी के स्वामी का नाम और ई-मेल पता
प्रमाण पत्र।

GIT_PUSH_CERT_KEY
पुश प्रमाणपत्र पर हस्ताक्षर करने वाली कुंजी की GPG कुंजी आईडी।

GIT_PUSH_CERT_STATUS
पुश प्रमाणपत्र के जीपीजी सत्यापन की स्थिति, उसी स्मरक का उपयोग करते हुए
%G में उपयोग किया जाता है? कमांड के गिट लॉग परिवार का प्रारूप (देखें गिट-लॉग(1))।

GIT_PUSH_CERT_NONCE
प्रक्रिया में गैर-स्ट्रिंग ने हस्ताक्षरकर्ता को पुश प्रमाणपत्र में शामिल करने के लिए कहा। अगर
यह पुश प्रमाणपत्र में "नॉन्स" हेडर पर दर्ज मूल्य से मेल नहीं खाता है,
यह संकेत दे सकता है कि प्रमाणपत्र वैध है जिसे दोबारा चलाया जा रहा है
अलग "गिट पुश" सत्र।

GIT_PUSH_CERT_NONCE_STATUS

अनचाही
"गिट पुश--साइनड" ने एक गैर भेजा जबकि हमने उससे एक भेजने के लिए नहीं कहा था।

लापता
"गिट पुश--साइनड" ने कोई भी नॉन हेडर नहीं भेजा।

खराब
"गिट पुश--साइनड" ने एक फर्जी नॉनस भेजा।

OK
जब हमने इसे भेजने के लिए कहा तो "गिट पुश--साइन्ड" ने नॉन भेज दिया।

डबरा
"गिट पुश--साइनड" ने जो हमने इसे अभी भेजने के लिए कहा था, उससे अलग एक नॉन भेजा, लेकिन
पिछले सत्र में. GIT_PUSH_CERT_NONCE_SLOP पर्यावरण चर देखें।

GIT_PUSH_CERT_NONCE_SLOP
"गिट पुश--साइनड" ने जो हमने इसे अभी भेजने के लिए कहा था, उससे भिन्न एक नॉन भेजा, लेकिन एक में
अलग-अलग सत्र जिनका प्रारंभ समय इतने सेकंड से भिन्न है
वर्तमान सत्र। केवल तभी सार्थक जब GIT_PUSH_CERT_NONCE_STATUS SLOP कहता है। यह भी पढ़ें
Receive.certNonceSlop वैरिएबल के बारे में गिट-कॉन्फ़िगरेशन(1).

किसी भी रेफनेम को अपडेट करने से पहले और किसी भी फास्ट-फॉरवर्ड चेक से पहले इस हुक को कॉल किया जाता है
प्रदर्शन किया।

यदि प्री-रिसीव हुक गैर-शून्य निकास स्थिति के साथ बाहर निकलता है तो कोई अपडेट नहीं किया जाएगा,
और अपडेट, पोस्ट-प्राप्ति और पोस्ट-अपडेट हुक भी लागू नहीं किए जाएंगे। यह हो सकता है
यदि अद्यतन का समर्थन नहीं किया जाना है तो शीघ्रता से बाहर निकलने के लिए उपयोगी है।

अद्यतन हुक

प्रत्येक रेफरी को अद्यतन करने से पहले, यदि $GIT_DIR/hooks/update फ़ाइल मौजूद है और निष्पादन योग्य है, तो यह है
प्रति रेफरी एक बार लागू किया गया, तीन मापदंडों के साथ:

$GIT_DIR/हुक/अद्यतन refname sha1-पुराना sha1-नया

Refname पैरामीटर $GIT_DIR से संबंधित है; उदाहरण के लिए मास्टर हेड के लिए यह है
"रेफ्स/प्रमुख/मास्टर"। दो sha1 तर्क पहले refname के लिए ऑब्जेक्ट नाम हैं
और अद्यतन के बाद. ध्यान दें कि रिफ़नेम अपडेट होने से पहले हुक को कॉल किया जाता है, इसलिए
या तो sha1-old 0{40} है (मतलब अभी तक ऐसा कोई रेफरी नहीं है), या इसे जो है उससे मेल खाना चाहिए
Refname में दर्ज किया गया।

यदि हुक नामित रेफरी को अद्यतन करने की अनुमति नहीं देना चाहता है तो उसे गैर-शून्य स्थिति के साथ बाहर निकलना चाहिए।
अन्यथा इसे शून्य के साथ बाहर निकलना चाहिए।

इस हुक का सफल निष्पादन (शून्य निकास स्थिति) रेफरी सुनिश्चित नहीं करता है
वास्तव में अद्यतन होना, यह केवल एक शर्त है। ऐसे में भेजना अच्छा विचार नहीं है
इस हुक से नोटिस (जैसे ईमेल)। इसके बजाय पोस्ट-रिसीव हुक का उपयोग करने पर विचार करें।

पोस्ट-प्राप्ति हुक

सभी रेफरी अपडेट होने के बाद (या अपडेट करने का प्रयास किया गया), यदि कोई रेफरी अपडेट था
सफल, और यदि $GIT_DIR/hooks/post-receive फ़ाइल मौजूद है और निष्पादन योग्य है, तो यह होगा
बिना किसी पैरामीटर के एक बार लागू किया गया। हुक का मानक इनपुट प्रत्येक के लिए एक लाइन होगा
सफलतापूर्वक अद्यतन रेफरी:

sha1-पुराना SP sha1-नया SP रेफ़नाम LF

Refname मान $GIT_DIR से संबंधित है; उदाहरण के लिए मास्टर हेड के लिए यह है
"रेफ्स/प्रमुख/मास्टर"। प्रत्येक refname से पहले दो sha1 मान इसके लिए ऑब्जेक्ट नाम हैं
अद्यतन से पहले और बाद में नाम बदलें। बनाए गए रेफ्स में sha1-पुराना बराबर होगा
0{40}, जबकि हटाए गए रेफरी में sha1-नया 0{40} के बराबर होगा, अन्यथा sha1-पुराना होगा
और sha1-new रिपॉजिटरी में वैध ऑब्जेक्ट होना चाहिए।

GIT_PUSH_CERT* पर्यावरण चर का निरीक्षण किया जा सकता है, जैसे पूर्व-प्राप्त हुक में,
एक हस्ताक्षरित धक्का स्वीकार करने के बाद.

इस हुक का उपयोग करके, रिपॉजिटरी के अपडेट का वर्णन करने वाले मेल जेनरेट करना आसान है।
यह उदाहरण स्क्रिप्ट प्रति रेफरी एक मेल संदेश भेजती है जिसमें पुश किए गए कमिट सूचीबद्ध होते हैं
रिपॉजिटरी, और अच्छे हस्ताक्षरों के साथ हस्ताक्षरित पुश के पुश प्रमाणपत्रों को लॉग करता है
लकड़हारा सेवा:

#!/ बिन / श
# प्रतिबद्ध अद्यतन जानकारी मेल करें।
जबकि ओवल एनवल रेफरी पढ़ें
do
यदि expr "$oval" : '0*$' >/dev/null
फिर
इको "निम्नलिखित प्रतिबद्धताओं के साथ एक नया रेफरी बनाया गया:"
गिट रेव-लिस्ट--सुंदर "$nval"
अन्य
प्रतिध्वनि "नई प्रतिबद्धताएँ:"
गिट रेव-लिस्ट --सुंदर "$nval" "^$ओवल"
फाई |
मेल -एस "रेफरी $रेफ में परिवर्तन" कमिट-लिस्ट@मायडोमेन
किया
# हस्ताक्षरित पुश प्रमाणपत्र लॉग करें, यदि कोई हो
यदि परीक्षण -n "${GIT_PUSH_CERT-}" && परीक्षण ${GIT_PUSH_CERT_STATUS} = G
फिर
(
प्रतिध्वनि अपेक्षित नॉन्स ${GIT_PUSH_NONCE} है
गिट कैट-फ़ाइल ब्लॉब ${GIT_PUSH_CERT}
) | मेल-एस "$GIT_PUSH_CERT_SIGNER से पुश प्रमाणपत्र" पुश-लॉग@मायडोमेन
fi
बाहर निकलें 0

इस हुक आह्वान से निकास कोड को नजरअंदाज कर दिया जाता है, हालांकि एक गैर-शून्य निकास कोड होगा
एक त्रुटि संदेश उत्पन्न करें.

ध्यान दें कि जब यह हुक चलता है तो refname में sha1-new न होना संभव है। ये हो सकता है
यदि कोई अन्य उपयोगकर्ता रेफरी को अद्यतन करने के बाद संशोधित करता है तो यह आसानी से हो सकता है गिट-प्राप्त-पैक,
लेकिन इससे पहले कि हुक इसका मूल्यांकन कर पाता। यह अनुशंसा की जाती है कि हुक sha1-new पर निर्भर रहें
Refname के वर्तमान मान के बजाय।

पोस्ट-अपडेट हुक

अन्य सभी प्रसंस्करण के बाद, यदि कम से कम एक रेफरी अद्यतन किया गया था, और यदि
$GIT_DIR/हुक/पोस्ट-अपडेट फ़ाइल मौजूद है और निष्पादन योग्य है, तो पोस्ट-अपडेट को कॉल किया जाएगा
अद्यतन किए गए रेफरी की सूची के साथ। इसका उपयोग किसी भी रिपॉजिटरी को लागू करने के लिए किया जा सकता है
व्यापक सफ़ाई कार्य.

इस हुक आमंत्रण से निकास कोड को अनदेखा कर दिया गया है; के लिए एकमात्र चीज बची है
गिट-प्राप्त-पैक उस बिंदु पर ऐसा करना वैसे भी स्वयं से बाहर निकलना है।

इस हुक का उपयोग किया जा सकता है, उदाहरण के लिए, यदि रिपॉजिटरी है तो git update-server-info को चलाने के लिए
पैक किया जाता है और डंब ट्रांसपोर्ट के माध्यम से परोसा जाता है।

#!/ बिन / श
कार्यकारी गिट अद्यतन-सर्वर-जानकारी

onworks.net सेवाओं का उपयोग करके ऑनलाइन git-receive-pack का उपयोग करें