git-receive-pack - מקוון בענן

תָכְנִית:

שֵׁם

git-receive-pack - קבלו את מה שנדחף למאגר

תַקצִיר

git-receive-pack

תיאור

מופעל על ידי סילון שלח-חבילה ומעדכן את המאגר במידע המוזן מה-
קצה מרוחק.

פקודה זו בדרך כלל אינה מופעלת ישירות על ידי משתמש הקצה. ממשק המשתמש של הפרוטוקול הוא
על סילון שלח-חבילה צד, וצמד התוכניות נועד לשמש כדי לדחוף עדכונים ל
מאגר מרוחק. לפעולות משיכה, ראה git-fetch-pack(1).

הפקודה מאפשרת יצירה והעברה מהירה של sha1 refs (ראשים/תגים) ב-
הקצה המרוחק (למען האמת, זה הקצה המקומי git-receive-pack פועל, אלא למשתמש
מי שיושב בקצה השליחה, הוא מעדכן את השלט. מְבוּלבָּל?)

ישנן דוגמאות אחרות בעולם האמיתי לשימוש בווי עדכון ואחרי עדכון שנמצאו ב-
ספריית תיעוד/איך לעשות.

git-receive-pack מכבד את אפשרות התצורה receive.denyNonFastForwards, שאומרת לו אם
יש לדחות עדכונים לשופט אם הם אינם מהירים קדימה.

אפשרויות

המאגר שיש לסנכרן אליו.

קבלה מראש וו

לפני עדכון כלשהו של תקן, אם קובץ $GIT_DIR/hooks/pre-receive קיים והוא בר הפעלה, זה
יופעל פעם אחת ללא פרמטרים. הקלט הסטנדרטי של הקרס יהיה קו אחד
לכל שופט לעדכון:

sha1-old SP sha1-new SP refname LF

ערך refname הוא יחסי ל-$GIT_DIR; למשל עבור ראש המאסטר זה
"שופטים/ראשים/מאסטר". שני ערכי sha1 לפני כל refname הם שמות האובייקטים עבור
refname לפני ואחרי העדכון. לשוונים שייווצרו יהיה sha1-old שווה ל-0{40},
בעוד של-refs שיימחק יהיה sha1-new שווה ל-0{40}, אחרת sha1-old ו-
sha1-new צריכים להיות אובייקטים חוקיים במאגר.

בעת קבלת דחיפה חתומה (ראה git-push(1)), תעודת הדחיפה החתומה מאוחסנת ב-a
blob ומשתנה סביבה GIT_PUSH_CERT ניתן לעיין בשם האובייקט שלו. לִרְאוֹת
התיאור של וו לאחר קבלת דוגמה. בנוסף, התעודה היא
מאומת באמצעות GPG והתוצאה מיוצאת עם משתני הסביבה הבאים:

GIT_PUSH_CERT_SIGNER
השם וכתובת הדואר האלקטרוני של בעל המפתח שחתם על הדחיפה
תעודה.

GIT_PUSH_CERT_KEY
מזהה מפתח GPG של המפתח שחתם על אישור הדחיפה.

GIT_PUSH_CERT_STATUS
הסטטוס של אימות GPG של תעודת הדחיפה, באמצעות אותו מנמוניק כמו
בשימוש ב-%G? פורמט של משפחת פקודות git log (ראה git-log(1)).

GIT_PUSH_CERT_NONCE
המחרוזת הלא נמנעת שהתהליך ביקש מהחותם לכלול בתעודת הדחיפה. אם
זה לא תואם את הערך שנרשם בכותרת "nonce" באישור הדחיפה,
זה עשוי להצביע על כך שהאישור תקף המופעל מחדש מ-a
הפעלה נפרדת של "דחיפה בכוח".

GIT_PUSH_CERT_NONCE_STATUS

לְלֹא הַזמָנָה
"git push --signed" שלח הודעה כאשר לא ביקשנו לשלוח אחת.

MISSING
"git push --signed" לא שלח שום כותרת לא אחת.

רע
"git push --signed" שלח הודעה מזויפת.

OK
"git push --signed" שלח את ההודעה שביקשנו ממנה לשלוח.

סלופ
"git push --signed" שלח הודעה שונה ממה שביקשנו לשלוח עכשיו, אבל
בפגישה קודמת. ראה משתנה סביבה GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" שלח הודעה שונה ממה שביקשנו לשלוח עכשיו, אבל ב-a
הפעלה שונה שזמן ההתחלה שלה שונה בשניות רבות כל כך מה
הפגישה הנוכחית. משמעותי רק כאשר GIT_PUSH_CERT_NONCE_STATUS אומר SLOP. קרא גם
על משתנה receive.certNonceSlop ב git-config(1).

הוק הזה נקרא לפני עדכון של שם רשום כלשהו ולפני בדיקות הרצה קדימה
מְבוּצָע.

אם הוק לפני הקבלה יוצא עם סטטוס יציאה שאינו אפס, לא יבוצעו עדכונים,
וגם הוקס של עדכון, שלאחר קבלה ואחרי עדכון לא יופעלו. זה יכול להיות
שימושי לחילוץ מהיר אם אין לתמוך בעדכון.

עדכון וו

