Git
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-receive-pack last updated in 2.43.0

NOME

git-receive-pack - Recebe o que for impulsionado para o repositório

RESUMO

git-receive-pack <diretório>

DESCRIÇÃO

Chamado através do comando git send-pack e atualiza o repositório com as informações fornecidas pelo terminal remoto.

Este comando geralmente não é invocado diretamente pelo usuário final. O protocolo da interface do usuário está no lado git send pack, e o par de programas deve ser utilizado para enviar atualizações para o repositório remoto. Para as operações "pull", veja see git-fetch-pack[1].

O comando permite a criação e o encaminhamento rápido dos sha1 das refs (heads/tags) na extremidade remota (falando estritamente, é a extremidade local do comando git receive pack executado, porém, para o usuário que está sentado na outra extremidade do pacote de envio, é atualizando o ramo remoto. Confundiu?)

Existem outros exemplos no mundo real da utilização dos ganchos de atualização e pós-atualização encontrados no diretório Documentation/howto.

O coamndo git-receive-pack respeita a opção de configuração receive.denyNonFastForwards, que informa se as atualizações de uma "ref" devem ser negadas caso não sejam rápidas.

Uma quantidade de outras opções de configurações receive.* estão disponíveis para ajustar o seu comportamento, consulte git-config[1].

OPÇÕES

<diretório>

O repositório para sincronizar.

O GANCHO DE PRÉ-RECEBIMENTO

Antes de qualquer "ref" ser atualizada, caso o arquivo $GIT_DIR/hooks/pre-receive existir e for executável, ele será chamado uma vez e sem parâmetros. A entrada predefinido do gancho será uma linha por referência que será atualizada:

sha1-old SP sha1-new SP refname LF

O valor do refname é relativo ao $GIT_DIR; como por exemplo, para a cabeçalho principal, isto é "refs/heads/master". Os dois valores sha1 antes de cada refname são os nomes dos objetos para o refname antes e depois da atualização. As refs que serão criadas terão um sha1 antigo igual a 0{40}, enquanto as refs que serão excluídas terão um sha1 novo igual a 0{40}, caso contrário, tanto o sha1 novo quanto o sha1 antigo devem ser objetos válidos no repositório.

Ao aceitar um impulsionamento assinado (consulte git-push[1]), o certificado deste impulsionamento assinado é armazenado em uma bolha e em uma variável GIT_PUSH_CERT do ambiente onde o seu nome do objeto pode ser consultado. Um exemplo pode ser visto consultando a descrição do gancho post-receive. Além disso, o certificado é verificado utilizando o GPG e seu resultado é exportado com as seguintes variáveis de ambiente:

GIT_PUSH_CERT_SIGNER

O nome e o endereço do e-mail do proprietário da chave que assinou o certificado push.

GIT_PUSH_CERT_KEY

O ID da chave GPG da chave que assinou o certificado "push".

GIT_PUSH_CERT_STATUS

A condição da verificação do certificado GPG do impulsionamento utiliza o mesmo processo mnemônico de como é utilizado em %G?, formato da família de comandos git log (consulte git-log[1]).

GIT_PUSH_CERT_NONCE

A sequência nonce que o processo solicitou ao assinante para incluir no certificado "push". Caso isso não corresponda ao valor registrado no cabeçalho "nonce" no certificado "push", isso pode indicar que o certificado é válido e está sendo reproduzido em uma sessão separada do comando "git push".

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

O comando "git push --signed" enviou um nonce quando não pedimos para enviar um.

MISSING

O comando "git push --signed" não enviou nenhum cabeçalho nonce.

BAD

O comando "git push --signed" enviou um falso nonce.

OK

O comando "git push --signed" enviou o nonce que pedimos para ser enviado.

SLOP

O comando "git push --signed" enviou um nonce diferente do que foi pedido para enviar agora, porém em uma sessão anterior. Consulte a variável de ambiente GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP

O comando "git push --signed" enviou um nonce diferente do que foi pedido agora, porém em uma sessão diferente, cujo horário do início e é diferente em muitos segundos da sessão atual. So faz sentido quando GIT_PUSH_CERT_NONCE_STATUS diz SLOP. Leia também sobre a variável receive.certNonceSlop no git-config[1].

Este gancho é chamado antes que qualquer "refname" seja atualizado e antes que qualquer verificação de avanço rápido seja executada.

Caso o gancho pre-receive termine com uma condição diferente de zero, nenhuma atualização será executada, a atualização, os ganchos pre-receive e post-update também não serão invocados. Isso pode ser útil para o resgate rápido caso a atualização não seja compatível.

Veja as notas sobre o ambiente de quarentena abaixo.

GANCHO DE ATUALIZAÇÃO

Antes de cada "ref" que será atualizada, caso o arquivo $GIT_DIR/hooks/update existir e for executável, ele será chamado uma vez por referência, com três parâmetros:

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

