Git
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-fetch last updated in 2.34.1

NOME

git-fetch - Faz o download dos objetos e refs do outro repositório

RESUMO

git fetch [<opções>] [<repositório> [<refspec>…​]]
git fetch [<opções>] <grupo>
git fetch --multiple [<opções>] [(<repositório> | <grupo>)…​]
git fetch --all [<opções>]

DESCRIÇÃO

Busque as ramificações ou as tags (coletivamente, refs) de um ou mais repositórios, juntamente com os objetos necessários para completar seus históricos. As ramificações de rastreamento remoto são atualizadas (consulte a descrição de <refspec> abaixo para conhecer maneiras de controlar esse comportamento).

É predefinido que qualquer tag que aponte para os históricos que estão sendo capturados também sejam capturados; o efeito é capturar as tags que apontem para os ramos nos quais você está interessado. Este comportamento predefinido pode ser alterado utilizando as opções --tags, --no-tags ou configurando remote.<nome>.tagOpt. Utilizando um refspec de forma explicita, é possível que você busque as tags que não apontam para as ramificações nas quais você também está interessado.

O git fetch pode capturar em um único repositório ou em uma determinada URL assim como em vários repositórios de uma vez caso <grupo> seja utilizado e exista um entrada remotes.<grupo> no arquivo de configuração. (Consulte git-config[1]).

Por predefinição quando nenhum ponto remoto é utilizado, o origin será utilizado, a menos que haja um ramo upstream configurado para o ramo atual.

Os nomes dos refs que são capturados, juntamente com os nomes dos objetos para os quais eles apontam, são gravados em .git/FETCH_HEAD. Essa informação pode ser utilizada por scripts ou outros comandos git, como git-pull[1].

OPÇÕES

--all

Capture todos os ramos remotos.

-a
--append

Acrescente nomes ao "ref" e os nomes dos objetos refs capturados ao conteúdo existente de .git/FETCH_HEAD. Sem esta opção, os dados antigos em .git/FETCH_HEAD serão substituídos.

--depth=<profundidade>

Limite a captura para uma quantidade específica de commits na ponta do histórico de cada ramificação remota. Caso esteja capturando um repositório shallow (superficial) criado pelo git clone com a opção --depth=<profundidade> (consulte git-clone[1]), aprofunde ou encurte o histórico para a quantidade especificada de commits. As tags para os commits aprofundados não são capturados.

--deepen=<profundidade>

Semelhante a opção --depth, exceto que especifica a quantidade de commits do limite raso atual em vez da ponta de cada histórico do ramo remoto.

--shallow-since=<data>

Aprofunde ou encurte o histórico de um repositório raso para incluir todas os commits acessíveis após a <data>.

--shallow-exclude=<revisão>

Aprofunde ou diminua o histórico de um repositório raso para excluir os commits acessíveis vindos de uma determinada tag ou ramificação remota. Esta opção pode ser utilizada várias vezes.

--unshallow

Caso o repositório de origem esteja completo, converta um repositório raso em um completo, removendo todas as limitações impostas pelos repositórios rasos.

Caso o repositório de origem seja superficial, busque o máximo possível para que o repositório atual tenha o mesmo histórico que o repositório de origem.

--update-shallow

É predefinido que durante a captura em um repositório superficial, o git fetch recuse os refs que exijam a atualização do .git/shallow. Esta opção atualiza o .git/shallow e aceita tais refs.

--negotiation-tip=<commit|glob>

É predefinido que o Git relatará ao servidor os commits acessíveis de todos as refs locais para que localize os commits comuns na tentativa de reduzir o tamanho do pacote que será recebido. Caso seja utilizado, o Git relatará apenas os commits acessíveis a partir das dicas informadas. Útil para acelerar o processo "fetch" quando o usuário sabe qual a ref local que provavelmente, haverá commits em comum com uma ref upstream que está sendo capturada.

Esta opção pode ser utilizada mais de uma vez; Se assim for, o Git irá reportar os commits de qualquer um dos commits informados.

