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

NOME

git-pull - Busque e integre-se a outro repositório ou em um ramo local

RESUMO

git pull [<opções>] [<repositório> [<refspec>…​]]

DESCRIÇÃO

Incorpora as alterações de um repositório remoto no ramo atual. Em seu modo predefinido, o comando git pull é uma abreviação do comando git fetch seguido por git merge FETCH_HEAD.

Mais precisamente, o comando git pull executa o git fetch com os parâmetros informados e chama o git merge para mesclar os cabeçalhos recuperados da ramificação no ramo atual. Com --rebase, ele executa o comando git rebase em vez do git merge.

O <repositório> deve ser o nome de um repositório remoto, conforme passado para o git-fetch[1]. O <refspec> pode nomear de forma arbitrária uma referência remota (por exemplo, o nome de uma tag) ou até mesmo uma coleção de referências com as ramificações dos ramos monitorados remotamente (refs/heads/{asterisk}:refs/remotes/origin/{asterisk} por exemplo), porém geralmente é o nome de uma ramificação no repositório remoto.

Os valores predefinidos para o <repositório> e o <ramo> eles são lidos na configuração "remote" e "merge" do ramo atual, conforme for definido pelo git-branch[1] --track.

Suponha que exista o seguinte histórico e o ramo atual seja master:

	  A---B---C master on origin
	 /
    D---E---F---G master
	^
	origin/master no seu repositório

Então, o comando "git pull" fara a captura e a reprodução das alterações do ramo remoto master por ter se divergido do master local (ou seja, E) até o seu commit atual (C) no topo do master e registra o resultado em um novo commit, juntamente com os nomes dos dois commits principais e uma mensagem do registro log do usuário, descrevendo quais forma as alterações que foram feitas.

	  A---B---C origin/master
	 /         \
    D---E---F---G---H master

Para mais detalhes incluindo informações de como os conflitos são gerenciados e como eles são exibidos, consulte git-merge[1].

No Git 1.7.0 ou posterior, para cancelar uma mesclagem conflitante, utilize o comando git reset --merge. Aviso: Nas versões mais antigas do Git, a execução do git pull com as alterações dos commits não realizados é desencorajado: enquanto for possível, deixa você em uma condição onde a recuperação pode ser difícil no caso de um conflito.

Caso alguma das alterações remotas se sobrepuser às alterações dos commits locais que não foram realizados, a mesclagem será automaticamente cancelada e a árvore de trabalho se manterá intocada. Geralmente é melhor obter as alterações locais na ordem de trabalho antes de retirá-las ou escondê-las com o git-stash[1].

OPÇÕES

-q
--quiet

Isso é passado para ambos os comandos subjacentes do git-fetch para abafar o relatório do processo durante a transferência assim como do git-merge silenciando sua saída durante a mesclagem.

-v
--verbose

Encaminhe a opção --verbose para o git-fetch e git-merge.

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

Esta opção controla se os novos commits dos submódulos populados devem ser buscados ou não e se as árvore de trabalho dos submódulos ativos devem ser atualizados também (consulte git-fetch[1], git-config[1] e gitmodules[5]).

Caso a averiguação seja feita através da reconstrução "rebase", os commits do submódulo local também serão refeitas.

Caso a atualização seja feita através de uma mesclagem, os conflitos do sub-módulo serão resolvidos e retirados.

Opções relacionadas a mesclagem

--commit
--no-commit

Execute a mesclagem e faça o commit com o resultado. Esta opção pode ser usada para substituir a opção --no-commit.

Com a opção --no-commit, executa a mesclagem e para imediatamente antes de criar a mesclagem de um commit, para dar ao usuário a chance de inspecionar e ajustar ainda mais o resultado da mesclagem antes de fazer o commit.

Observe que as atualizações com avanço rápido não criam a mesclagem de um commit e portanto, não há como interromper essas mesclagens com a opção --no-commit. Portanto, caso queira garantir que o seu ramo não seja alterado ou atualizado pelo comando mesclar, utilize --no-ff with --no-commit.

--edit
-e
--no-edit

Chame um editor antes de fazer a mesclagem mecânica de um commit bem sucedido para editar ainda mais a mensagem da mesclagem que foi gerada automaticamente, para que o usuário possa explicar e justificar a mesclagem. A opção --no-edit pode ser utilizada para aceitar a mensagem que foi gerada automaticamente (em geral isso é desencorajado).

