git-receive-pack - ക്ലൗഡിൽ ഓൺലൈനായി

പട്ടിക:

NAME

git-receive-pack - റിപ്പോസിറ്ററിയിലേക്ക് തള്ളുന്നത് സ്വീകരിക്കുക

സിനോപ്സിസ്

git-സ്വീകരിക്കൽ-പാക്ക്

വിവരണം

വിളിച്ചത് ജിറ്റിനെ അയയ്ക്കുക-പാക്ക് എന്നിവയിൽ നിന്നുള്ള വിവരങ്ങൾ ഉപയോഗിച്ച് ശേഖരം അപ്ഡേറ്റ് ചെയ്യുന്നു
വിദൂര അവസാനം.

ഈ കമാൻഡ് സാധാരണയായി അന്തിമ ഉപയോക്താവ് നേരിട്ട് അഭ്യർത്ഥിക്കില്ല. പ്രോട്ടോക്കോളിനുള്ള UI ആണ്
ന് ജിറ്റിനെ അയയ്ക്കുക-പാക്ക് വശം, കൂടാതെ അപ്‌ഡേറ്റുകൾ പുഷ് ചെയ്യാൻ പ്രോഗ്രാം ജോടി ഉപയോഗിക്കാനാണ് ഉദ്ദേശിക്കുന്നത്
റിമോട്ട് റിപ്പോസിറ്ററി. പുൾ പ്രവർത്തനങ്ങൾക്കായി, കാണുക ഗിറ്റ്-ഫെച്ച്-പാക്ക്(1).

sha1 റെഫുകൾ (ഹെഡുകൾ/ടാഗുകൾ) സൃഷ്ടിക്കുന്നതിനും വേഗത്തിൽ ഫോർവേഡ് ചെയ്യുന്നതിനും കമാൻഡ് അനുവദിക്കുന്നു
റിമോട്ട് എൻഡ് (കർശനമായി പറഞ്ഞാൽ, ഇത് പ്രാദേശിക അവസാനമാണ് git-സ്വീകരിക്കൽ-പാക്ക് പ്രവർത്തിക്കുന്നു, പക്ഷേ ഉപയോക്താവിന്
അയയ്‌ക്കുന്ന പായ്ക്ക് അറ്റത്ത് ഇരിക്കുന്നയാൾ റിമോട്ട് അപ്‌ഡേറ്റ് ചെയ്യുന്നു. ആശയക്കുഴപ്പത്തിലാണോ?)

അപ്‌ഡേറ്റും പോസ്റ്റ്-അപ്‌ഡേറ്റ് ഹുക്കുകളും ഉപയോഗിക്കുന്നതിന് മറ്റ് യഥാർത്ഥ ലോക ഉദാഹരണങ്ങളുണ്ട്
ഡോക്യുമെന്റേഷൻ/എങ്ങനെ ഡയറക്‌ടറി.

git-സ്വീകരിക്കൽ-പാക്ക് റിസീവ്.denyNonFastForwards കോൺഫിഗറേഷൻ ഓപ്ഷനെ മാനിക്കുന്നു, അത് ഉണ്ടെങ്കിൽ അത് പറയുന്നു
ഒരു റെഫറിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ ഫാസ്റ്റ് ഫോർവേഡ് അല്ലെങ്കിൽ നിരസിക്കപ്പെടേണ്ടതാണ്.

ഓപ്ഷനുകൾ

സമന്വയിപ്പിക്കാനുള്ള ശേഖരം.

മുൻകൂട്ടി സ്വീകരിക്കുക HOOK

ഏതെങ്കിലും റെഫർ അപ്ഡേറ്റ് ചെയ്യുന്നതിനുമുമ്പ്, $GIT_DIR/hooks/pre-receive ഫയൽ നിലവിലുണ്ടെങ്കിൽ അത് എക്സിക്യൂട്ടബിൾ ആണെങ്കിൽ, അത്
പരാമീറ്ററുകളില്ലാതെ ഒരിക്കൽ അഭ്യർത്ഥിക്കും. ഹുക്കിന്റെ സ്റ്റാൻഡേർഡ് ഇൻപുട്ട് ഒരു വരി ആയിരിക്കും
ഓരോ റഫറൻസിനും അപ്‌ഡേറ്റ് ചെയ്യണം:

sha1-പഴയ എസ്പി ഷാ1-പുതിയ എസ്പിയുടെ പുനർനാമം LF

പുനർനാമകരണ മൂല്യം $GIT_DIR-ന് ആപേക്ഷികമാണ്; ഉദാ: മാസ്റ്റർ ഹെഡ് ഇത്
"refs/heads/Master". ഓരോ പുനർനാമകരണത്തിനും മുമ്പുള്ള രണ്ട് ഷാ1 മൂല്യങ്ങൾ വസ്തു നാമങ്ങളാണ്
അപ്ഡേറ്റിന് മുമ്പും ശേഷവും പേരുമാറ്റുക. സൃഷ്ടിക്കേണ്ട അവലംബങ്ങൾക്ക് 1{0} എന്നതിന് തുല്യമായ sha40-ഓൾഡ് ഉണ്ടായിരിക്കും,
അതേസമയം, ഇല്ലാതാക്കേണ്ട അവലംബങ്ങൾക്ക് sha1-new-ന് തുല്യമായ 0{40} ഉണ്ടായിരിക്കും, അല്ലാത്തപക്ഷം sha1-പഴയതും
sha1-new റിപ്പോസിറ്ററിയിൽ സാധുവായ ഒബ്‌ജക്‌റ്റുകൾ ആയിരിക്കണം.

ഒപ്പിട്ട പുഷ് സ്വീകരിക്കുമ്പോൾ (കാണുക git-push(1)), ഒപ്പിട്ട പുഷ് സർട്ടിഫിക്കറ്റ് സംഭരിച്ചിരിക്കുന്നത് a
ബ്ലോബും ഒരു എൻവയോൺമെന്റ് വേരിയബിളായ 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" തലക്കെട്ടിൽ രേഖപ്പെടുത്തിയിരിക്കുന്ന മൂല്യവുമായി ഇത് പൊരുത്തപ്പെടുന്നില്ല,
a എന്നതിൽ നിന്ന് വീണ്ടും പ്ലേ ചെയ്യുന്ന സർട്ടിഫിക്കറ്റ് സാധുതയുള്ള ഒന്നാണെന്ന് ഇത് സൂചിപ്പിക്കാം
പ്രത്യേക "ജിറ്റ് പുഷ്" സെഷൻ.

GIT_PUSH_CERT_NONCE_STATUS

ആവശ്യപ്പെടാത്തത്
"git push --signed" ഒരെണ്ണം അയയ്ക്കാൻ ഞങ്ങൾ ആവശ്യപ്പെടാത്തപ്പോൾ ഒരു നോൺസ് അയച്ചു.

മിസ്സിംഗ്
"git push --signed" ഒരു തലക്കെട്ടും അയച്ചില്ല.

മോശമായ
"git push --signed" എന്ന വ്യാജേന അയച്ചു.

OK
"git push --signed" ഞങ്ങൾ അയയ്‌ക്കാൻ ആവശ്യപ്പെട്ടിട്ടില്ലാത്തത് അയച്ചു.

SLOP
"git push --signed" ഞങ്ങൾ ഇപ്പോൾ അയയ്‌ക്കാൻ ആവശ്യപ്പെട്ടതിൽ നിന്ന് വ്യത്യസ്‌തമായി അയച്ചു, പക്ഷേ
മുൻ സെഷനിൽ. GIT_PUSH_CERT_NONCE_SLOP പരിസ്ഥിതി വേരിയബിൾ കാണുക.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" ഞങ്ങൾ ഇപ്പോൾ അയയ്‌ക്കാൻ ആവശ്യപ്പെട്ടതിൽ നിന്ന് വ്യത്യസ്‌തമായി അയച്ചു, എന്നാൽ a
വ്യത്യസ്‌ത സെഷനിൽ നിന്ന് ആരംഭിക്കുന്ന സമയം വ്യത്യസ്‌തമാണ്
നിലവിലെ സെഷൻ. GIT_PUSH_CERT_NONCE_STATUS SLOP എന്ന് പറയുമ്പോൾ മാത്രം അർത്ഥപൂർണ്ണമാണ്. ഇതും വായിക്കുക
സ്വീകരിക്കുക.certNonceSlop വേരിയബിളിനെ കുറിച്ച് git-config(1).