O argumento para esta opção pode ser um "ref" aos nomes de referência, uma referência ou o (possivelmente abreviado) SHA-1 de um commit. Especificar um agrupamento é o equivalente a utilizar esta opção várias vezes, uma para cada nome "ref" coincidente.

Consulte também a variável de configuração fetch.negotiationAlgorithm documentada em git-config[1].

--dry-run

Exiba apenas o que seria feito, sem fazer quaisquer alterações.

-f
--force

Quando git fetch é utilizado com <src>:<dst> "refspec" ele pode se recusar a atualizar o ramo local como discutido na parte <refspec> abaixo. Esta opção sobrescreve esta verificação.

-k
--keep

Mantenha o pacote que foi baixado.

--multiple

Permita que vários argumentos <repositório> e <grupo> sejam utilizados. Nenhum <refspec> pode ser utilizado.

--[no-]auto-gc

Execute o git gc --auto no final para executar a coleta de lixo, caso seja necessário. A predefinição é, sempre ativado.

--[no-]write-commit-graph

Grave um grafo do commit após a captura remota. Este sobrescreve a configuração fetch.writeCommitGraph.

-p
--prune

Antes de capturar, remova as referências do rastreamento remoto que não exista mais remotamente. As tags não estão sujeitas a remoção caso sejam capturadas apenas por causa do acompanhamento automático da tag predefinida ou devido a uma opção --tags. No entanto, caso as tags seja capturadas por causa de um "refspec" explícito (na linha de comandos ou na configuração remota, por exemplo, caso haja uma clonagem remota com a opção --mirror), elas também estarão sujeitas a remoção. Informar a opção --prune-tags é uma abreviação para informar a tag refspec.

Consulte a seção de PRUNING abaixo para mais detalhes.

-p
--prune-tags

Antes de capturar, remova as tags locais que não existam mais remotamente caso a opção --prune esteja ativa. Esta opção deve ser utilizada com mais cuidado, ao contrário da opção --prune, ela removerá todas as referências locais (tags locais) que forem criadas. Esta opção é um atalho para informar a tag explícita refspec junto com a opção --prune, consulte a discussão sobre isso em sua documentação.

Consulte a seção de PRUNING abaixo para mais detalhes.

-n
--no-tags

É predefinido que as tags que apontem para os objetos baixados do repositório remoto sejam capturados e armazenadas localmente. Esta opção desativa essa tag automática a seguir. O comportamento remoto predefinido pode ser especificado com a configuração remote.<nome>.tagOpt. Consulte git-config[1].

--refmap=<refspec>

Ao capturar as refs listadas na linha de comando, utilize o "refspec" informado (pode ser utilizado mais de uma vez) para mapear os refs para as ramificações rastreadas remotamente em vez dos valores das variáveis da configuração remote.*.fetch para o repositório remoto. Informe um <refspec> vazio à opção --refmap faz com que o Git ignore os "refspecs" configurados e confie inteiramente nos "refspecs" informados como os argumentos da linha de comando. Para mais detalhes consulte a seção "Configuração dos Ramos Monitorados Remotamente".

-t
--tags

