git-receive-pack

--http-backend-info-refs git-http-backend(1) tarafından $GIT_URL/info/refs?service=git-receive-pack isteklerine hizmet vermek için kullanılır. git-upload-pack(1) içindeki --http-backend-info-refs bölümüne bakın.

--skip-connectivity-check Erişilebilir nesnelerin geçişli kapanımındaki (transitive closure) tüm nesnelerin varlığını doğrulayan bağlantı kontrollerini atlar. Bu seçenek, Git dışında kendi nesne bağlantı doğrulamasını uygulamak isteyen sunucu operatörleri için tasarlanmıştır. Bu, sunucu tarafının Git'in nasıl kullanıldığına dair ek bilgilere sahip olduğu ve bu sayede Git'in kendisinin yapamayacağı şekilde nesne bağlantısını daha verimli hesaplamak için belirli güvencelere güvenebileceği durumlarda yararlıdır. Tam erişilebilir nesne bağlantısını sağlayacak güvenilir bir harici mekanizma olmadan bu seçeneğin kullanılması depoyu bozma riski taşır ve genel durumlarda kullanılmamalıdır.

Pre-Receive Kancası (Hook)

Herhangi bir referans güncellenmeden önce, eğer $GIT_DIR/hooks/pre-receive dosyası mevcutsa ve çalıştırılabilir durumdaysa, parametresiz olarak bir kez çağrılır. Kancanın standart girdisi, güncellenecek her referans için bir satır olacaktır:

sha1-old SP sha1-new SP refname LF

refname değeri $GIT_DIR dizinine göredir; örneğin master dalı (head) için bu "refs/heads/master" şeklindedir. Her refname'den önceki iki sha1 değeri, güncellemeden önceki ve sonraki refname nesne adlarıdır. Yeni oluşturulacak referanslar için sha1-old değeri 0{40} değerine eşit olacak, silinecek referanslar için ise sha1-new değeri 0{40} değerine eşit olacaktır; aksi takdirde sha1-old ve sha1-new depoda geçerli nesneler olmalıdır.

İmzalı bir itme (signed push) kabul edildiğinde (bkz. git-push(1)), imzalı itme sertifikası bir blob içinde saklanır ve nesne adı için bir GIT_PUSH_CERT çevre değişkenine başvurulabilir. Örnek için post-receive kancasının açıklamasına bakın. Ek olarak sertifika GPG kullanılarak doğrulanır ve sonuç aşağıdaki çevre değişkenleriyle dışa aktarılır:

GIT_PUSH_CERT_SIGNER İtme sertifikasını imzalayan anahtarın sahibinin adı ve e-posta adresi.

GIT_PUSH_CERT_KEY İtme sertifikasını imzalayan anahtarın GPG anahtar kimliği (ID).

GIT_PUSH_CERT_STATUS İtme sertifikasının GPG doğrulama durumu; git log komut ailesinin %G? biçiminde kullanılan anımsatıcının aynısını kullanır (bkz. git-log(1)).

GIT_PUSH_CERT_NONCE Sürecin imzalayandan itme sertifikasına dahil etmesini istediği tek seferlik dize (nonce). Eğer bu, itme sertifikasındaki "nonce" başlığında kaydedilen değerle eşleşmiyorsa, sertifikanın ayrı bir "git push" oturumundan yeniden oynatılan (replay) geçerli bir sertifika olduğunu gösterebilir.

GIT_PUSH_CERT_NONCE_STATUS

UNSOLICITED "git push --signed" biz istemediğimiz halde bir nonce gönderdi.

MISSING "git push --signed" herhangi bir nonce başlığı göndermedi.

BAD "git push --signed" geçersiz bir nonce gönderdi.

OK "git push --signed" göndermesini istediğimiz nonce değerini gönderdi.

SLOP "git push --signed" şu an göndermesini istediğimizden farklı, ancak önceki bir oturumda gönderdiğimiz bir nonce değerini gönderdi. GIT_PUSH_CERT_NONCE_SLOP çevre değişkenine bakın.

GIT_PUSH_CERT_NONCE_SLOP "git push --signed" şu an göndermesini istediğimizden farklı, ancak başlangıç zamanı mevcut oturumdan bu kadar saniye farklı olan farklı bir oturumda bir nonce gönderdi. Yalnızca GIT_PUSH_CERT_NONCE_STATUS değeri SLOP olduğunda anlamlıdır. Ayrıca git-config(1) kılavuzundaki receive.certNonceSlop değişkenini okuyun.

Bu kancanın çağrılması, herhangi bir refname güncellenmeden ve herhangi bir ileri sarma (fast-forward) kontrolü yapılmadan önce gerçekleşir.

Eğer pre-receive kancası sıfır olmayan bir çıkış durumuyla sonlanırsa, hiçbir güncelleme yapılmayacaktır ve update, post-receive ile post-update kancaları da çağrılmayacaktır. Bu, güncelleme desteklenmiyorsa işlemden hızlıca vazgeçmek için yararlı olabilir.

Aşağıdaki karantina ortamıyla ilgili notlara bakın.

Update Kancası (Hook)

Her bir referans güncellenmeden önce, eğer $GIT_DIR/hooks/update dosyası mevcutsa ve çalıştırılabilir durumdaysa, her bir referans için bir kez olmak üzere üç parametreyle çağrılır:

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

refname parametresi $GIT_DIR dizinine göredir; örneğin master dalı için bu "refs/heads/master" şeklindedir. İki sha1 argümanı, güncellemeden önceki ve sonraki refname nesne adlarıdır. Kancanın refname güncellenmeden önce çağrıldığını unutmayın; dolayısıyla ya sha1-old 0{40} değerindedir (böyle bir referansın henüz mevcut olmadığı anlamına gelir) ya da refname içinde kaydedilenle eşleşmelidir.