ഏതെങ്കിലും പുനർനാമകരണം അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് മുമ്പും ഏതെങ്കിലും ഫാസ്റ്റ്-ഫോർവേഡ് പരിശോധനകൾക്ക് മുമ്പും ഈ ഹുക്ക് വിളിക്കുന്നു
നിർവഹിച്ചു.

പ്രീ-റിസീവ് ഹുക്ക് പൂജ്യമല്ലാത്ത എക്സിറ്റ് സ്റ്റാറ്റസോടെ പുറത്തുകടക്കുകയാണെങ്കിൽ, അപ്‌ഡേറ്റുകളൊന്നും നടപ്പിലാക്കില്ല,
കൂടാതെ അപ്ഡേറ്റ്, പോസ്റ്റ്-റിസീവ്, പോസ്റ്റ്-അപ്ഡേറ്റ് ഹുക്കുകൾ എന്നിവയും അഭ്യർത്ഥിക്കില്ല. ഇത് ആകാം
അപ്‌ഡേറ്റ് പിന്തുണയ്‌ക്കേണ്ടതില്ലെങ്കിൽ വേഗത്തിൽ ജാമ്യം ലഭിക്കാൻ ഉപയോഗപ്രദമാണ്.

അപ്ഡേറ്റ് HOOK

ഓരോ റഫറൻസും അപ്ഡേറ്റ് ചെയ്യുന്നതിനുമുമ്പ്, $GIT_DIR/hooks/update ഫയൽ നിലവിലുണ്ടെങ്കിൽ അത് എക്സിക്യൂട്ടബിൾ ആണെങ്കിൽ, അത്
മൂന്ന് പാരാമീറ്ററുകൾക്കൊപ്പം ഓരോ റഫറൻസിനും ഒരിക്കൽ അഭ്യർത്ഥിച്ചു:

$GIT_DIR/hooks/update refname sha1-old sha1-new

പുനർനാമകരണ പാരാമീറ്റർ $GIT_DIR-ന് ആപേക്ഷികമാണ്; ഉദാ: മാസ്റ്റർ ഹെഡ് ഇത്
"refs/heads/Master". രണ്ട് ഷാ1 ആർഗ്യുമെന്റുകൾ മുമ്പ് പുനർനാമകരണത്തിനുള്ള വസ്‌തുനാമങ്ങളാണ്
അപ്ഡേറ്റ് ശേഷം. പുനർനാമം അപ്ഡേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഹുക്ക് വിളിക്കപ്പെടുന്നു എന്നത് ശ്രദ്ധിക്കുക
ഒന്നുകിൽ sha1-ഓൾഡ് 0{40} ആണ് (അതായത് ഇതുവരെ അങ്ങനെ ഒരു റഫറൻസ് ഇല്ല) അല്ലെങ്കിൽ അത് ഉള്ളതുമായി പൊരുത്തപ്പെടണം
പുനർനാമത്തിൽ രേഖപ്പെടുത്തി.

പേരുള്ള റഫറൻസ് അപ്‌ഡേറ്റ് ചെയ്യുന്നത് അനുവദിക്കാതിരിക്കണമെങ്കിൽ ഹുക്ക് പൂജ്യമല്ലാത്ത സ്റ്റാറ്റസോടെ പുറത്തുകടക്കണം.
അല്ലെങ്കിൽ പൂജ്യത്തോടെ പുറത്തുകടക്കണം.

ഈ ഹുക്കിന്റെ വിജയകരമായ നിർവ്വഹണം (ഒരു സീറോ എക്സിറ്റ് സ്റ്റാറ്റസ്) റെഫർ ഇച്ഛാശക്തി ഉറപ്പാക്കുന്നില്ല
യഥാർത്ഥത്തിൽ അപ്ഡേറ്റ് ചെയ്യണം, ഇത് ഒരു മുൻവ്യവസ്ഥ മാത്രമാണ്. ആ നിലയ്ക്ക് അയക്കുന്നത് നല്ലതല്ല
ഈ ഹുക്കിൽ നിന്നുള്ള അറിയിപ്പുകൾ (ഉദാ. ഇമെയിൽ). പകരം പോസ്റ്റ്-റിസീവ് ഹുക്ക് ഉപയോഗിക്കുന്നത് പരിഗണിക്കുക.

പോസ്റ്റ്-സ്വീകരിക്കുക HOOK

