Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.33.1 → 2.34.1 no changes
- 2.33.0 08/16/21
- 2.32.0 06/06/21
- 2.31.1 no changes
- 2.31.0 03/15/21
- 2.29.1 → 2.30.2 no changes
- 2.29.0 10/19/20
- 2.28.1 no changes
- 2.28.0 07/27/20
- 2.27.1 no changes
- 2.27.0 06/01/20
- 2.25.2 → 2.26.3 no changes
- 2.25.1 02/17/20
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 no changes
- 2.24.0 11/04/19
- 2.23.1 → 2.23.4 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.20.1 → 2.20.5 no changes
- 2.20.0 12/09/18
- 2.19.1 → 2.19.6 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.17.1 → 2.17.6 no changes
- 2.17.0 04/02/18
- 2.15.4 → 2.16.6 no changes
- 2.14.6 12/06/19
- 2.12.5 → 2.13.7 no changes
- 2.11.4 09/22/17
- 2.10.5 09/22/17
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
- 2.2.3 → 2.3.10 no changes
- 2.1.4 12/17/14
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çãofetch.parallel
esubmodule.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
eadd
será adicionada ao "upstream", utilizado pelo argumentoless
git-pull[1] e outros comandos. Para mais informações, consultebranch.<nome>.merge
ebranch.<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ódulofetch
(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 ogit-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
ouLF
. 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 definafetch.showForcedUpdates
como tofalse
para ignorar esta verificação por questões de desempenho. Se utilizada durante ogit-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áveisremote.<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 querefs/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çãorefs/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 ganchopre-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 nomesrefs/heads/*
aceite um objeto que não seja um commit.NoteQuando 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 valoresgit fetch origin
ougit fetch
,remote.<repositório>.fetch
são utilizados comorefspecs
eles especificam quais osrefs
capturar e quais asrefs
locais atualizar. O exemplo acima capturará todas as ramificações que existem emorigin
(ou seja, qualquerref
que coincida ao lado esquerdo do valor,refs/heads/*
) e atualizará as ramificações de rastreamento remoto correspondentes na hierarquiarefs/remotes/origem/*
. -
Quando o
git fetch
é executado especificamente com as ramificações ou tags utilizando a linha de comando comogit fetch origin master
por exemplo, os<refspec>
utilizados determinam uma ordem de capturar, o quê deve ser capturado (omaster
no exemplo é uma abreviação demaster:
, que por sua vez significa "capture a ramificação master, por exemplo), assim o comando no exemplo capturará apenas a ramificação master. Os valoresremote.<repositório>.fetch
determinam qual a ramificação remota rastreada, caso exista, será atualizada. Quando utilizados desta maneira, os valoresremote.<repository>.fetch
não têm nenhum efeito na decisão do quê é capturado (ou seja, os valores não são utilizados comorefspecs
quando a linha de comando listarefspecs
); eles são utilizados apenas para decidir onde osrefs
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 emrefs/remotes/origin/
com um espaço de nomes local, a menos que a opçãobranch.<nome>.fetch
seja utilizada para definir umrefspec
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á otmp
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 emgit://git.kernel.org/pub/scm/git/git.git
e o segundo comando usaFETCH_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:
-
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 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.
GIT
Parte do conjunto git[1]