git-receive-pack - Online di Cloud

PROGRAM:

NAMA

git-receive-pack - Terima apa yang didorong ke dalam repositori

RINGKASAN

git-terima-paket

DESKRIPSI

Dipanggil oleh git kirim-paket dan memperbarui repositori dengan informasi yang diumpankan dari
ujung yang jauh.

Perintah ini biasanya tidak dipanggil langsung oleh pengguna akhir. UI untuk protokolnya adalah
pada git kirim-paket sisi, dan pasangan program dimaksudkan untuk digunakan untuk mendorong pembaruan ke
gudang jarak jauh. Untuk operasi tarik, lihat git-fetch-pack(1).

Perintah tersebut memungkinkan pembuatan dan penerusan cepat referensi sha1 (kepala/tag) di
ujung jarak jauh (tepatnya, ini adalah ujung lokal git-terima-paket berjalan, tetapi untuk pengguna
yang duduk di ujung send-pack, sedang memperbarui remote. Bingung?)

Ada contoh dunia nyata lain menggunakan kait pembaruan dan pasca-pembaruan yang ditemukan di
Direktori dokumentasi/howto.

git-terima-paket menghormati opsi konfigurasi accept.denyNonFastForwards, yang memberi tahu jika
pembaruan ke referensi harus ditolak jika tidak maju cepat.

PILIHAN

Repositori untuk disinkronkan.

PRA-TERIMA HOOK

Sebelum ref apa pun diperbarui, jika file $GIT_DIR/hooks/pre-receive ada dan dapat dieksekusi, itu
akan dipanggil sekali tanpa parameter. Input standar hook akan menjadi satu baris
per referensi untuk diperbarui:

sha1-lama SP sha1-nama baru SP refname LF

Nilai refname relatif terhadap $GIT_DIR; misalnya untuk kepala master ini adalah
"ref/kepala/master". Dua nilai sha1 sebelum setiap refname adalah nama objek untuk
refname sebelum dan sesudah pembaruan. Referensi yang akan dibuat akan memiliki sha1-old sama dengan 0{40},
sementara referensi yang akan dihapus akan memiliki sha1-baru sama dengan 0{40}, jika tidak, sha1-lama dan
sha1-new harus menjadi objek yang valid di repositori.

Saat menerima push yang ditandatangani (lihat git-push(1)), sertifikat push yang ditandatangani disimpan di a
gumpalan dan variabel lingkungan GIT_PUSH_CERT dapat dikonsultasikan untuk nama objeknya. Lihat
deskripsi kait pasca-terima sebagai contoh. Selain itu, sertifikatnya adalah
diverifikasi menggunakan GPG dan hasilnya diekspor dengan variabel lingkungan berikut:

GIT_PUSH_CERT_SIGNER
Nama dan alamat email pemilik kunci yang menandatangani push
sertifikat.

GIT_PUSH_CERT_KEY
ID kunci GPG dari kunci yang menandatangani sertifikat push.

GIT_PUSH_CERT_STATUS
Status verifikasi GPG dari sertifikat push, menggunakan mnemonik yang sama seperti
digunakan di %G? format keluarga perintah git log (lihat git-log(1)).

GIT_PUSH_CERT_NONCE
String nonce yang diminta oleh proses untuk disertakan dalam sertifikat push. Jika
ini tidak cocok dengan nilai yang dicatat pada header "nonce" di sertifikat push,
itu mungkin menunjukkan bahwa sertifikat itu valid yang sedang diputar ulang dari a
sesi "git Push" yang terpisah.

GIT_PUSH_CERT_NONCE_STATUS

TIDAK DIMINTA
"git Push --signed" mengirim nonce ketika kami tidak memintanya untuk mengirimnya.

HILANG
"git Push --signed" tidak mengirim header nonce apa pun.

BAD
"git Push --signed" mengirim nonce palsu.

OK
"git Push --signed" mengirim nonce yang kami minta untuk dikirim.

AIR KOTOR
"git Push --signed" mengirim nonce yang berbeda dari apa yang kami minta untuk dikirim sekarang, tapi
dalam sesi sebelumnya. Lihat variabel lingkungan GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" mengirim nonce yang berbeda dari apa yang kami minta untuk dikirim sekarang, tetapi dalam a
sesi berbeda yang waktu mulainya berbeda beberapa detik dari
sesi Sekarang. Hanya bermakna ketika GIT_PUSH_CERT_NONCE_STATUS mengatakan SLOP. Baca juga
tentang variabel accept.certNonceSlop di git-config(1).

Hook ini dipanggil sebelum refname apa pun diperbarui dan sebelum pemeriksaan fast-forward dilakukan
dilakukan.

Jika kait pra-terima keluar dengan status keluar bukan nol, tidak ada pembaruan yang akan dilakukan,
dan kait pembaruan, pasca-terima, dan pasca-pembaruan juga tidak akan dipanggil. Ini bisa jadi
berguna untuk menyelamatkan dengan cepat jika pembaruan tidak didukung.