Capture todas as tags remotas (ou seja, capture as tags remotas refs/tags/* nas tags locais com o mesmo nome), além de qualquer outra coisa que possa ser capturada. O uso desta opção por si só não sujeita a remoção das tags, mesmo que --prune seja utilizado (embora as tags possam ser removidas de qualquer maneira, caso também sejam o destino de um "refspec" explícito; consulte --prune).

--recurse-submodules[=yes|on-demand|no]

Essa opção controla se e sob quais condições os novos commits dos submódulos preenchidos também devem ser capturadas. Pode ser utilizado como uma opção booleana para desativar completamente a recursão quando definido como no ou para recursar incondicionalmente em todos os sub-módulos preenchidos quando definido como sim, que é a predefinição quando esta opção é utilizada sem qualquer valor. Utilize on demand para re-examinar apenas em um submódulo preenchido quando o superprojeto recuperar um commit que atualize a referência do submódulo para um commit que ainda não esteja no clone do submódulo local. É predefinido que on demand seja utilizado, a menos que fetch.recurseSubmodules seja definido (consulte git-config[1]).

-j
--jobs=<n>

A quantidade de processos paralelos que serão utilizados para todas as formas de captura.

Caso a opção --multiple seja utilizada, os diferentes ramos remotos serão capturados em paralelo. Caso vários submódulos sejam capturados, estes serão capturados em paralelo. Para controlá-los de forma independente, utilize as definições da configuração fetch.parallel e submodule.fetchJobs (consulte git-config[1]).

Normalmente, as capturas remotas dos múltiplos ramos de forma paralela e recursiva serão mais rápidas. A predefinição é realizar as capturas em sequência e não em paralelo.

--no-recurse-submodules

Desative a captura recursiva dos submódulos (tem o mesmo efeito que utilizar a opção --recurse-submodules=no).

--set-upstream

Caso a captura remota seja bem sucedida, uma referência de rastreamento pull e add será adicionada ao "upstream", utilizado pelo argumento less git-pull[1] e outros comandos. Para mais informações, consulte branch.<nome>.merge e branch.<nome>.remote em git-config[1].

--submodule-prefix=<caminho>

Anexe o <caminho> para os caminhos impressos nas mensagens informativas como "Recolhendo o submódulo foo". Esta opção é utilizada internamente quando recorrer as submódulos.

--recurse-submodules-default=[yes|on-demand]

Esta opção é utilizada internamente para prover temporariamente um valor não negativo da forma predefinida para a opção --recurse-submodules. Todos os outros métodos de configurar a recursão do submódulo fetch (como as configurações em gitmodules[5] e git-config[1]) sobrescreva esta opção utilizando --[no-]recurse-submodules diretamente.

-u
--update-head-ok

É predefinido que o git fetch se recuse a atualizar o cabeçalho que corresponde ao ramo atual. Esta flag desativa esta verificação. Serve apenas para a utilização interna do git pull para se comunicar com o git fetch, a menos que esteja implementando a sua própria porcelana, você não deve utilizá-la.

--upload-pack <pacote-para-envio>

Quando o repositório é informado para capturar e que seja manipulado por git fetch-pack, o --exec=<upload-pack> é passado para o comando utilizar um caminho alternativo para o comando executado na outra extremidade.

-q
--quiet

Repasse a opção --quiet para o git-fetch-pack e silencie qualquer outro comando git utilizado internamente. O progresso não é relatado para o fluxo de erro predefinido.

-v
--verbose

Seja loquaz.

--progress

É predefinido que a condição geral do progresso seja relatada no fluxo de erros quando estiver conectado em um terminal, a menos que -q seja utilizado. Esta opção impõem a condição geral do progresso, mesmo que o fluxo de erro predefinido não seja direcionado para um terminal.

-o <opção>
--server-option=<opção>

Transmita a sequência especificada para o servidor ao se comunicar utilizando o protocolo versão 2. A sequência informada não deve conter um caractere NUL ou LF. O tratamento das opções do servidor, incluindo os desconhecidos, é específico do servidor. Quando a opção --server-option=<opção> forem utilizadas várias vezes, todos serão enviados para o outro lado na ordem listada na linha de comando.

--show-forced-updates

É predefinido que o Git verifique se a atualização do ramo foi imposta durante uma captura. Pode ser desativado por meio de fetch.showForcedUpdates, porém a opção `--show-forced-updates garante que essa verificação ocorra. Consulte git-config[1].

--no-show-forced-updates

É predefinido que o Git verifique se a atualização do ramo foi imposta durante uma captura. Utilize a opção --no-show-forced-updates ou defina fetch.showForcedUpdates como to false para ignorar esta verificação por questões de desempenho. Se utilizada durante o git-pull, a opção --ff-only ainda verificará quais as atualizações foram impostas antes de tentar uma atualização rápida. Consulte git-config[1].

-4
--ipv4

Utilize apenas os endereços IPv4, ignorando os endereços IPv6.

-6
--ipv6

Utilize apenas os endereços IPv6, ignorando os endereços IPv4.

<repositório>

The "remote" repository that is the source of a fetch or pull operation. Este parâmetro pode ser uma URL (consulte a seção GIT URLS abaixo) ou o nome de um ramo remoto (consulte a seção REMOTES abaixo).

<grupo>

Um nome referente para a lista de repositórios como o valor no arquivo da configuração remotes.<grupo>. (Consulte git-config[1]).

<refspec>

Determina quais as refs capturar e quais as refs locais atualizar. Quando nenhum <refspec> aparece na linha de comando, em vez disso, os refs que serão capturados são lidos a partir das variáveis remote.<repositório>.fetch (consulte CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE below).

O formato de um parâmetro <refspec> é um opcional mais +, seguido pela fonte <src>, seguido por dois pontos :, seguido pelo destino "ref" <dst>. Os dois pontos podem ser omitidos quando o destino <dst> estiver vazio. A fonte <src> normalmente é uma referência, mas também pode ser um nome de objeto escrito totalmente em hexadecimal.

A tag significa o mesmo que refs/tags/<tag>:refs/tags/<tag>; ele solicita a buscaa de tudo até a tag informada.

A "ref" remota que coincida com <src> é buscada e se <dst> não seja uma sequência vazia, é feita uma tentativa de atualizar a referência local que coincida com ela.

Caso a atualização seja permitida sem a opção --force depende do espaço de nomes da ref onde está sendo buscada, do tipo do objeto que está sendo buscado e se a atualização é considerada um avanço rápido. Geralmente, as mesmas regras se aplicam à busca e ao impulsionar, consulte a seção <refspec>... do git-push[1] para saber o que são. As exceções para estas regras específicas para o comando git fetch são anotadas abaixo.

Até a versão 2.20 do Git, e diferentemente do envio com git-push[1], qualquer atualização para refs/tags/* seria aceita sem o sinal + no refspec (ou --force). Ao buscar, consideramos promiscuamente todas as atualizações das tags de um ramo remoto como buscas impostas. Desde a versão 2.20 Git, buscar a atualização refs/tags/* funciona da mesma maneira que quando fazer um impulsionamento. Ou seja, todas as atualizações serão rejeitadas sem o sinal + no refspec (ou --force).

Ao contrário quando impulsionamos com o git-push[1], qualquer atualização fora do refs/{tags,heads}/* será aceito sem o sinal + no refspec (ou --force), seja trocando, por exemplo, um objeto de árvore para uma bolha ou um commit para outro commit que não tenha o commit anterior como ancestral, etc.

Ao contrário quando impulsionamos com o git-push[1], não existe uma configuração que corrija estas regras, e nada como um gancho pre-fetch análogo ao gancho pre-receive.

Assim como impulsionar com git-push[1], todas as regras descritas acima sobre o que não é permitido como uma atualização pode ser sobrescrito ao adicionar um caractere opcional no "refspec" começando com + (ou utilizando a opção --force na linha de comando). A única exceção a isso é que nenhuma quantidade de imposição fará com que o espaço de nomes refs/heads/* aceite um objeto que não seja um commit.

Note
Quando se sabe que o ramo remoto que você quer buscar é retrocedida e reconstruída regularmente, espera-se que o novo topo não seja descendente do topo anterior (conforme foi armazenada no ramo monitorado remotamente da última vez que você fez a busca). Você vai querer usar o sinal + para indicar que serão necessárias atualizações não rápidas para estas ramificações. Não há como determinar ou declarar que uma ramificação será disponibilizada em um repositório com este comportamento; o usuário que está capturando simplesmente deve saber que esse é o padrão de uso esperado para um ramo.

GIT URLS

Em geral as URLs contêm informações sobre o protocolo de transporte, o endereço do servidor remoto e o caminho para o repositório. Dependendo do protocolo de transporte, algumas dessas informações podem estar ausentes.

O Git suporta os protocolos ssh, git, http e https (além do ftp e ftps podem ser utilizados para capturar, porém é ineficiente e obsoleto; não utilize).

O transporte nativo (ou seja, git:// URL) não faz a autenticação e deve ser utilizado com cuidado em redes sem segurança.

As seguintes sintaxes podem ser utilizadas com eles:

  • ssh://[user@]host.xz[:port]/caminho/para/o/repositório.git/

  • git://host.xz[:port]/caminho/para/o/repositório.git/

  • http[s]://host.xz[:port]/caminho/para/o/repositório.git/

  • ftp[s]://host.xz[:port]/caminho/para/o/repositório.git/

Uma sintaxe alternativa como scp também pode ser utilizada com o protocolo ssh:

  • [user@]host.xz:caminho/para/o/repositório.git/

Essa sintaxe apenas é reconhecida caso não haja barras antes dos primeiros dois pontos. Isso ajuda a diferenciar um caminho local que contém dois pontos. Por exemplo, o caminho local foo:bar pode ser utilizado como um caminho absoluto ou ./foo:bar para evitar ser mal interpretado como uma url ssh.

Os protocolos ssh e git também oferecem suporte à expansão do ~nome do usuário:

  • ssh://[user@]host.xz[:port]/~[user]/caminho/para/o/repositório.git/

  • git://host.xz[:port]/~[user]/caminho/para/o/repositório.git/

  • [user@]host.xz:/~[user]/caminho/para/o/repositório.git/

Para os repositórios locais, as seguintes sintaxes podem ser utilizadas que também são compatíveis de forma nativa pelo Git:

  • /caminho/para/o/repositório.git/

  • file:///caminho/para/o/repositório.git/

Estas duas sintaxes são basicamente equivalentes, exceto durante a clonagem, quando a primeira implica no uso da opção --local. Para mais detalhes, consulte git-clone[1].

O git clone, git fetch e git pull, mas não o git push, também aceitarão um arquivo do pacote adequado. Consulte git-bundle[1].

Quando o Git não sabe como lidar com um determinado protocolo de transporte, quando existe, ele tenta usar o auxiliar remote-<transporte>. Para os repositórios locais, as seguintes sintaxes podem ser utilizadas:

  • <transporte>::<endereço>

onde <endereço> pode ser um caminho, um servidor e um caminho ou uma sequência arbitrária semelhante a uma URL reconhecida por um auxiliar remoto em específico que está sendo chamado. Para mais detalhes, consulte gitremote-helpers[7].

Se houver um grande número de repositórios remotos com nomes semelhantes e caso queira usar um formato diferente para eles (de modo que as URLs utilizadas sejam reescritas nas URLs que funcionam), você poderá criar uma seção de configuração da opção:

	[url "<url da base atual>"]
		insteadOf = <a url da outra base>

Por exemplo:

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

uma URL como "work:repo.git" ou como "host.xz:/caminho/para/o/repositório.git" será reescrito em qualquer contexto onde a URL seja "git://git.host.xz/repo.git".

Caso queira reescrever apenas as URLs para envio por "push" (impulsionamento), é possível criar uma seção de configuração da opção:

	[url "<url da base atual>"]
		pushInsteadOf = <a url da outra base>

Por exemplo:

	[url "ssh://exemplo.org/"]
		pushInsteadOf = git://exemplo.org/

uma URL como "git://exemplo.org/caminho/para/o/repositório.git" será reescrito para "ssh://exemplo.org/caminho/para/o/repositório.git" para os "pushes" (impulsionamentos), porém os "pulls" (obtenções) ainda usarão a URL original.

REMOTOS

O nome de um dos seguintes pode ser usado em vez de uma URL como argumento do <repositório>:

  • um ramo remoto no arquivo de configuração do Git: $GIT_DIR/config,

  • um arquivo no diretório $GIT_DIR/remotes ou

  • um arquivo no diretório $GIT_DIR/branches.

Tudo isso também permite seja omitido o refspec da linha de comando, pois cada um contém um refspec que o git utilizará de maneira predefinida.

Ramo remoto nomeado no arquivo de configuração

Você pode optar por informar o nome de um ramo remoto que você configurou anteriormente usando git-remote[1], git-config[1] ou até mesmo uma edição manual no arquivo $GIT_DIR/config. A URL deste ramo remoto será usado para acessar o repositório. É predefinido que o "refspec" deste ramo remoto será usado quando você não informar um refspec na linha de comando. A entrada no arquivo de configuração ficaria assim:

	[remote "<nome>"]
		url = <url>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

O <pushurl> é utilizado apenas para os impulsionamentos. Além de opcional a sua predefinição retorna para <url>.

Arquivo nomeado no $GIT_DIR/remotes

Você pode optar por fornecer o nome de um arquivo em $GIT_DIR/remotes. A URL neste arquivo será utilizada para acessar o repositório. O "refspec" neste arquivo será utilizado como uma predefinição quando você não informar um "refspec" na linha de comando. Este arquivo deve ter o seguinte formato:

	URL: um dos formatos da URL acima
	Push: <refspec>
	Pull: <refspec>

Push: as linhas são usadas pelo comando git push e Pull: as linhas são usadas pelo comando git pull e git fetch. Várias linhas Push: e Pull: podem ser utilizadas para mapeamentos adicionais das ramificações.

Arquivo informado em GIT_DIR/branches

Você pode decidir entre informar o nome de um arquivo no $GIT_DIR/branches. A URL neste arquivo será utilizada para acessar o repositório. Este arquivo deve ter o seguinte formato:

	<url>#<head>

A <url> é necessária; #<head> é opcional.

Dependendo da operação, o git usará um dos seguintes refspecs, caso nenhum seja utilizado na linha de comando. O <ramo> (ramo) é o nome deste arquivo no $GIT_DIR/branches e <head> retorna a predefinição para master.

O git fetch usa:

	refs/heads/<head>:refs/heads/<ramo>

O comando git push usa:

	HEAD:refs/heads/<head>

CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE

Você costuma interagir com o mesmo repositório remoto, capturando-o regularmente e de forma repetida. Para acompanhar o progresso de um repositório remoto, o git fetch permite que você configure variáveis da configuração remote.<repositório>.fetch.

Normalmente, essa variável pode ser assim:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*

Essa configuração é utilizada de duas maneiras:

  • Quando o git fetch é executado sem informar quais as ramificações ou tags capturar na linha de comando, por exemplo. Os valores git fetch origin ou git fetch, remote.<repositório>.fetch são utilizados como refspecs eles especificam quais os refs capturar e quais as refs locais atualizar. O exemplo acima capturará todas as ramificações que existem em origin (ou seja, qualquer ref que coincida ao lado esquerdo do valor, refs/heads/*) e atualizará as ramificações de rastreamento remoto correspondentes na hierarquia refs/remotes/origem/*.

  • Quando o git fetch é executado especificamente com as ramificações ou tags utilizando a linha de comando como git fetch origin master por exemplo, os <refspec> utilizados determinam uma ordem de capturar, o quê deve ser capturado (o master no exemplo é uma abreviação de master:, que por sua vez significa "capture a ramificação master, por exemplo), assim o comando no exemplo capturará apenas a ramificação master. Os valores remote.<repositório>.fetch determinam qual a ramificação remota rastreada, caso exista, será atualizada. Quando utilizados desta maneira, os valores remote.<repository>.fetch não têm nenhum efeito na decisão do quê é capturado (ou seja, os valores não são utilizados como refspecs quando a linha de comando lista refspecs); eles são utilizados apenas para decidir onde os refs que estão sendo capturados estão sendo armazenados e agem como um mapeamento.

O último valores do remote.<repositório>.fetch podem ser substituídos, ao usar os parâmetros --refmap=<refspec> na linha de comando.

PODA

A disposição predefinida do Git se organiza de forma a manter os dados a menos que sejam descartados de forma explicita; isso se estende a manter referências locais nas ramificações remotas que elas mesmas excluíram.

Se desassistidas, essas referências obsoletas podem piorar o desempenho em repositórios grandes e ocupados aonde apresentam muita rotatividade e por exemplo, façam uso de comandos como git branch -a --contains <commit> cuja saída é desnecessariamente detalhada, cautilizando impacto de desempenho em qualquer outra referência de trabalho conhecida.

Estas referências de rastreamento remoto podem ser excluídas com um único:

# Enquanto estiver fazendo a captura
$ git fetch --prune <nome>

# Exclua apenas, não busque nada
$ git remote prune <nome>

Para remover as referências como parte do seu fluxo de trabalho normal sem precisar se lembrar de executá-lo, defina fetch.prune globalmente ou com a configuração ` remote.<nome>.prune` por ramo remoto. Consulte git-config[1].

Aqui é onde as coisas ficam complicadas e bem específicas. O recurso de remoção não se importa muito com as ramificações; em vez disso, remove as referências locais <→ remotas como uma função do refspec remoto (consulte <refspec> e CRTB acima).

Portanto, caso o refspec remoto inclua refs/tags/*:refs/tags/* por exemplo ou caso execute manualmente git fetch --prune <nome> "refs/tags/*:refs/tags/*" por exemplo. As ramificações remotas rastreadas que forem excluídas não expirarão, a não ser qualquer outra tag local que não exista remotamente.

Senão for o que você deseja, caso queira remover remotamente o <nome> por exemplo e também capturar explicitamente as tags a partir dele; primeiramente, ao recolher dele você exclui todas as tags locais, a maioria das quais podem não terem vindo do <nome> remoto.

Assim, tenha cuidado ao utilizar isso com um refspec como refs/tags/*:refs/tags/* ou qualquer outro refspec que possa mapear as referências de diferentes pontos remotos para o mesmo namespace local.

Como manter-se atualizado com as ramificações e as tags remotamente é um caso de uso comum, a opção --prune-tags pode ser utilizada junto com o --prune para remover as tags locais que não existam no ponto remoto e impor a atualização dessas tags que estiverem diferentes. A remoção de tags também podem ser ativadas com fetch.pruneTags ou remote.<nome>.pruneTags nas configurações. Consulte git-config[1].

A opção --prune-tags é equivalente a ter o refs/tags/*:refs/tags/* declarado nos refspecs remotos. Isso pode ocasionar algumas interações estranhas:

# Ambas capturam as tags
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --no-tags --prune-tags origin

O motivo pelo qual não ocorre um erro durante o uso sem a opção --prune ou as suas versões de configuração, é a flexibilidade das versões configuradas, para manter um mapeamento 1=1 entre as opções da linha de comando e o que as versões das configuração fazem.

É razoável que a configuração fetch.pruneTags=true em ~/.gitconfig que as tags sejam removidas sempre que o comando git fetch --prune seja executado, sem fazer com que todas as invocações do comando git fetch sem a opção --prune cause um erro.

A remoção de tags com --prune-tags também funciona durante o resgate de uma URL em vez de um determinado nome remoto. Todas essas tags de remoção serão encontradas em origin:

$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
$ git fetch <url of origin> --prune --prune-tags
$ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'

SAÍDA

A saída do comando "git fetch" depende do método de transporte utilizado; Esta seção descreve a saída durante a utilização da captura ao utilizar o protocolo Git (localmente ou via ssh) e o protocolo inteligente "Smart HTTP".

A condição da saída durante a captura é produzida em forma de tabela, com cada linha representando a condição de uma única referência. Cada linha é uma forma de:

 <flag> <resumo> <de> -> <para> [<motivo>]

A condição das referências atualizadas é exibido caso a opção --verbose seja utilizada.

O modo de saída compacta é definida com a variável de configuração fetch.output, caso <de> ou <para> seja inteiramente encontrada em outra cadeia de caracteres, esta será substituída por * na outra cadeia de caracteres. master -> origin/master se torna master -> origin/* por exemplo.

flag

Um único caractere indicando a condição da referência:

(space)

para um avanço rápido bem sucedido;

+

para uma imposição de atualização bem sucedida;

-

para uma eliminação da referência bem sucedida;

t

para uma atualização da tag bem sucedida;

*

para a captura de uma nova referência bem sucedida;

!

para uma referência que foi rejeitada ou a sua atualização tenha falhado; e

=

para uma referência que estava atualizada e não precisou de nenhuma captura.

resumo

Para a a captura de uma referência bem sucedida, o resumo exibe os valores antigos e novos em um formato adequado para a utilização como argumento para o comando git log (<antigo>..<novo> na maioria dos casos, e <antigo>...<novo> para atualizações de avanço rápido que forem impostas).

de

The name of the remote ref being fetched from, minus its refs/<tipo>/ prefix. In the case of deletion, the name of the remote ref is "(none)".

para

The name of the local ref being updated, minus its refs/<tipo>/ prefix.

motivo

Uma explicação legível para humanos. No caso de referências capturadas com sucesso, nenhuma explicação é necessária. Para uma referência com falha, o motivo será explanado.

EXEMPLOS

  • Atualize as ramificações de rastreamento remoto:

    $ git fetch origin

    O comando acima copia todas as ramificações do refs/heads/ do espaço de nomes remoto e as armazena em refs/remotes/origin/ com um espaço de nomes local, a menos que a opção branch.<nome>.fetch seja utilizada para definir um refspec fora do que já vem predefinido.

  • Utilizando refspecs de forma explicita:

    $ git fetch origin +seen:seen maint:tmp

    Faz a atualização (ou cria, conforme seja necessário) as ramificações seen e` tmp` no repositório local, capturando as ramificações (respectivamente) seen e` maint` no repositório remoto.

    O ramo seen será atualizado ainda que não faça um avanço rápido, porque é prefixado com um sinal de mais; já o tmp não será.

  • Dê uma olhada no ramo remoto sem a configuração remota do seu repositório local:

    $ git fetch git://git.kernel.org/pub/scm/git/git.git maint
    $ git log FETCH_HEAD

    O primeiro comando captura a ramificação maint do repositório em git://git.kernel.org/pub/scm/git/git.git e o segundo comando usa FETCH_HEAD para examinar a ramificação com git-log[1]. Os objetos capturados serão eventualmente removidos pelo serviço de limpeza interno do git (consulte git-gc[1]).

SEGURANÇA

Os protocolos de busca e envio não foram projetados para impedir que um lado roube os dados do outro repositório que não deveriam ser compartilhado. Caso tenha dados particulares que precisam ser protegidos de um par malicioso, a sua melhor opção é armazená-los em um outro repositório. Isso se aplica aos clientes e aos servidores. Em particular, os espaço de nomes em um servidor não são eficazes para o controle de acesso de leitura; você só deve conceder acesso de leitura a um espaço de nomes para os clientes que você confiaria o acesso de leitura para todo o repositório.

Os vetores de ataque informados são os seguintes:

  1. A vítima envia as linhas "have" anunciando as IDs dos objetos que possui, que não são explicitamente planejados para serem compartilhados, porém podem ser usados para otimizar a transferência caso o par também os tenha. O atacante escolhe um ID do objeto X para roubar e envia uma "ref" para X, porém não é necessário enviar o conteúdo do X porque a vítima já o possui. Agora a vítima acredita que o atacante tem o X e depois envia seu conteúdo de volta ao atacante. (Esse ataque é mais simples para um cliente executar em um servidor, criando uma "ref" para X no espaço de nomes onde o cliente tem acesso e em seguida, buscando-o. A maneira mais provável de um servidor executá-lo em um cliente é "mesclar" X em um ramo público e esperar que o usuário faça um trabalho adicional neste ramo, enviá-lo de volta ao servidor sem perceber a mesclagem.)

  2. Como no item 1, o atacante escolhe um ID do objeto X para roubar. A vítima envia um objeto Y que o atacante já possui e o atacante afirma falsamente ter X e não Y; portanto, a vítima envia Y como um delta contra X. O delta revela as regiões de X que são semelhantes para Y ao atacante.

BUGS

Com a opção --recurse-submodules só pode buscar novos commits nos submódulos que já foram averiguados no momento. Quando, por exemplo, a "upstream" adicionou um novo submódulo nos commits recém-buscados do superprojeto, o submódulo em si não pode ser buscado, tornando impossível verificar o submódulo sendo necessário fazer uma nova busca mais tarde. Espera-se que isso seja corrigido em uma versão futura do Git.

VEJA TAMBÉM

GIT

Parte do conjunto git[1]

scroll-to-top