Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
- 2.43.1 → 2.45.2 no changes
- 2.43.0
11/20/23
- 2.39.1 → 2.42.3 no changes
- 2.39.0
12/12/22
- 2.34.1 → 2.38.5 no changes
- 2.34.0
11/15/21
- 2.24.1 → 2.33.8 no changes
- 2.24.0
11/04/19
- 2.18.1 → 2.23.4 no changes
- 2.18.0
06/21/18
- 2.14.6 → 2.17.6 no changes
- 2.13.7
05/22/18
- 2.12.5 no changes
- 2.11.4
09/22/17
- 2.5.6 → 2.10.5 no changes
- 2.4.12
05/05/17
- 2.3.10 no changes
- 2.2.3
09/04/15
- 2.1.4 no changes
- 2.0.5
12/17/14
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 um 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 de refs sha1 (cabeçalhos/tags) na extremidade remota (a rigor, é o git-receive-pack da extremidade local que é executado, mas para o usuário que está sentado na extremidade do pacote de envio, ele está atualizando o remoto. Ficou confuso?)
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
- <git-dir>
O repositório para sincronizar.
- --http-backend-info-refs
Utilizado por git-http-backend[1] para servir até os pedido
$GIT_URL/info/refs?service=git-receive-pack
. Consulte--http-backend-info-refs
em git-upload-pack[1].
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
; 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 numa bolha e numa 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 comandosgit 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 numa 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 numa 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 numa 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
dizSLOP
. Leia também sobre a variávelreceive.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
; 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
; 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 num 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, 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 num 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:
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.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).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 dopre-receive
são rejeitadas automaticamente.
GIT
Parte do conjunto git[1]