UPDATE HOOK

Sebelum setiap ref diperbarui, jika file $GIT_DIR/hooks/update ada dan dapat dieksekusi, itu adalah
dipanggil sekali per ref, dengan tiga parameter:

$GIT_DIR/hook/perbarui refname sha1-old sha1-new

Parameter refname relatif terhadap $GIT_DIR; misalnya untuk kepala master ini adalah
"ref/kepala/master". Dua argumen sha1 adalah nama objek untuk refname sebelumnya
dan setelah pembaruan. Perhatikan bahwa hook dipanggil sebelum refname diperbarui, jadi
baik sha1-old adalah 0{40} (artinya belum ada referensi seperti itu), atau harus cocok dengan apa yang ada
dicatat dalam refname.

Hook harus keluar dengan status bukan nol jika ingin melarang pembaruan referensi bernama.
Kalau tidak, itu harus keluar dengan nol.

Eksekusi yang berhasil (status keluar nol) dari hook ini tidak memastikan wasit akan
sebenarnya diperbarui, itu hanya prasyarat. Karena itu, bukanlah ide yang baik untuk mengirim
pemberitahuan (misalnya email) dari hook ini. Pertimbangkan untuk menggunakan kait pasca-terima sebagai gantinya.

PASCA TERIMA HOOK

Setelah semua referensi diperbarui (atau dicoba untuk diperbarui), jika ada pembaruan referensi
berhasil, dan jika file $GIT_DIR/hooks/post-receive ada dan dapat dieksekusi, itu akan menjadi
dipanggil sekali tanpa parameter. Input standar hook akan menjadi satu baris untuk masing-masing
berhasil memperbarui ref:

sha1-lama SP sha1-nama baru SP refname LF

Nilai refname relatif terhadap $GIT_DIR; misalnya untuk kepala master ini adalah
"ref/kepala/master". Dua nilai sha1 sebelum setiap refname adalah nama objek untuk
refname sebelum dan sesudah pembaruan. Referensi yang dibuat akan memiliki sha1-old sama dengan
0{40}, sedangkan referensi yang dihapus akan memiliki sha1-new sama dengan 0{40}, jika tidak sha1-old
dan sha1-new harus menjadi objek yang valid di repositori.

Variabel lingkungan GIT_PUSH_CERT* dapat diperiksa, seperti pada kait pra-penerimaan,
setelah menerima push yang ditandatangani.

Dengan menggunakan kait ini, mudah untuk membuat email yang menjelaskan pembaruan ke repositori.
Contoh skrip ini mengirim satu pesan email per referensi yang mencantumkan komit yang didorong ke
repositori, dan mencatat sertifikat push dari push yang ditandatangani dengan tanda tangan yang baik ke a
layanan pencatat:

#!/ Bin / sh
# kirimkan informasi pembaruan komit.
sambil membaca oval nval ref
do
if expr "$oval" : '0*$' >/dev/null
kemudian
echo "Membuat referensi baru, dengan komit berikut:"
git rev-list --pretty "$nval"
lain
echo "Komit baru:"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Perubahan pada ref $ref" commit-list@mydomain
dilakukan
# log sertifikat push yang ditandatangani, jika ada
jika tes -n "${GIT_PUSH_CERT-}" && tes ${GIT_PUSH_CERT_STATUS} = G
kemudian
(
echo nonce yang diharapkan adalah ${GIT_PUSH_NONCE}
gumpalan file kucing git ${GIT_PUSH_CERT}
) | mail -s "push sertifikat dari $GIT_PUSH_CERT_SIGNER" push-log@domainsaya
fi
keluar 0

Kode keluar dari permintaan kait ini diabaikan, namun kode keluar bukan nol akan
menghasilkan pesan kesalahan.

Perhatikan bahwa refname mungkin tidak memiliki sha1-new saat hook ini berjalan. Ini bisa
mudah terjadi jika pengguna lain memodifikasi referensi setelah diperbarui oleh git-terima-paket,
tapi sebelum hook bisa mengevaluasinya. Direkomendasikan bahwa kait bergantung pada sha1-baru
daripada nilai refname saat ini.

SETELAH PEMBARUAN HOOK

Setelah semua pemrosesan lainnya, jika setidaknya satu referensi diperbarui, dan jika
File $GIT_DIR/hooks/post-update ada dan dapat dieksekusi, maka post-update akan dipanggil
dengan daftar referensi yang telah diperbarui. Ini dapat digunakan untuk mengimplementasikan repositori apa pun
tugas pembersihan yang luas.

Kode keluar dari permintaan kait ini diabaikan; satu-satunya yang tersisa untuk
git-terima-paket lakukan pada saat itu adalah untuk keluar sendiri pula.

Kait ini dapat digunakan, misalnya, untuk menjalankan git update-server-info jika repositorinya
dikemas dan disajikan melalui transportasi bodoh.

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

Gunakan git-receive-pack online menggunakan layanan onworks.net