Kanca, belirtilen referansın güncellenmesine izin vermemek istiyorsa sıfır olmayan bir durumla çıkış yapmalıdır. Aksi takdirde sıfırla çıkmalıdır.

Bu kancanın başarıyla yürütülmesi (sıfır çıkış durumu), referansın gerçekten güncelleneceğini garanti etmez, yalnızca bir ön koşuldur. Bu nedenle, bu kancadan bildirim (örneğin e-posta) göndermek iyi bir fikir değildir. Bunun yerine post-receive kancasını kullanmayı düşünün.

Post-Receive Kancası (Hook)

Tüm referanslar güncellendikten (veya güncellenmeye çalışıldıktan) sonra, herhangi bir referans güncellemesi başarılı olmuşsa ve $GIT_DIR/hooks/post-receive dosyası mevcutsa ve çalıştırılabilir durumdaysa, parametresiz olarak bir kez çağrılır. Kancanın standart girdisi, başarıyla güncellenen her referans için bir satır olacaktır:

sha1-old SP sha1-new SP refname LF

refname değeri $GIT_DIR dizinine göredir; örneğin master dalı için bu "refs/heads/master" şeklindedir. Her refname'den önceki iki sha1 değeri, güncellemeden önceki ve sonraki refname nesne adlarıdır. Oluşturulan referanslar için sha1-old değeri 0{40} değerine eşit olacak, silinen referanslar için ise sha1-new değeri 0{40} değerine eşit olacaktır; aksi takdirde sha1-old ve sha1-new depoda geçerli nesneler olmalıdır.

GIT_PUSH_CERT* çevre değişkenleri, tıpkı pre-receive kancasında olduğu gibi imzalı bir itme kabul edildikten sonra incelenebilir.

Bu kancayı kullanarak, depodaki güncellemeleri açıklayan e-postalar oluşturmak oldukça kolaydır. Bu örnek betik, referans başına depoya itilen commit'leri listeleyen bir e-posta iletisi gönderir ve geçerli imzalara sahip imzalı itmelerin itme sertifikalarını bir günlük kaydı (logger) servisine kaydeder:

#!/bin/sh
# commit güncelleme bilgilerini e-posta ile gönder.
while read oval nval ref
do
if expr "$oval" : '0*$' >/dev/null
then
echo "Aşağıdaki commit'lerle yeni bir ref oluşturuldu:"
git rev-list --pretty "$nval"
else
echo "Yeni commit'ler:"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Changes to ref $ref" commit-list@mydomain
done
# varsa imzalı itme sertifikasını günlüğe kaydet
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
(
echo expected nonce is ${GIT_PUSH_NONCE}
git cat-file blob ${GIT_PUSH_CERT}
) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

Bu kanca çağrısından dönen çıkış kodu yoksayılır, ancak sıfır olmayan bir çıkış kodu bir hata mesajı oluşturacaktır.

Bu kanca çalıştığında refname'in sha1-new değerine sahip olmamasının mümkün olduğunu unutmayın. Bu durum, başka bir kullanıcı ref'i git-receive-pack tarafından güncellendikten sonra fakat kanca onu değerlendiremeden önce değiştirirse kolayca meydana gelebilir. Kancaların refname'in mevcut değeri yerine sha1-new değerine güvenmesi önerilir.

Post-Update Kancası (Hook)

Diğer tüm işlemlerden sonra, en az bir referans güncellenmişse ve $GIT_DIR/hooks/post-update dosyası mevcutsa ve çalıştırılabilir durumdaysa, güncellenen referansların listesiyle birlikte post-update çağrılacaktır. Bu, depo genelindeki herhangi bir temizlik görevini uygulamak için kullanılabilir.

Bu kanca çağrısından dönen çıkış kodu yoksayılır; git-receive-pack'in bu noktada yapacağı tek şey zaten kendisinden çıkış yapmaktır.

Bu kanca, örneğin depo paketlenmişse (packed) ve aptal bir taşıma (dumb transport) protokolü üzerinden sunuluyorsa git update-server-info komutunu çalıştırmak için kullanılabilir.

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

Karantina Ortamı

receive-pack nesneleri aldığında, bunlar $GIT_DIR/objects dizini içindeki geçici bir "karantina" dizinine yerleştirilir ve yalnızca pre-receive kancası tamamlandıktan sonra ana nesne deposuna taşınır. İtme işlemi bundan önce başarısız olursa, geçici dizin tamamen kaldırılır.

Bunun kullanıcı tarafından görülebilen birkaç etkisi ve uyarısı vardır:

1. Gelen paketteki sorunlar, eksik nesneler veya pre-receive kancası nedeniyle başarısız olan itmeler diskte herhangi bir veri bırakmaz. Bu genellikle başarısız itmelerin diskinizi doldurmasını önlemek için yararlıdır, ancak hata ayıklamayı daha zor hale getirebilir.

2. pre-receive kancası tarafından oluşturulan tüm nesneler karantina dizininde oluşturulacaktır (ve yalnızca başarılı olursa taşınacaktır).

3. pre-receive kancası, herhangi bir referansı karantinaya alınmış nesneleri gösterecek şekilde GÜNCELLEMEMELİDİR. Depoya erişen diğer programlar nesneleri göremeyecektir (ve pre-receive kancası başarısız olursa, bu referanslar bozulacaktır). Güvenlik için, pre-receive içerisinden yapılan tüm referans güncellemeleri otomatik olarak reddedilir.

Ayrıca Bakınız

git-send-pack(1), gitnamespaces(7)

Git

git(1) paketinin bir parçasıdır

Git 2.50.1.428.g0e8243 2025-07-22 GIT-RECEIVE-PACK(1)