എല്ലാ റെഫറുകളും അപ്‌ഡേറ്റ് ചെയ്‌തതിന് ശേഷം (അല്ലെങ്കിൽ അപ്‌ഡേറ്റ് ചെയ്യാൻ ശ്രമിച്ചു), ഏതെങ്കിലും റെഫ് അപ്‌ഡേറ്റ് ആണെങ്കിൽ
വിജയിച്ചു, കൂടാതെ $GIT_DIR/hooks/post-receive ഫയൽ നിലവിലുണ്ടെങ്കിൽ അത് എക്സിക്യൂട്ടബിൾ ആണെങ്കിൽ, അത്
പരാമീറ്ററുകളില്ലാതെ ഒരിക്കൽ അഭ്യർത്ഥിച്ചു. ഹുക്കിന്റെ സ്റ്റാൻഡേർഡ് ഇൻപുട്ട് ഓരോന്നിനും ഒരു വരി ആയിരിക്കും
വിജയകരമായി അപ്ഡേറ്റ് ref:

sha1-പഴയ എസ്പി ഷാ1-പുതിയ എസ്പിയുടെ പുനർനാമം LF

പുനർനാമകരണ മൂല്യം $GIT_DIR-ന് ആപേക്ഷികമാണ്; ഉദാ: മാസ്റ്റർ ഹെഡ് ഇത്
"refs/heads/Master". ഓരോ പുനർനാമകരണത്തിനും മുമ്പുള്ള രണ്ട് ഷാ1 മൂല്യങ്ങൾ വസ്തു നാമങ്ങളാണ്
അപ്ഡേറ്റിന് മുമ്പും ശേഷവും പേരുമാറ്റുക. സൃഷ്ടിച്ച അവലംബങ്ങൾക്ക് sha1-ഓൾഡ് തുല്യമായിരിക്കും
0{40}, ഇല്ലാതാക്കിയ അവലംബങ്ങൾക്ക് 1
കൂടാതെ sha1-new എന്നത് റിപ്പോസിറ്ററിയിലെ സാധുവായ ഒബ്‌ജക്‌റ്റുകളായിരിക്കണം.

GIT_PUSH_CERT* എൻവയോൺമെന്റ് വേരിയബിളുകൾ, പ്രീ-റിസീവിംഗ് ഹുക്ക് പോലെ പരിശോധിക്കാവുന്നതാണ്,
ഒപ്പിട്ട പുഷ് സ്വീകരിച്ച ശേഷം.

ഈ ഹുക്ക് ഉപയോഗിച്ച്, റിപ്പോസിറ്ററിയിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ വിവരിക്കുന്ന മെയിലുകൾ സൃഷ്ടിക്കുന്നത് എളുപ്പമാണ്.
ഈ ഉദാഹരണ സ്‌ക്രിപ്‌റ്റ് ഒരു റെഫറിലേക്ക് ഒരു മെയിൽ സന്ദേശം അയയ്‌ക്കുന്നു
റിപ്പോസിറ്ററി, ഒപ്പം ഒപ്പിട്ട പുഷുകളുടെ പുഷ് സർട്ടിഫിക്കറ്റുകൾ നല്ല ഒപ്പുകളോടെ ലോഗ് ചെയ്യുന്നു a
ലോഗർ സേവനം:

#!/ bin / sh
# മെയിൽ ഔട്ട് കമ്മിറ്റ് അപ്‌ഡേറ്റ് വിവരങ്ങൾ.
ഓവൽ nval ref വായിക്കുമ്പോൾ
do
if expr "$oval" : '0*$' >/dev/null
അപ്പോള്
പ്രതിധ്വനി "ഇനിപ്പറയുന്ന കമ്മിറ്റുകൾക്കൊപ്പം ഒരു പുതിയ റെഫർ സൃഷ്ടിച്ചു:"
git rev-list --മനോഹരമായ "$nval"
മറ്റാരെങ്കിലും
പ്രതിധ്വനി "പുതിയ പ്രതിബദ്ധതകൾ:"
git rev-list --pretty "$nval" "^$oval"
fi |
മെയിൽ -s "റഫർ $ref ലേക്കുള്ള മാറ്റങ്ങൾ" commit-list@mydomain
ചെയ്തു
# ലോഗ് ഒപ്പിട്ട പുഷ് സർട്ടിഫിക്കറ്റ്, എന്തെങ്കിലും ഉണ്ടെങ്കിൽ
if test -n "${GIT_PUSH_CERT-}" && ടെസ്റ്റ് ${GIT_PUSH_CERT_STATUS} = ജി
അപ്പോള്
(
പ്രതിധ്വനി പ്രതീക്ഷിക്കുന്നത് ${GIT_PUSH_NONCE} ആണ്
git cat-file blob ${GIT_PUSH_CERT}
) | മെയിൽ -s "$GIT_PUSH_CERT_SIGNER ൽ നിന്നുള്ള പുഷ് സർട്ടിഫിക്കറ്റ്" push-log@mydomain
fi
പുറത്തുകടക്കുക 0

