Git

git-fetch last updated in 2.45.0

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

Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.

git fetch can fetch from either a single named repository or URL, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See 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.

The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by scripts or other git commands, such as git-pull[1].

OPÇÕES

--[no-]all: Fetch all remotes. This overrides the configuration variable fetch.all.
-a
--append: Append ref names and object names of fetched refs to the existing contents of .git/FETCH_HEAD. Without this option old data in .git/FETCH_HEAD will be overwritten.
--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>: Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. This option can be specified multiple times.
--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>: By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips. This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched.
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.
This is incompatible with --recurse-submodules=[yes|on-demand]. Internally this is used to implement the push.negotiate option, see 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: Write the list of remote refs fetched in the FETCH_HEAD file directly under $GIT_DIR. This is the default. Passing --no-write-fetch-head from the command line tells Git not to write the file. Under --dry-run option, the file is never written.
-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: Run git maintenance run --auto at the end to perform automatic repository maintenance if needed. (--[no-]auto-gc is a synonym.) This is enabled by default.
--[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: Before fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option. However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning. Supplying --prune-tags is a shorthand for providing the 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: By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default behavior for a remote may be specified with the remote.<name>.tagOpt setting. See 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>: When fetching refs listed on the command line, use the specified refspec (can be given more than once) to map the refs to remote-tracking branches, instead of the values of remote.*.fetch configuration variables for the remote repository. Providing an empty <refspec> to the --refmap option causes Git to ignore the configured refspecs and rely entirely on the refspecs supplied as command-line arguments. See section on "Configured Remote-tracking Branches" for details.
-t
--tags: Fetch all tags from the remote (i.e., fetch remote tags refs/tags/* into local tags with the same name), in addition to whatever else would otherwise be fetched. Using this option alone does not subject tags to pruning, even if --prune is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see --prune).
--recurse-submodules[=yes|on-demand|no]: This option controls if and under what conditions new commits of submodules should be fetched too. When recursing through submodules, git fetch always attempts to fetch "changed" submodules, that is, a submodule that has commits that are referenced by a newly fetched superproject commit but are missing in the local submodule clone. A changed submodule can be fetched as long as it is present locally e.g. in $GIT_DIR/modules/ (see gitsubmodules[7]); if the upstream adds a new submodule, that submodule cannot be fetched until it is cloned e.g. by 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.
When unspecified, this uses the value of fetch.recurseSubmodules if it is set (see git-config[1]), defaulting to on-demand if unset. When this option is used without any value, it defaults to 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>: Prepend <path> to paths printed in informative messages such as "Fetching submodule foo". This option is used internally when recursing over submodules.
--recurse-submodules-default=[yes|on-demand]: This option is used internally to temporarily provide a non-negative default value for the --recurse-submodules option. All other methods of configuring fetch’s submodule recursion (such as settings in gitmodules[5] and git-config[1]) override this option, as does specifying --[no-]recurse-submodules directly.
-u
--update-head-ok: By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it.
--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: By default, git checks if a branch is force-updated during fetch. This can be disabled through fetch.showForcedUpdates, but the --show-forced-updates option guarantees this check occurs. See 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.

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.

Caso uma refspec seja prefixada através do ^, ela será interpretada como uma refspec negativa. Em vez de especificar quais as refs devem ser buscadas ou quais as refs locais devem ser atualizadas, tal refspec irá especificar as refs que serão excluídas. Uma ref será considerada compatível caso coincida com pelo menos uma ref positiva e não corresponda com nenhum ref negativo. Os refspecs negativos podem ser úteis para restringir o escopo padrão de um refspec para que ele não inclua determinados refspecs. Os refspecs negativos podem ser padrões refspecs de si mesmo. Entretanto, eles podem conter apenas uma fonte <src> e não especificam um destino <dst>. Os nomes dos objetos em hexadecimais também não são suportados.

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 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 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.

--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 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> é 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 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

You often interact with the same remote repository by regularly and repeatedly fetching from it. In order to keep track of the progress of such a remote repository, git fetch allows you to configure remote.<repository>.fetch configuration variables.

Normalmente, essa variável pode ser assim:

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

Essa configuração é utilizada de duas maneiras:

When git fetch is run without specifying what branches and/or tags to fetch on the command line, e.g. git fetch origin or git fetch, remote.<repository>.fetch values are used as the refspecs—they specify which refs to fetch and which local refs to update. The example above will fetch all branches that exist in the origin (i.e. any ref that matches the left-hand side of the value, refs/heads/*) and update the corresponding remote-tracking branches in the refs/remotes/origin/* hierarchy.
When git fetch is run with explicit branches and/or tags to fetch on the command line, e.g. git fetch origin master, the <refspec>s given on the command line determine what are to be fetched (e.g. master in the example, which is a short-hand for master:, which in turn means "fetch the master branch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch only the master branch. The remote.<repository>.fetch values determine which remote-tracking branch, if any, is updated. When used in this way, the remote.<repository>.fetch values do not have any effect in deciding what gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide where the refs that are fetched are stored by acting as a mapping.

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
```
This updates (or creates, as necessary) branches seen and tmp in the local repository by fetching from the branches (respectively) seen and maint from the remote repository.
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
```
The first command fetches the maint branch from the repository at git://git.kernel.org/pub/scm/git/git.git and the second command uses FETCH_HEAD to examine the branch with git-log[1]. The fetched objects will eventually be removed by git’s built-in housekeeping (see 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.)
As in #1, the attacker chooses an object ID X to steal. The victim sends an object Y that the attacker already has, and the attacker falsely claims to have X and not Y, so the victim sends Y as a delta against X. The delta reveals regions of X that are similar to Y to the attacker.

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