Os scripts mais antigos podem depender do comportamento histórico de não permitir que o usuário edite a mensagem do registro log da mesclagem. Eles verão um editor aberto quando executar o git merge. Para facilitar o ajuste destes scripts para o comportamento que foi atualizado, a variável de ambiente GIT_MERGE_AUTOEDIT pode ser definido como no no início deles.

--cleanup=<modo>

Esta opção determina como a mensagem de mesclagem será limpa antes da confirmação. Para mais detalhes consulte git-commit[1]. Além disso, caso o <mode> seja dado o valor de scissors, scissors (tesouras) será anexada a MERGE_MSG antes de ser repassada para o mecanismo de commit caso exista mesclagens conflitantes.

--ff
--no-ff
--ff-only

Especifica como uma mesclagem é manipulada quando o histórico mesclado já é um descendente do histórico atual. A predefinição é a opção --ff , a menos que durante a mesclagem de uma tag anotada (e possivelmente assinada) que não seja armazenada em seu local natural na hierarquia refs/tags/, no caso onde a opção --ff não será assumida.

Com --ff, quando for possível, resolva a mesclagem como um avanço rápido (atualize apenas o ponteiro do ramo para coincidir com a ramificação que foi mesclada; não crie um commit da mesclagem). Quando não for possível (quando o histórico mesclado não for um descendente do histórico atual), crie um commit da mesclagem.

Com --no-ff, crie um commit da mesclagem em todos os casos, mesmo quando a mesclagem puder ser resolvida como um avanço rápido.

Com a opção --ff-only, quando for possível, resolva a mesclagem com avanço rápido. Quando não for possível, recuse a mesclagem e encerre com uma condição diferente de zero.

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

Assine a mesclagem resultante do commit com o GPG. O argumento keyid é opcional e a predefinição retorna para a identidade de quem fez o commit; se utilizado, deve estar anexado a opção sem espaço. A opção --no-gpg-sign é útil para revogar a variável de configuração commit.gpgSign e a anterior --gpg-sign.

--log[=<n>]
--no-log

Além dos nomes dos ramos, preencha a mensagem do registro log com descrições de uma linha com no máximo <n> commits atuais que estão sendo mesclados. Consulte também git-fmt-merge-msg[1].

Com --no-log, não liste as descrições de uma linha vindas do commits que estão atualmente sendo mescladas.

--signoff
--no-signoff

Adicionar uma linha assinado pela pessoa que fez o commit no final do registro log do commit assinado. O significado de uma aprovação depende do projeto, porém normalmente certifica que a pessoa que fez o commit tem o direito de enviar este trabalho sob a mesma licença e concorda com um Certificado de Origem do Desenvolvedor (consulte http://developercertificate.org/ para obter mais informações).

A opção --no-signoff não adiciona a linha de assinatura "Signed-off-by".

--stat
-n
--no-stat

Exiba um "diffstat" no final da mesclagem. O diffstat também é controlado pela opção da configuração merge.stat.

Com -n ou --no-stat, não mostre o diffstat no final da mesclagem.

--squash
--no-squash

Produza a árvore de trabalho e a condição do índice como se uma mesclagem real tivesse acontecido (exceto as informações da mesclagem), porém não efetue um commit, mova o HEAD ou registre o $GIT_DIR/MERGE_HEAD (para causar o próximo comando git commit para criar uma mesclagem). Isso permite que você crie um único commit sobre o ramo atual, cujo efeito é o mesmo que mesclar um outro ramo (ou mais no caso da mesclagem "octopus").

Com a opção --no-squash, execute a mesclagem e faça o commit com o resultado. Esta opção pode ser usada para substituir a opção --squash.

Com a opção --squash, a opção --commit não é permitida e irá falhar.

--no-verify

Esta opção ignora os ganchos dos commits anteriores e os ganchos das mensagens do commit. Consulte também githooks[5].

-s <estratégia>
--strategy=<estratégia>

Use a estratégia de mesclagem informada; podem ser utilizado mais de uma vez para defini-los na ordem em que devem ser tentados. Caso não haja a opção -s, em vez disso será usada uma lista de estratégias incorporada (git merge-recursive ao mesclar um único cabeçalho, caso contrário git merge octopus).

-X <opção>
--strategy-option=<opção>

Passe a opção específica da estratégia através da estratégia de mesclagem.

--verify-signatures
--no-verify-signatures

Verifique se o topo do commit do lado do ramo mesclado está assinado com uma chave válida, ou seja, uma chave que possua um uid válida: no modelo de confiança predefinido, isso significa que a chave da assinatura foi assinada através de uma chave confiável. Caso o topo do commit do lado do ramo não seja assinada com uma chave válida, a mesclagem será cancelada.

--summary
--no-summary

É um sinônimos para --stat e --no-stat; estas opções foram descontinuadas e serão removidas no futuro.

--autostash
--no-autostash

Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run the operation on a dirty worktree. No entanto, utilize com cuidado: conflitos não triviais podem acontecer caso a aplicação final do "stash" ocorra após uma mesclagem bem-sucedida.

--allow-unrelated-histories

É predefinido que o comando git merge se recuse a mesclar os históricos que não compartilham de um ancestral comum. Esta opção pode ser utilizada para substituir esta segurança durante a mesclagem dos históricos dos dois projetos que iniciaram as suas vidas de forma independente. Como esta é uma ocasião muito rara, não existe variável de configuração para ativar isso de forma predefinida e não será adicionada.

-r
--rebase[=false|true|merges|preserve|interactive]

Quando for verdadeiro, reorganize a fundação do ramo atual no topo da ramificação upstream após a busca. Caso haja uma ramificação monitorado remotamente correspondente à ramificação upstream e a ramificação upstream foi reconstruído desde a última busca, a reconstrução da fundação utilizará estas informações para evitar reconstruir as alterações que não fora locais.

Quando definido como merges, a reconstrução da fundação (rebase) utilizando o comando git rebase --rebase-merges para que as mesclagem dos commits locais sejam incluídas na reconstrução (para mais detalhes, consulte git-rebase[1]).

Quando definido como preserve (já descontinuado em favor de merges), reconstrua passando a opção --preserve-merges para o comando git rebase para que a mesclagem dos commits criados localmente não sejam achatadas.

Quando for falso, mescle a ramificação atual na ramificação upstream.

Quando interactive (interativo) , ative o modo interativo da reconstrução da fundação.

Consulte pull.rebase, branch.<nome>.rebase e branch.autoSetupRebase no git-config[1] caso queira fazer o git pull, sempre utilize o comando --rebase em vez de mesclar .

Note
Esse é um modo de operação potencialmente perigoso. Ele reescreve o histórico, o que não é um bom presságio quando você já o publicou. Não utilize esta opção, a menos que você leia o git-rebase[1] com muita atenção.
--no-rebase

Ignora o --rebase anterior.

Opções relacionadas à busca

--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> da documentação do git-fetch[1]. Esta opção sobrescreve esta verificação.

-k
--keep

Mantenha o pacote que foi baixado.

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

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

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

--set-upstream

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

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

--progress

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

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

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

--show-forced-updates

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

--no-show-forced-updates

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

-4
--ipv4

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

-6
--ipv6

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

<repositório>

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

<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 a seção "CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE" in git-fetch[1]).

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

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

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

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

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

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

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

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

Note
Quando se sabe que o ramo remoto que você quer buscar é retrocedida e reconstruída regularmente, espera-se que o novo topo não seja descendente do topo anterior (conforme foi armazenada no ramo monitorado remotamente da última vez que você fez a busca). Você vai querer usar o sinal + para indicar que serão necessárias atualizações não rápidas para estas ramificações. Não há como determinar ou declarar que uma ramificação será disponibilizada em um repositório com este comportamento; o usuário que está capturando simplesmente deve saber que esse é o padrão de uso esperado para um ramo.
Note
Há uma diferença entre listar múltiplos <refspec> diretamente na linha de comando com git pull e ter várias entradas remote.<repositório>.fetch na sua configuração para um <repositório> e executar um comando com git pull sem qualquer parâmetros explícitos <refspec>. Os <refspec>s listados explicitamente na linha de comando são sempre mesclado no ramo atual após a busca. Em outras palavras, caso você liste mais de uma "ref" remota, o comando git pull criará uma mesclagem "Octopus" (Polvo). Por outro lado, caso você não liste nenhum parâmetro <refspec> de forma explícita na linha de comando, o comando git pull buscará tudo o que encontrar na configuração remote.<repositório>.fetch e mesclará apenas o primeiro que for encontrado no ramo atual. Isso ocorre porque raramente é feito a criação de um "polvo" a partir das refs remotas, enquanto monitora os vários cabeçalhos remotos de uma só, isso geralmente é bastante útil.

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>

ESTRATÉGIAS DE MESCLAGEM

O mecanismo da mesclagem (comandos git merge e git pull) permite que as estruturas das estratégias de mesclagem sejam escolhidas com a opção -s. Algumas estratégias também podem ter suas próprias opções, que podem ser passadas usando -X<opção> como argumentos para o comando git merge e/ou git pull.

resolve

Isso só pode resultar em dois cabeçalhos (ou seja, a ramificação atual e uma outra ramificada da que você obteve) utilizando um algoritmo de mesclagem de três vias. Ele tenta detectar cuidadosamente as ambiguidades cruzadas da mesclagem e geralmente é considerado seguro e rápido.

recursive

Isso pode resolver apenas duas cabeças usando o algoritmo da mesclagem de 3 vias. Quando há mais de um ancestral comum que pode ser usado para a mesclagem de 3 vias, ele cria uma árvore mesclada dos ancestrais comuns e o usa como a árvore de referência para a mesclagem de 3 vias. Foi informado que isso resulta em menos conflitos durante mesclagem sem causar distorções pelos testes feitos nas mesclagens reais dos commits, retiradas do histórico de desenvolvimento do Linux kernel 2.6. Além disso, isso pode detectar e manipular as mesclagens envolvendo renomeações, porém atualmente não pode fazer uso das cópias detectadas. Essa é a estratégia de mesclagem predefinida ao extrair ou mesclar um ramo.

A estratégia recursiva pode ter as seguintes opções:

ours

Esta opção impõem que os pedaços conflitantes que sejam resolvidos de forma automática e de maneira limpa, favorecendo a nossa versão. As alterações vindos de outra árvore que não conflitam com o nosso lado são refletidas no resultado da mesclagem. Para um arquivo binário, todo o conteúdo é retirado do nosso lado.

Isso não deve ser confundido com a estratégia da nossa de mesclagem, que sequer olha para o que a outra árvore contém. Descarta tudo o que a outra árvore fez, declarando que o nosso histórico contém tudo o que aconteceu nela.

theirs

Este é o oposto do nosso; observe que, diferentemente do nosso, não existe uma estratégia de mesclagem deles para confundir esta opção de mesclagem.

patience

Com esta opção, merge-recursive gasta um pouco de tempo extra para evitar as distorções que às vezes ocorrem devido as coincidência das linhas sem importância (como, por exemplo, chaves das funções distintas). Use isso quando os ramos que serão mesclados divergirem bastante. Consulte também git-diff[1] --patience.

diff-algorithm=[patience|minimal|histogram|myers]

Informa ao merge-recursive para usar um algoritmo diff diferente, que pode ajudar a evitar as distorções que ocorrem devido as linhas coincidentes sem importância (como chaves das funções distintas). Consulte também git-diff[1] --diff-algorithm.

ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol

Trata as linhas com o tipo indicado da mudança do espaço como inalterado por uma mesclagem de três vias. As alterações de espaço combinadas com outras alterações em uma linha não são ignoradas. Consulte também git-diff[1] -b, -w, --ignore-space-at-eol, e --ignore-cr-at-eol.

  • Caso a versão their (dele) introduzir apenas as alterações de espaço em uma linha, a our (nossa) versão será utilizada;

  • Caso a our (nossa) versão introduzir alterações nos espaços, porém a versão their (dele) incluir uma alteração substancial, a versão their (dele) será utilizada;

  • Caso contrário, a mesclagem continuará de forma usual.

renormalize

Executa uma averiguação e um check-in virtual de três estágios em um arquivo ao resolver uma mesclagem de três vias. Esta opção deve ser utilizada ao mesclar os ramos com diferentes filtros que estejam limpos ou as regras normais para a quebra de linha. Para obter mais detalhes, consulte "Mesclando ramificações com diferentes atributos de check-in/check-out" em gitattributes[5].

no-renormalize

Desativa a opção renormalize. Substitui a variável de configuração merge.renormalize.

no-renames

Desativa a detecção de renomeação. Isso substitui a variável de configuração merge.renames. Consulte tambémgit-diff[1] --no-renames.

find-renames[=<n>]

Liga a detecção de renomeação, configurando opcionalmente o limite de similaridade. Esta é a predefinição. Isso substitui a configuração da variável merge.renames. Consulte também git-diff[1] --find-renames.

rename-threshold=<n>

É um sinônimo obsoleto para find-renames=<n>.

subtree[=<caminho>]

Essa opção é uma forma mais avançada da estratégia da subárvore, onde a estratégia adivinha como as duas árvores devem ser deslocadas para coincidirem uma com a outra durante a mesclagem. Em vez disso, o caminho definido é prefixado (ou removido desde o início) para criar a forma das duas árvores que serão coincididas.

octopus

Isso resolve os casos com mais de dois cabeçalhos, porém se recusa a fazer uma mesclagem complexa que precise de uma resolução manual. Destina-se primeiramente para ser usado para agrupar junto o tópico dos cabeçalhos. Esra é a estratégia de mesclagem predefinida durante a extração ou a mesclagem com mais de um ramo.

ours

Isso resolve qualquer quantidade dos cabeçalhos, porém a árvore resultante da mesclagem é sempre a do cabeçalho atual do ramo, ignorando efetivamente todas as alterações de todas os outros ramos. Ele deve ser usado para substituir o histórico antigo de desenvolvimento das ramificações laterais. Observe que isso é diferente da opção -Xours da estratégia de mesclagem recursiva.

subtree

Esta é uma estratégia recursiva modificada. Ao mesclar as árvores A e B, caso B corresponda a uma subárvore de A, o B será ajustado primeiro para coincidir à estrutura da árvore A, em vez de ler as árvores no mesmo nível. Esse ajuste também é feito na árvore ancestral comum.

Com as estratégias que usma a mesclagem de 3 vias (incluindo a predefinição, recursive), caso uma alteração seja feita em ambas as ramificações, porém depois revertida em uma das ramificações, essa alteração estará presente no resultado mesclado; algumas pessoas acham este comportamento confuso. Isso ocorre porque apenas os cabeçalhos e a base da mesclagem são consideradas ao fazer uma mesclagem, e não os commits individuais. Portanto, o algoritmo da mesclagem considera a alteração revertida como nenhuma alteração e substitui a versão alterada.

COMPORTAMENTO PREDEFINIDO

Frequentemente, as pessoas utilizam o git pull sem informar qualquer parâmetro. Tradicionalmente, é o mesmo que dizer git pull origin. No entanto, quando a configuração branch.<nome>.remote está presente enquanto no ramo <nome>, esse valor é utilizado em vez de origin.

Para determinar de qual URL usar, o valor da configuração remote.<origin>.url é consultado e caso não haja nenhuma variável, o valor na linha URL: em $GIT_DIR/remotes/<origin> é utilizado.

Para determinar quais ramificações remotas buscar (e opcionalmente armazenar nas ramificações monitoradas remotamente) quando o comando é executado sem nenhum parâmetro "refspec" na linha de comando, os valores da variável de configuração remote.<origin>.fetch são consultados e caso não exista nenhum, então $GIT_DIR/remotes/<origin> é consultado e as suas linhas Pull: são utilizadas. Além dos formatos "refspec" descritos na seção OPÇÕES, você pode ter um englobamento do "refspec" parecido com este:

refs/heads/*:refs/remotes/origin/*

Um englobamento do "refspec" deve ter um RHS que não não seja vazio (ou seja, deve armazenar o que foi buscado nas ramificações monitoradas remotamente) e o seu LHS e RHS devem terminar com /*. A definição acima determina que todas as ramificações remotas sejam monitoradas utilizando os ramos monitorados remotamente em refs/remotes/origin/ com o mesmo nome.

A regra para determinar qual a ramificação remota deve ser mesclada após a captura é um pouco complexo, para que não prejudique a compatibilidade com as versões anteriores.

Caso "refspecs" explícitos sejam informados para o comando git pull, todos eles são mesclados.

Quando nenhum "refspec" for informado na linha de comando, o git pull utiliza o "refspec" da configuração ou $GIT_DIR/remotes/<origin>. Nestes casos, as seguintes regras se aplicam:

  1. Caso a configuração branch.<nome>.merge para o ramo atual <nome> exista, este é o nome do ramo no site remoto que é mesclado.

  2. Caso o refspec seja um caractere curinga, nada será mesclado.

  3. Caso contrário, a ramificação remota do primeiro refspec será mesclada.

EXEMPLOS

  • Atualize as ramificações monitoradas remotamente para o repositório onde a clonagem foi feita e em seguida, mescle uma delas na sua ramificação atual:

    $ git pull
    $ git pull origin

    Normalmente o ramo mesclado fica no HEAD do repositório remoto, porém a escolha é determinada pelas opções branch.<nome>.remote e branch.<nome>.merge; para mais detalhes consulte git-config[1].

  • Mescle na ramificação atual o ramo remoto next:

    $ git pull origin next

    Isto deixa uma cópia do next temporariamente no FETCH_HEAD, porém não atualiza nenhum outro ramo origin/next monitorado remotamente. O mesmo pode ser feito ao executar o fetch e o merge:

    $ git fetch origin
    $ git merge origin/next

Caso você tente fazer um "pull" que resultou em conflitos complexos e queira recomeçar, a recuperação pode ser feita com o comando git reset.

SEGURANÇA

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

Os vetores de ataque informados são os seguintes:

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

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

BUGS

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

GIT

Parte do conjunto git[1]