O parâmetro "refname" é relativo ao $GIT_DIR; como por exemplo, para a cabeçalho principal, isto é "refs/heads/master". Os dois argumentos sha1 são os nomes dos objetos para o "refname" antes e depois da atualização. Observe que o gancho é chamado antes que o "refname" seja atualizado; portanto, o sha1 antigo é 0{40} (o que significa que essa "ref" ainda não existe) ou deve coincidir ao que está registrado no "refname".

O gancho deve encerrar com uma condição diferente de zero caso queira impedir a atualização da "ref" informada. Caso contrário, ele deve encerrar com zero.

Uma execução bem-sucedida (uma condição de encerramento com zero) deste gancho não garante que a "ref" seja realmente atualizada; é apenas um pré-requisito. Como tal, não é uma boa ideia enviar avisos (por email por exemplo) deste gancho. Em vez disso, considere utilizar o gancho pós-recebimento.

O GANCHO DO PÓS-RECEBIMENTO

Depois da atualização de todas as refs (ou que tentaram ser atualizadas), caso alguma atualização seja bem-sucedida e se o arquivo $GIT_DIR/hooks/post-receive existir e for executável, ele será chamado uma vez sem parâmetros. A entrada padrão do gancho será uma linha para cada ref atualizada com êxito:

sha1-old SP sha1-new SP refname LF

O valor do refname é relativo ao $GIT_DIR; como por exemplo, para a cabeçalho principal, isto é "refs/heads/master". Os dois valores sha1 antes de cada refname são os nomes dos objetos para o refname antes e depois da atualização. As refs que serão criadas terão um sha1 antigo igual a 0{40}, enquanto as refs que serão excluídas terão um sha1 novo igual a 0{40}, caso contrário, tanto o sha1 novo quanto o sha1 antigo devem ser objetos válidos no repositório.

As variáveis de ambiente GIT_PUSH_CERT* podem ser inspecionadas, assim como no gancho de pré-recebimento, após aceitar um "push" assinado.

Com a utilização deste gancho, é fácil gerar e-mails descrevendo as atualizações no repositório. Este script de demonstração envia uma mensagem de e-mail listando cada "ref" dos commits impulsionados ao repositório e faz o registro dos certificados dos impulsionamentos assinados com boas assinaturas em um serviço para o registro dos eventos:

#!/bin/sh
# envie as informações das atualizações dos commits por e-mail.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Foi criado uma nova ref, com os seguintes commits:"
		git rev-list --pretty "$nval"
	else
		echo "Novos commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "As alterações para a ref $ref" commit-list@mydomain
done
# registre o certificado da assinatura push, caso exista
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 "certificado push do $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

O código de encerramento vindo desta invocação do gancho é ignorado; no entanto, um código de encerramento diferente de zero gera uma mensagem de erro.

Observe que é possível para o "refname" não ter um sha1 novo durante a execução deste gancho. Isso pode ocorrer facilmente caso outro usuário modifique a "ref" após a atualização do git receive pack, porém antes que o gancho possa avaliá-lo. Recomenda-se que os ganchos confiem no sha1 novo ao invés do valor atual do "refname".

O GANCHO DE PÓS-ATUALIZAÇÃO

Após todos os outros processamentos, se pelo menos uma ref foi atualizada e caso o arquivo $GIT_DIR/hooks/post-update existe e é executável, então o "post-update" (pós-atualização) será chamada com a lista das refs que foram atualizadas. Isso pode ser utilizado para implementar qualquer outra tarefa de limpeza em todo o repositório.

O código de saída deste gancho de chamada é ignorado; a única coisa que resta para o git receive pack nesse ponto é encerrar de qualquer maneira.

Este gancho pode ser utilizado, como por exemplo, para executar git update server info caso o repositório esteja empacotado e seja servido através de um transporte burro.

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

AMBIENTE DE QUARENTENA

Quando o receive-pack recebe os objetos, eles são colocados em um diretório temporário de "quarentena" dentro do diretório $GIT_DIR/objects e migrados para o armazenamento dos objetos principais somente após a conclusão do gancho pré-recebimento. Caso o envio falhe antes, o diretório temporário será removido completamente.

Isso tem alguns efeitos e advertências visíveis ao usuário:

  1. Os impulsionamentos que falharem devido aos problemas com o pacote recebido, os objetos ausentes ou devido ao gancho do pré-recebimento não deixarão nenhum dado no disco. Geralmente é útil para impedir que impulsionamentos sem sucesso e de forma repetida preencham o seu disco, porém podem tornar a depuração muito mais desafiadora.

  2. Quaisquer objetos criados pelo gancho pre-receive (recebimento prévio) serão criados no diretório de quarentena (e migrados apenas caso sejam bem-sucedidos).

  3. O gancho pre-receive NÃO DEVE atualizar nenhuma refs para apontar para os objetos em quarentena. Outros programas que acessam o repositório não poderão ver os objetos (e se o gancho do "pre-receive" falhar, estes refs serão corrompidos). Por questões de segurança, qualquer atualização do "ref" dento do pre-receive são rejeitadas automaticamente.

VEJA TAMBÉM

git-send-pack[1], gitnamespaces[7]

GIT

Parte do conjunto git[1]

scroll-to-top