Git

git-fetch last updated in 2.46.2

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

Obtenha as ramificações e/ou as etiquetas (coletivamente, "refs") de um ou mais repositórios, juntamente com os objetos necessários para completar os seus históricos. As ramificações de rastreamento remoto são atualizadas (consulte a descrição de <refspec> abaixo para obter formas de controlar este comportamento).

É predefinido que qualquer etiqueta que aponte para os históricos que estão sendo obtidos também seja obtido; o efeito é obter as etiquetas que apontem para as ramificações onde você esteja interessado. Este comportamento predefinido pode ser alterado com o uso das opções --tags ou --no-tags ou com a configuração remote.<nome>.tagOpt. Ao usar um refspec que obtenha as etiquetas de forma explícita, você também pode obter as etiquetas que não apontam para as ramificações onde você esteja interessado.

O git fetch pode obter num único repositório ou determinada URL, ou em vários repositórios de uma só vez se o <grupo> for usado e houver uma 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 das referências que forem obtidas, juntamente com os nomes dos objetos para onde elas apontam, são gravados em .git/FETCH_HEAD. Estas informações podem ser usadas por scripts ou outros comandos git, como git-pull[1].

OPÇÕES

--[no-]all: Fetch all remotes, except for the ones that has the remote.<name>.skipFetchAll configuration variable set. This overrides the configuration variable fetch.all`.
-a
--append: Acrescenta os nomes das refs e os nomes dos objetos das refs obtidas ao conteúdo existente do .git/FETCH_HEAD. Sem essa opção, os dados antigos em .git/FETCH_HEAD serão substituídos.
--atomic: Utilize uma transação atômica para atualizar as refs locais. Ou todas as refs são atualizadas ou por erro, nenhuma será.
--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 usada 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 reduza o histórico de um repositório superficial para excluir os commits acessíveis a partir de um ramo ou tag remoto informada. Esta opção pode ser utilizada várias vezes.
--unshallow: Caso o repositório de origem esteja completo, converta um repositório raso num 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 num 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 relate ao servidor os commits acessíveis a partir de todas as refs locais para encontrar commits comuns numa tentativa de reduzir o tamanho do pacote dos arquivos que serão recebidos. Se for especificado, o Git relatará apenas os commits acessíveis a partir das dicas fornecidas. Isso é útil para acelerar as obtenções quando o usuário sabe qual ref local provavelmente terá commits em comum com a ref upstream que está sendo buscada.

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 e push.negotiate documentada em git-config[1] e na opção --negotiate-only abaixo.
--negotiate-only: Não busque nada do servidor e imprima os argumentos --negotiation-tip=* fornecidos anteriormente e que nós temos em comum com o servidor.

Isso é incompatível com --recurse-submodules=[yes|on-demand]. Internamente, isso é usado para implementar a opção push.negotiate, para mais detalhes consulte git-config[1].
--dry-run: Exiba apenas o que seria feito, sem fazer quaisquer alterações.
--porcelain: Imprima na saída padrão num formato fácil para scripts. Consulte a seção OUTPUT em git-fetch[1] para obter mais detalhes.

Isso é compatível com a opção --recurse-submodules=[yes|on-demand] e tem precedência sobre a opção de configuração fetch.output.
--[no-]write-fetch-head: Escreva a lista de refs remotas obtidas no arquivo FETCH_HEAD diretamente em $GIT_DIR. Esta é a predefinição. Usar a opção --no-write-fetch-head na linha de comando diz ao Git para não escrever o arquivo. Na opção --dry-run, o arquivo nunca é gravado.
-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-maintenance
--[no-]auto-gc: Execute git maintenance run --auto no final para realizar a manutenção automática do repositório, caso seja necessário. (--[no-]auto-gc é um sinônimo.) A predefinição é ativado.
--[no-]write-commit-graph: Grave um grafo do commit após a captura remota. Este sobrescreve a configuração fetch.writeCommitGraph.
--prefetch: Altere o refspec configurado para colocar todos os refs no namespace refs/prefetch/. Consulte a tarefa prefetch em git-maintenance[1].
-p
--prune: Antes de obter, remova todas as referências de rastreamento remoto que não existam mais no ramo remoto. As tags não estão sujeitas à poda se forem apenas obtidas devido ao acompanhamento automático da tag predefinida ou devido a uma opção --tags. No entanto, se as tags forem obtidas através de uma refspec explícita (na linha de comando ou na configuração remota, por exemplo, se o ramo remoto tiver sido clonado com a opção --mirror), elas também estarão sujeitas à poda. Usar a opção --prune-tags é um atalho para fornecer 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 apontam para objetos que são baixados do repositório remoto são obtidas e armazenadas localmente. Essa opção desativa o acompanhamento automático de tags. O comportamento padrão de um ramo remoto pode ser especificado com a configuração remote.<nome>.tagOpt. Consulte git-config[1].
--refetch: Em vez de negociar com o servidor para evitar a transferência dos commits e dos objetos associados que já estão presentes no local, esta opção faz a busca de todos os objetos da mesma maneira que seria feito com um novo clone. Use isso para reaplicar um filtro de clone parcial da configuração ou usando --filter= quando a definição do filtro for alterada. A manutenção automática pós-busca realizará a consolidação do pacote no banco de dados dos objetos para seja removido quaisquer objetos duplicados.
--refmap=<refspec>: Ao obter as refs listadas na linha de comando, use o refspec especificado (pode ser usado mais de uma vez) para mapear as refs nas ramificações de rastreamento remoto, em vez dos valores das variáveis de configuração remote.*.fetch do repositório remoto. Fornecer um <refspec> vazio para a opção --refmap faz com que o Git ignore os refspecs configurados e confie inteiramente nos refspecs fornecidos como argumentos da linha de comando. Consulte a seção "Configurações dos Ramos Monitorados Remotamente" para obter detalhes.
-t
--tags: Obtém todas as tags do ramo remoto (ou seja, obtém as tags remotas refs/tags/* em tags locais com o mesmo nome), além de tudo o que seria obtido de outra maneira. O uso dessa opção por si só não sujeita as tags à poda, mesmo que a opção --prune seja usada (embora as tags possam ser podadas de qualquer forma se também forem 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 também devem ser obtidos. Ao percorrer os submódulos, o git fetch sempre tenta obter os submódulos "alterados", ou seja, um submódulo que tenha commits referenciados por um commit de superprojeto recém-buscado, mas que esteja faltando no clone do submódulo local. Um submódulo alterado pode ser buscado desde que esteja presente localmente, por exemplo, em $GIT_DIR/modules/ (consulte gitsubmodules[7]); se o upstream adicionar um novo submódulo, esse submódulo não poderá ser buscado até que seja clonado, por exemplo, pelo comando git submodule update.

Quando for definido como sob demanda, apenas os submódulos que tenham sido alterados são buscados. Quando for definido como yes, todos os submódulos que tenham sido colonizados ou não, assim como tenham sido alterados, todos eles serão buscados . Quando for definido como no, os submódulos nunca serão buscados.

Quando não especificado, utiliza o valor de fetch.recurseSubmodules se estiver definido (consulte git-config[1]), tendo como predefinição on-demand caso não esteja definido. Quando essa opção é usada sem nenhum valor, a predefinição é yes.
-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 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>: Acrescenta <caminho> aos caminhos impressos nas mensagens informativas, como "Fetching submodule foo". Essa opção é usada internamente quando se recorre a submódulos.
--recurse-submodules-default=[yes|on-demand]: Essa opção é usada internamente para fornecer temporariamente um valor predefinido não negativo para a opção --recurse-submodules. Todos os outros métodos de configuração da recursão do submódulo fetch (como as configurações do comando gitmodules[5] e git-config[1]) substituem essa opção, assim como especificar --[no-]recurse-submodules diretamente.
-u
--update-head-ok: É predefinido que o comando "git fetch" se recuse a atualizar o cabeçalho correspondente ao ramo atual. Esta opção desativa a verificação. Isso serve apenas para uso interno do comando "git pull" para se comunicar com o comando "git fetch" e, a menos que você esteja implementando a sua própria porcelana, você não deve usá-lo.
--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 num 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 usada 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 uma ramificação é atualizada à força durante o fetch. Isso pode ser desativado através do fetch.showForcedUpdates, mas 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>

O repositório "remote" é a fonte de uma operação fetch ou pull. Este parâmetro pode ser uma URL (consulte a seção GIT URLS abaixo) ou o nome de um controle remoto (consulte a seção RAMOS REMOTOS abaixo).

<grupo>

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

<refspec>

Especifica quais as refs que devem ser obtidas via fetch e quais as refs locais devem ser atualizadas. Quando não houver um <refspec> na linha de comando, as refs que serão obtidas com fetch serão lidas 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 sinal de adição opcional +, seguido pela origem <src>, seguido por dois-pontos :, seguido pela referência de destino <dst>. Os dois-pontos podem ser omitidos quando o valor de <dst> estiver vazio. O valor de <src> normalmente é uma referência, mas também pode ser um nome de um objeto hexadecimal inteiramente escrito.

Uma <refspec> pode conter um * na sua origem <src> para indicar uma simples combinação de padrões. Tal "refspec" funciona como um "glob" que combina com qualquer ref de mesmo prefixo. Um padrão <refspec> deve conter um * tanto origem <src> quanto no destino <dst>. Ele irá mapear os reffs para o destino substituindo o * pelo conteúdo correspondente da fonte.

Se um refspec for prefixado por ^, ele será interpretado como um refspec negativo. Em vez de especificar quais as refs devem ser obtidas com fetch ou quais as refs locais devem ser atualizadas, esta refspec especificará as refs que serão excluídas. Uma ref será considerada compatível se corresponder a pelo menos uma refspec positiva e não corresponder a nenhuma refspec negativa. As refspecs negativas podem ser úteis para restringir o escopo de um padrão refspec para que não inclua refs específicas. As refspecs negativas podem ser refspecs de padrão. No entanto, eles podem conter apenas um <src> e não especificar um <dst>. Também não há suporte para nomes de objetos hexadecimais totalmente mencionados.

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 ao contrário do que ocorre quando se faz um push com git-push[1], quaisquer atualizações para refs/tags/* seriam aceitas sem + no refspec (ou a opção --force). Ao fazer a obtenção com fetch, consideramos promiscuamente todas as atualizações das etiquetas de um ramo remoto como sendo um fetch forçado. Desde a versão 2.20 do Git, a busca para atualizar refs/tags/* funciona da mesma forma que o push. Ou seja, todas as atualizações serão rejeitadas sem + 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 ao utilizar 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 o ramo remoto que você deseja obter com fetch for conhecido por ser rebobinado ter feito um rebase regularmente, espera-se que o novo cume não seja descendente do cume anterior (conforme foi armazenado no último fetch que você fez no ramo rastreado remotamente). Você deve usar o sinal + para indicar que serão necessárias atualizações que não sejam de avanço rápido para estas ramificações. Não há nenhuma maneira de determinar ou declarar que um ramo será disponibilizado num repositório com este comportamento; o usuário que o extrai simplesmente deve saber que esse é o padrão de uso esperado para um ramo.

--stdin: Faz a leitura linha a linha dos refspecs a partir do stdin adicionalmente aqueles fornecidos pelos argumentos. O formato "tag <nome>" não é compatível.

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 captura (feching), porém é ineficiente e obsoleto; não os 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 = <url-da-outra-base>

Por exemplo, com isso:

	[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, com isso:

	[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 mencionar o nome de um ramo remoto que você configurou anteriormente usando o comando git-remote[1], git-config[1] ou até mesmo por uma edição manual no arquivo $GIT_DIR/config. A URL deste ramo remoto será usada para acessar o repositório. O "refspec" deste ramo remoto será usado por padrão quando você não fornecer um "refspec" na linha de comando. A entrada no arquivo de configuração teria a seguinte aparência:

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

O <pushurl> é usado somente para envios. É opcional e o padrão é <URL>. O envio para um controle remoto afeta todos os pushurls definidos ou todos as urls definidas se não houver pushurls definidos. No entanto, o Fetch só buscará a primeira url definida caso haja várias urls definidas.

Arquivo nomeado no `$GIT_DIR/remotes`

Você pode optar por fornecer o nome de um arquivo em $GIT_DIR/remotes. A URL nesse arquivo será usado para acessar o repositório. O "refspec" neste arquivo será usado como padrão quando você não fornecer um "refspec" na linha de comando. Este arquivo deve ter os seguintes formatos:

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

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

Arquivo informado em `$GIT_DIR/branches`

Você pode optar por fornecer o nome de um arquivo em $GIT_DIR/branches. A URL nesse arquivo será usado para acessar o repositório. Este arquivo deve ter os seguintes formatos:

	<URL>#<head>

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

Dependendo da operação, o git usará um dos seguintes "refspecs", caso você não forneça um na linha de comando. O <ramo> é o nome desse arquivo em $GIT_DIR/branches e <cabeçalho> tem como master como predefinição.

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 fazendo buscas regulares e repetidas nele. Para acompanhar o progresso deste repositório remoto, o comando git fetch permite que você configure as variáveis de 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 comando git fetch é executado sem especificar quais ramificações e/ou tags devem ser buscadas na linha de comando, por exemplo, o comando git fetch origin ou git fetch, os valores remote.<repositório>.fetch são usados como refspecs - eles especificam quais referências devem ser obtidas e quais referências locais devem ser atualizadas. O exemplo acima obterá todas as ramificações que existem em origin (ou seja, qualquer referência que corresponda ao lado esquerdo do valor, refs/heads/*) e atualizará as ramificações de rastreamento remoto correspondentes na hierarquia refs/remotes/origin/*.
Quando o comando git fetch é executado com ramificações e/ou tags explícitas que serão obtidas através da linha de comando, por exemplo, git fetch origin master, as <refspec>s informadas na linha de comando determinam o que deve ser obtido (por exemplo, master no exemplo, que é uma abreviação de master:, que por sua vez significa "buscar a ramificação master, mas não digo explicitamente qual ramificação de rastreamento remoto atualizar com ela a partir da linha de comando"), e o comando de exemplo buscará apenas a ramificação master. Os valores remote.<repositório>.fetch determinam qual ramo rastreado remotamente, se ele existir, ele será atualizado. Quando usados dessa maneira, os valores remote.<repositório>.fetch não têm nenhum efeito na decisão de o que é buscado (ou seja, os valores não são usados como refspecs quando a linha de comando listar refspecs); eles são usados apenas para decidir onde as refs que são buscadas são armazenadas, agindo 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 mais específicas. O recurso de poda não se preocupa de fato com as ramificações; em vez disso, ele poda as referências remotas ←→ locais como uma função no refspec remoto (consulte <refspec> e CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE 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>]

Ao usar --porcelain, o formato gerado serve para ser analisado por uma máquina. Em contraste com os formatos de saída legíveis para humanos, ele imprime na saída predefinida em na de erro padrão. Cada linha tem o formato:

<flag> <id-antiga-do-objeto> <id-nova-do-objeto> <referência-local>

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.

sinalizar, sinalização, indicação, marcação, marcador

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 num 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 remote.<repositório>.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
```
Isso atualiza (ou cria, conforme necessário) as ramificações seen e tmp no repositório local, buscando nas ramificações (respectivamente) seen e maint do 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 obtém 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 obtidos serão eventualmente removidos pela manutenção interna 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:

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.)
Como no item 1, o invasor escolhe a ID do objeto X para roubar. A vítima envia um objeto Y que o invasor já possui, e o invasor alega falsamente que possui X e não Y, então a vítima envia Y como um delta contra X. O delta revela ao invasor regiões de X que são semelhantes a Y.

CONFIGURAÇÃO

Warning

Missing pt_BR/includes/cmd-config-section-all.txt

See original version for this content.

Warning

Missing pt_BR/config/fetch.txt

See original version for this content.

BUGS

Com a opção --recurse-submodules só se pode buscar por novos commits nos submódulos que estejam presentes localmente, por exemplo, em $GIT_DIR/modules/. Se o upstream adicionar um novo submódulo, este submódulo não pode ser buscado até que seja clonado, por exemplo, através do git submodule update. Isso deve ser corrigido numa versão futura do Git.

VEJA TAMBÉM

git-pull[1]

Parte do conjunto git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands