git-fetch - Online na nuvem

PROGRAMA:

NOME

git-fetch - Baixar objetos e referências de outro repositório

SINOPSE

git buscar [ ] [ [ ...]]
git buscar [ ]
git buscar --múltiplo [ ] [( | ) ...]
git buscar --tudo [ ]

DESCRIÇÃO

Busque branches e / ou tags (coletivamente, "refs") de um ou mais outros repositórios,
junto com os objetos necessários para completar suas histórias. Filiais de rastreamento remoto são
atualizado (veja a descrição de abaixo para saber como controlar esse comportamento).

Por padrão, qualquer tag que aponte para os históricos sendo buscados também é buscada; a
efeito é buscar tags que apontam para ramos de seu interesse. Este padrão
o comportamento pode ser alterado usando as opções --tags ou --no-tags ou configurando
controlo remoto. .tagOpt. Usando um refspec que busca tags explicitamente, você pode buscar tags
que não apontam para ramos nos quais você também está interessado.

git buscar pode buscar de um único repositório nomeado ou URL, ou de vários
repositórios de uma vez se é dado e há um controle remoto. entrada no
arquivo de configuração. (Ver git-config(1)).

Quando nenhum controle remoto é especificado, por padrão o controle remoto de origem será usado, a menos que haja um
ramificação upstream configurada para a ramificação atual.

Os nomes dos refs que são buscados, junto com os nomes dos objetos para os quais eles apontam, são
escrito para .git / FETCH_HEAD. Essas informações podem ser usadas por scripts ou outros comandos git,
tais como git-pull(1).

OPÇÕES

--tudo
Obtenha todos os controles remotos.

-a, --append
Anexar nomes de ref e nomes de objeto de refs buscadas ao conteúdo existente de
.git / FETCH_HEAD. Sem esta opção, os dados antigos em .git / FETCH_HEAD serão sobrescritos.

--depth =
Limita a busca ao número especificado de commits da ponta de cada branch remoto
história. Se buscar para um raso repositório criado por git clone com --depth =
opção (ver clone do git(1)), aprofundar ou encurtar a história para o número especificado de
compromete. As tags para os commits aprofundados não são buscadas.

- pouco raso
Se o repositório de origem estiver completo, converta um repositório raso em um completo,
removendo todas as limitações impostas por repositórios superficiais.

Se o repositório de origem for raso, busque o máximo possível para que o atual
repositório tem o mesmo histórico que o repositório de origem.

--update-raso
Por padrão, ao buscar de um repositório raso, git fetch recusa refs que
requer atualização .git / raso. Esta opção atualiza .git / shallow e aceita tais referências.

--funcionamento a seco
Mostre o que seria feito, sem fazer nenhuma alteração.

-f, --força
Quando git buscar é usado com : refspec, ele se recusa a atualizar o
Filial local a menos que o ramo remoto ele busca é um descendente
do . Esta opção substitui essa verificação.

-k, --manter
Mantenha o pacote baixado.

--múltiplo
Permitir vários e argumentos a serem especificados. Não s pode ser
Especificadas.

-p, --prune
Depois de buscar, remova todas as referências de rastreamento remoto que não existam mais no
controlo remoto. As tags não estão sujeitas a remoção se forem buscadas apenas por causa do
tag padrão de seguimento automático ou devido a uma opção --tags. No entanto, se as tags forem buscadas devido
para um refspec explícito (na linha de comando ou na configuração remota, para
exemplo, se o controle remoto foi clonado com a opção --espelho), então eles também estão sujeitos
a poda.

-n, --sem tags
Por padrão, tags que apontam para objetos que são baixados do repositório remoto
são buscados e armazenados localmente. Esta opção desativa este seguimento automático de tag. o
o comportamento padrão de um controle remoto pode ser especificado com o controle remoto. Configuração .tagOpt.
See git-config(1).

--refmap =
Ao obter os refs listados na linha de comando, use o refspec especificado (pode ser fornecido
mais de uma vez) para mapear os refs para ramos de rastreamento remoto, em vez dos valores de
remote. *. fetch as variáveis ​​de configuração para o repositório remoto. Veja a seção sobre
"Ramificações de rastreamento remoto configuradas" para obter detalhes.

-t, --tags
Obter todas as tags do remoto (ou seja, buscar tags remotas refs / tags / * em tags locais
com o mesmo nome), além de tudo o mais que seria obtido. Usando
esta opção por si só não sujeita as tags a poda, mesmo se --prune for usado (embora
as tags podem ser removidas de qualquer maneira se também forem o destino de um refspec explícito; Vejo
--ameixa seca).

--recurse-submodules [= yes | on-demand | no]
Esta opção controla se e sob quais condições novos commits de submódulos preenchidos
deve ser buscado também. Pode ser usado como uma opção booleana para desabilitar completamente
recursão quando definido para não ou para recursar incondicionalmente em todos os submódulos povoados
quando definido para sim, que é o padrão quando esta opção é usada sem nenhum valor. Usar
sob demanda para apenas recursar em um submódulo preenchido quando o superprojeto recupera um
commit que atualiza a referência do submódulo para um commit que ainda não está no
clone de submódulo local.

--no-recurse-submódulos
Desative a busca recursiva de submódulos (isso tem o mesmo efeito que usar o
--recurse-submodules = no opção).

--submodule-prefix =
Prepend para caminhos impressos em mensagens informativas, como "Buscando submódulo
foo ". Esta opção é usada internamente ao recorrer a submódulos.

--recurse-submodules-default = [sim | sob demanda]
Esta opção é usada internamente para fornecer temporariamente um valor padrão não negativo para
a opção --recurse-submodules. Todos os outros métodos de configuração do submódulo de fetch
recursão (como configurações em módulos git(5) e git-config(1)) substituir esta opção,
assim como especificando - [no-] recurse-submodules diretamente.

-você, --update-head-ok
Por padrão git buscar se recusa a atualizar a cabeça que corresponde ao atual
filial. Este sinalizador desativa a verificação. Isso é puramente para uso interno para git puxar
para se comunicar com git buscar, e a menos que você esteja implementando sua própria porcelana, você
não deveriam usá-lo.

--upload-pack
Quando fornecido, e o repositório de onde buscar é gerenciado por git pacote de busca,
--exec = é passado ao comando para especificar o caminho não padrão para o
comando executado na outra extremidade.

-q, --quieto
Passe --quiet para git-fetch-pack e silencie quaisquer outros comandos git usados ​​internamente.
O progresso não é relatado ao fluxo de erro padrão.

-v, --verboso
Seja prolixo.

--progresso
O status do progresso é relatado no fluxo de erro padrão por padrão quando é
conectado a um terminal, a menos que -q seja especificado. Este sinalizador força o status de progresso mesmo
se o fluxo de erro padrão não for direcionado a um terminal.


O repositório "remoto" que é a origem de uma operação de busca ou extração. Esse
parâmetro pode ser um URL (consulte a seção GIT URLS abaixo) ou o nome de um remoto
(veja a seção REMOTOS abaixo).


Um nome que se refere a uma lista de repositórios como o valor de remotos. no
arquivo de configuração. (Ver git-config(1)).


Especifica quais referências buscar e quais referências locais atualizar. Quando não s
aparecem na linha de comando, os refs a serem buscados são lidos remotamente. .buscar
em vez disso (consulte FILIAIS DE RASTREAMENTO REMOTO CONFIGURADOS abaixo).

O formato de um parâmetro é um opcional mais +, seguido pela fonte ref
, seguido por dois pontos:, seguido pelo destino ref . O cólon pode ser
omitido quando está vazia.

marcação significa o mesmo que refs / tags / : refs / tags / ; requer busca
tudo até a tag fornecida.

O árbitro remoto que corresponde é buscado, e se não é uma string vazia, o
referência local que corresponde a ele é encaminhado rapidamente usando . Se o opcional mais + for
usado, a referência local é atualizada mesmo que não resulte em uma atualização de avanço rápido.

Note
Quando o branch remoto que você deseja buscar é conhecido por ser rebobinado e rebaseado
regularmente, espera-se que sua nova ponta não seja descendente de sua anterior
dica (conforme armazenado em seu branch de rastreamento remoto na última vez que você buscou). Vocês
gostaria de usar o sinal + para indicar que atualizações não aceleradas serão necessárias
para tais ramos. Não há como determinar ou declarar que uma filial será
disponibilizado em um repositório com este comportamento; o usuário que puxa simplesmente deve
saiba que este é o padrão de uso esperado para uma ramificação.

GIT URL

Em geral, os 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, alguns
desta informação pode estar ausente.

Git suporta os protocolos ssh, git, http e https (além disso, ftp e ftps podem ser usados
para buscar e rsync pode ser usado para buscar e enviar, mas estes são ineficientes e
descontinuada; não os use).

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

As seguintes sintaxes podem ser usadas com eles:

· Ssh: // [usuário @] host.xz [: porta] /path/to/repo.git/

· Git: //host.xz [: port] /path/to/repo.git/

· Http [s]: //host.xz [: porta] /path/to/repo.git/

· Ftp [s]: //host.xz [: porta] /path/to/repo.git/

· Rsync: //host.xz/path/to/repo.git/

Uma sintaxe semelhante a scp alternativa também pode ser usada com o protocolo ssh:

· [Usuário @] host.xz: caminho / para / repo.git /

Esta sintaxe só é reconhecida se não houver barras antes dos primeiros dois pontos. Isso ajuda
diferencie um caminho local que contém dois pontos. Por exemplo, o caminho local foo: bar poderia
ser especificado como um caminho absoluto ou ./foo:bar para evitar ser mal interpretado como um URL ssh.

Os protocolos ssh e git também suportam a expansão do nome de usuário:

· Ssh: // [usuário @] host.xz [: porta] / ~ [usuário] /path/to/repo.git/

· Git: //host.xz [: porta] / ~ [usuário] /path/to/repo.git/

· [Usuário @] host.xz: / ~ [usuário] /path/to/repo.git/

Para repositórios locais, também com suporte nativo do Git, as seguintes sintaxes podem ser
usava:

· /Path/to/repo.git/

· Arquivo: ///path/to/repo.git/

Essas duas sintaxes são quase sempre equivalentes, exceto durante a clonagem, quando a primeira implica
- opção local. Ver clone do git(1) para obter detalhes.

Quando o Git não sabe como lidar com um determinado protocolo de transporte, ele tenta usar o
controlo remoto- ajudante remoto, se houver. Para solicitar explicitamente um ajudante remoto,
a seguinte sintaxe pode ser usada:

· ::

Onde pode ser um caminho, um servidor e um caminho ou uma string arbitrária semelhante a um URL
reconhecido pelo helper remoto específico que está sendo chamado. Ver ajudantes gitremote(1) para
Detalhes.

Se houver um grande número de repositórios remotos com nomes semelhantes e você quiser usar um
formato diferente para eles (de modo que os URLs que você usa sejam reescritos em URLs que
trabalho), você pode criar uma seção de configuração do formulário:

[url " "]
em vez de =

Por exemplo, com este:

[url "git: //git.host.xz/"]
em vez de = host.xz: / caminho / para /
em vez de = trabalhar:

um URL como "trabalho: repo.git" ou "host.xz: /path/to/repo.git" será reescrito em qualquer
contexto que leva um URL a ser "git: //git.host.xz/repo.git".

Se você deseja reescrever URLs apenas para push, pode criar uma seção de configuração do
Formato:

[url " "]
pushInsteadOf =

Por exemplo, com este:

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

um URL como "git: //example.org/path/to/repo.git" será reescrito para
"ssh: //example.org/path/to/repo.git" para push, mas pulls ainda usarão o original
URL.

REMOTOS

O nome de um dos seguintes pode ser usado em vez de um URL como argumento:

· Um controle remoto no arquivo de configuração Git: $ GIT_DIR / config,

· Um arquivo no diretório $ GIT_DIR / remotes, ou

· Um arquivo no diretório $ GIT_DIR / branches.

Todos estes também permitem que você omita o refspec da linha de comando porque cada um
contém um refspec que o git usará por padrão.

Nomeado remoto in • Configuração lima
Você pode escolher fornecer o nome de um controle remoto que você configurou anteriormente usando
git-remote(1) git-config(1) ou mesmo por uma edição manual no arquivo $ GIT_DIR / config. O URL
deste remoto será usado para acessar o repositório. O refspec deste controle remoto será
usado por padrão quando você não fornece um refspec na linha de comando. A entrada no
o arquivo de configuração seria assim:

[controlo remoto " "]
url =
pushurl =
push =
buscar =

o é usado apenas para empurrar. É opcional e o padrão é .