לפני עדכון של כל תקן, אם קובץ $GIT_DIR/hooks/update קיים והוא בר הפעלה, הוא
מופעל פעם אחת לכל שופט, עם שלושה פרמטרים:

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

הפרמטר refname הוא יחסי ל-$GIT_DIR; למשל עבור ראש המאסטר זה
"שופטים/ראשים/מאסטר". שני הארגומנטים sha1 הם שמות האובייקטים עבור ה-refname שלפני
ואחרי העדכון. שימו לב שה-hook נקרא לפני שה-refname מתעדכן, אז
או sha1-old הוא 0{40} (כלומר שעדיין אין שופט כזה), או שהוא צריך להתאים למה שהוא
רשום ב-refname.

ה-hook אמור לצאת עם סטטוס שאינו אפס אם הוא רוצה לא לאפשר עדכון של ה-ref הנקרא.
אחרת זה צריך לצאת עם אפס.

ביצוע מוצלח (מצב יציאה אפס) של הוק זה לא מבטיח שהשופט ירצה
למעשה להתעדכן, זה רק תנאי מוקדם. ככזה זה לא רעיון טוב לשלוח
הודעות (למשל אימייל) מהוו הזה. שקול להשתמש בוו לאחר הקבלה במקום זאת.

לאחר קבלת וו

לאחר שכל השופטים עודכנו (או ניסו להתעדכן), אם היה עדכון שופט כלשהו
מצליח, ואם קובץ $GIT_DIR/hooks/post-receive קיים וניתן להפעלה, הוא יהיה
הופעל פעם אחת ללא פרמטרים. הקלט הסטנדרטי של הקרס יהיה שורה אחת לכל אחד
ר''פ עודכן בהצלחה:

sha1-old SP sha1-new SP refname LF

ערך refname הוא יחסי ל-$GIT_DIR; למשל עבור ראש המאסטר זה
"שופטים/ראשים/מאסטר". שני ערכי sha1 לפני כל refname הם שמות האובייקטים עבור
refname לפני ואחרי העדכון. Refs שנוצרו יהיו sha1-old שווה ל
0{40}, בעוד שלשואים שנמחקו יהיה sha1-new שווה ל-0{40}, אחרת sha1-old
ו-sha1-new צריכים להיות אובייקטים חוקיים במאגר.

ניתן לבדוק את משתני הסביבה GIT_PUSH_CERT*, בדיוק כמו ב-pre-receive hook,
לאחר קבלת דחיפה חתומה.

באמצעות הוק זה, קל ליצור מיילים המתארים את העדכונים למאגר.
סקריפט לדוגמה זה שולח הודעת דואר אחת לכל נציג המפרט את ההתחייבויות שנדחפו ל-
מאגר, ומתעד את אישורי הדחיפה של דחיפות חתומות עם חתימות טובות ל-a
שירות לוגר:

#!/ Bin / sh
# שלח מידע על עדכון התחייבות.
תוך כדי קריאה אובלי nval ref
do
if expr "$oval" : '0*$' >/dev/null
אז
echo "יצר שופט חדש, עם ההתחייבויות הבאות:"
git rev-list --די "$nval"
אחר
echo "חדש מתחייב:"
git rev-list --די "$nval" "^$oval"
פי |
mail -s "שינויים ל-ref $ref" commit-list@mydomain
עשה
# אישור דחיפה חתום ביומן, אם יש
אם מבחן -n "${GIT_PUSH_CERT-}" && מבחן ${GIT_PUSH_CERT_STATUS} = G
אז
(
ההד הצפוי ללא הפסקה הוא ${GIT_PUSH_NONCE}
git cat-file blob ${GIT_PUSH_CERT}
) | mail -s "תעודת דחיפה מ-$GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
צא מ- 0

מתעלמים מקוד היציאה מקריאת ה-hook הזו, אולם קוד יציאה שאינו אפס יעשה זאת
ליצור הודעת שגיאה.

שימו לב שיכול להיות של-refname לא יהיה sha1-new כאשר ה-hook הזה פועל. זה יכול
להתרחש בקלות אם משתמש אחר משנה את ה-ref לאחר שהוא עודכן על ידי git-receive-pack,
אבל לפני שהוו הצליח להעריך את זה. מומלץ שהווים יסתמכו על sha1-new
במקום הערך הנוכחי של refname.

לאחר עדכון וו

לאחר כל העיבודים האחרים, אם לפחות שו"פ אחד עודכן, ואם
קובץ $GIT_DIR/hooks/post-update קיים וניתן להפעלה, ולאחר מכן ייקרא פוסט העדכון
עם רשימת השופטים שעודכנו. זה יכול לשמש כדי ליישם כל מאגר
משימות ניקיון רחבות.

מתעלמים מקוד היציאה מקריאת ה-hook זו; הדבר היחיד שנשאר ל
git-receive-pack לעשות בשלב זה הוא לצאת מעצמו בכל מקרה.

ניתן להשתמש בהוק הזה, למשל, כדי להפעיל git update-server-info אם המאגר הוא
ארוז ומוגש באמצעות הובלה מטומטמת.

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

השתמש ב-git-receive-pack באינטרנט באמצעות שירותי onworks.net