ഈ ഹുക്ക് ഇൻവോക്കേഷനിൽ നിന്നുള്ള എക്‌സിറ്റ് കോഡ് അവഗണിക്കപ്പെടും, എന്നിരുന്നാലും ഒരു നോൺ-സീറോ എക്‌സിറ്റ് കോഡ് ചെയ്യും
ഒരു പിശക് സന്ദേശം സൃഷ്ടിക്കുക.

ഈ ഹുക്ക് പ്രവർത്തിക്കുമ്പോൾ പുനർനാമകരണത്തിന് sha1-new ഉണ്ടാകാതിരിക്കാൻ സാധിക്കുമെന്നത് ശ്രദ്ധിക്കുക. ഇതിന് കഴിയും
ref അപ്‌ഡേറ്റ് ചെയ്‌തതിന് ശേഷം മറ്റൊരു ഉപയോക്താവ് അത് പരിഷ്‌ക്കരിച്ചാൽ അത് എളുപ്പത്തിൽ സംഭവിക്കും git-സ്വീകരിക്കൽ-പാക്ക്,
എന്നാൽ ഹുക്ക് അതിനെ വിലയിരുത്തുന്നതിന് മുമ്പ്. ഹുക്കുകൾ sha1-ന്യൂവിനെ ആശ്രയിക്കാൻ ശുപാർശ ചെയ്യുന്നു
പുനർനാമകരണത്തിന്റെ നിലവിലെ മൂല്യത്തേക്കാൾ.

പോസ്റ്റ്-അപ്ഡേറ്റ് HOOK

മറ്റെല്ലാ പ്രോസസ്സിംഗിനും ശേഷം, കുറഞ്ഞത് ഒരു റെഫറെങ്കിലും അപ്‌ഡേറ്റ് ചെയ്‌തിട്ടുണ്ടെങ്കിൽ, എങ്കിൽ
$GIT_DIR/hooks/post-update ഫയൽ നിലവിലുണ്ട്, അത് എക്സിക്യൂട്ടബിൾ ആണ്, തുടർന്ന് പോസ്റ്റ്-അപ്ഡേറ്റ് എന്ന് വിളിക്കപ്പെടും
അപ്‌ഡേറ്റ് ചെയ്‌ത റെഫറുകളുടെ പട്ടികയ്‌ക്കൊപ്പം. ഏത് ശേഖരണവും നടപ്പിലാക്കാൻ ഇത് ഉപയോഗിക്കാം
വിശാലമായ ശുചീകരണ ജോലികൾ.

ഈ ഹുക്ക് ഇൻവോക്കേഷനിൽ നിന്നുള്ള എക്സിറ്റ് കോഡ് അവഗണിക്കപ്പെട്ടു; അവശേഷിക്കുന്നത് മാത്രം
git-സ്വീകരിക്കൽ-പാക്ക് ആ ഘട്ടത്തിൽ ചെയ്യുന്നത് എങ്ങനെയും സ്വയം പുറത്തുകടക്കുക എന്നതാണ്.

റിപ്പോസിറ്ററി ആണെങ്കിൽ git update-server-info പ്രവർത്തിപ്പിക്കാൻ ഈ ഹുക്ക് ഉപയോഗിക്കാം
പാക്ക് ചെയ്ത് ഒരു ഊമ ഗതാഗതം വഴി നൽകപ്പെടുന്നു.

#!/ bin / sh
exec git update-server-info

onworks.net സേവനങ്ങൾ ഉപയോഗിച്ച് git-receive-pack ഓൺലൈനായി ഉപയോഗിക്കുക