Nomeado lima in $ GIT_DIR / remotes
Você pode escolher fornecer o nome de um arquivo em $ GIT_DIR / remotes. O URL neste arquivo
será usado para acessar o repositório. O refspec neste arquivo será usado como padrão
quando você não fornece um refspec na linha de comando. Este arquivo deve ter o seguinte
formato:

URL: um dos formatos de URL acima
Empurre:
Puxar:

Push: as linhas são usadas por git empurrar e Pull: as linhas são usadas por git puxar e git buscar.
Várias linhas Push: e Pull: podem ser especificadas para mapeamentos de ramificação adicionais.

Nomeado lima in $ GIT_DIR / branches
Você pode escolher fornecer o nome de um arquivo em $ GIT_DIR / branches. O URL neste arquivo
será usado para acessar o repositório. Este arquivo deve ter o seguinte formato:

#

É necessário; # é opcional.

Dependendo da operação, o git usará um dos seguintes refspecs, se você não
forneça um na linha de comando. é o nome deste arquivo em $ GIT_DIR / branches
e o padrão é master.

git fetch usa:

refs / heads / : refs / heads /

git push usa:

CABEÇA: refs / cabeças /

CONFIGURADO RASTREAMENTO REMOTO FILIAIS

Freqüentemente, você interage com o mesmo repositório remoto, buscando regularmente e repetidamente
a partir dele. Para acompanhar o progresso de tal repositório remoto, git fetch
permite que você configure remotamente. .fetch as variáveis ​​de configuração.

Normalmente, essa variável pode ter a seguinte aparência:

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

Essa configuração é usada de duas maneiras:

· Quando git fetch é executado sem especificar quais branches e / ou tags buscar no
linha de comando, por exemplo, git fetch origin ou git fetch, remote. .fetch values
são usados ​​como refspecs - eles especificam quais referências buscar e quais referências locais devem ser
atualizar. O exemplo acima irá buscar todos os ramos que existem na origem (ou seja, qualquer
ref que corresponde ao lado esquerdo do valor, refs / heads / *) e atualiza o
ramos de rastreamento remoto correspondentes na hierarquia refs / remotes / origin / *.

· Quando git fetch é executado com branches explícitos e / ou tags para buscar na linha de comando,
por exemplo, git fetch origin master, o s fornecidos na linha de comando determinam o que
devem ser buscados (por exemplo, mestre no exemplo, que é uma abreviação de mestre :,
que por sua vez significa "buscar o dominar ramo, mas eu não digo explicitamente o que
branch de rastreamento remoto para atualizar com ele a partir da linha de comando "), e o exemplo
o comando irá buscar só da dominar filial. O remoto. .fetch values
determinar qual ramificação de rastreamento remoto, se houver, será atualizada. Quando usado desta forma, o
controlo remoto. Os valores .fetch não têm nenhum efeito na decisão o que é buscado
(isto é, os valores não são usados ​​como refspecs quando a linha de comando lista refspecs); elas
são usados ​​apenas para decidir onde as referências que são buscadas são armazenadas agindo como um
mapeamento.

O último uso do controle remoto. Os valores .fetch podem ser substituídos dando o
--refmap = parâmetro (s) na linha de comando.

EXEMPLOS

· Atualizar as filiais de rastreamento remoto:

$ git busca origem

O comando acima copia todos os branches do refs / heads / namespace remoto e armazena
-los para o local refs / remotes / origin / namespace, a menos que o branch. .buscar
opção é usada para especificar um refspec não padrão.

· Usando refspecs explicitamente:

$ git fetch origin + pu: pu maint: tmp

Isso atualiza (ou cria, conforme necessário) branches pu e tmp no repositório local por
obtendo dos ramos (respectivamente) pu e maint do repositório remoto.

O ramal pu será atualizado mesmo se não for de avanço rápido, porque é
prefixado com um sinal de mais; tmp não será.

· Peek em um branch remoto, sem configurar o remoto em seu repositório local:

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

O primeiro comando busca o branch maint do repositório em
git: //git.kernel.org/pub/scm/git/git.git e o segundo comando usa FETCH_HEAD para
examine o galho com git-log(1). Os objetos buscados serão eventualmente removidos por
manutenção interna do git (veja git-gc(1)).

Use git-fetch online usando serviços onworks.net