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

NOME

git-clone - Clona um repositório em um novo diretório

RESUMO

git clone [--template=<diretório-modelo>]
	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
	  [-o <nome>] [-b <nome>] [-u <upload-pack>] [--reference <repositório>]
	  [--dissociate] [--separate-git-dir <dir git>]
	  [--depth <profundidade>] [--[no-]single-branch] [--no-tags]
	  [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
	  [--[no-]remote-submodules] [--jobs <n>] [--sparse]
	  [--filter=<filter>] [--] <repositório>
	  [<diretório>]

DESCRIÇÃO

Clona um repositório em um diretório recém-criado, cria o monitoramento remoto dos ramos para cada ramo no repositório clonado (visível utilizando git branch --remotes), cria e verifica um ramo inicial que é bifurcado do ramo ativo atualmente do repositório clonado .

Após a clonagem, um simples git fetch sem argumentos atualizará todas os ramos remotos e um git pull sem argumentos irá além disso, fará a mesclagem do ramo master (mestre) remoto no ramo atual caso haja (isso não se torna verdadeiro quando "--single-branch" é utilizado; veja abaixo).

Esta configuração predefinida é obtida através da criação de referências nos cabeçalhos das ramificações remotas em refs/remotos/origem e inicializando as variáveis de configuração remote.origin.url e remote.origin.fetch.

OPÇÕES

-l
--local

Quando o repositório que será clonada está em uma máquina local, esta opção ignora o mecanismo de transporte "compatível com Git" normal e clona o repositório fazendo uma cópia do HEAD e tudo sob os diretórios dos objetos e das refs. Os arquivos sob o diretório .git / objects / são vinculados para economizar espaço sempre que possível.

É predefinido que caso o repositório seja definido como um caminho local (/path/to/repo por exemplo) e a opção --local não seja operacional. Caso o repositório seja definido como uma URL, então a opção será ignorada (e as otimizações locais nunca serão utilizadas). Utilizando a opção --no-local irá sobrescrever o valor predefinido quando /path/to/repo for informado em vez de utilizar o transporte regular do Git.

Impõem o processo de clonagem a partir de um repositório em um sistema de arquivos local para copiar os arquivos no diretório .git/objects em vez de utilizar links físicos. Pode ser desejável caso esteja tentando fazer um backup do seu repositório.

-s
--shared

Quando o repositório que será clonado estiver na máquina local, em vez de utilizar links físicos, configure automaticamente o .git/objetos/info/alternates para compartilhar os objetos com o repositório da origem. O repositório resultante é iniciado sem nenhum objeto próprio.

OBSERVAÇÃO: provavelmente está uma operação muito perigosa; não utilize a menos que compreenda o que ela faz. Caso clone o seu repositório utilizando esta opção e em seguida exclua os ramos (ou use qualquer outro comando Git que faz qualquer commit existente perder a referência) no repositório da origem, alguns objetos podem perder a referência (ou ficarem soltos). Estes objetos podem ser removidos através das operações normais do Git (como git commit) que chama automaticamente o comando git gc --auto. (Consulte git-gc[1].) Caso estes objetos sejam removidos e foram referenciados pelo repositório clonado, o repositório clonado se tornará corrompido.

Observe que executar o comando git repack sem a opção --local em um repositório clonado com --shared, este irá copiar os objetos do repositório da origem em um pacote no repositório que foi clonado, removendo a economia de espaço em disco do clone --shared. É seguro, no entanto, executar o comando git gc, que por predefinição utiliza a opção --local.

Caso queira quebrar a dependência de um repositório clonado com --shared no seu repositório de origem, você pode simplesmente executar o comando git repack -a para copiar todos os objetos do repositório de origem em um pacote dentro do repositório clonado.

--reference[-if-able] <repositório>

Caso o repositório de referência estiver na máquina local, configure automaticamente o arquivo de configuração .git/objects/info/alternates para obter os objetos do repositório de referência. A utilização de um repositório já existente como alternativa, exigirá que menos objetos sejam copiados do repositório que está sendo clonado, reduzindo as despesas do armazenamento local e da rede. Ao utilizar o comando --reference-if-able, um diretório não existente é ignorado com um aviso em vez de interromper a clonagem.

OBSERVAÇÃO: consulte a OBSERVAÇÃO para a opção --shared e também para a opção --dissociate.

--dissociate

Emprestar os objetos dos repositórios a partir da referência utilizada com as opções --reference apenas para reduzir a transferência de rede e parar de tomar emprestado deles após a clonagem, fazendo cópias locais necessárias dos objetos emprestados. Esta opção também pode ser usada na clonagem local a partir de um repositório que já toma emprestado os objetos de um outro repositório—​o novo repositório pegará emprestado os objetos do mesmo repositório, e esta opção pode ser usada para interromper o empréstimo.

-q
--quiet

Operate quietly. O progresso não é relatado para o fluxo de erro predefinido.

-v
--verbose

Executa em modo loquaz. Não afera o relatório da condição geral do progresso para o fluxo de erro padrão.

--progress

A condição do progresso é relatado no padrão do fluxo de erro por padrão quando ele é anexado em um terminal, a menos que --quiet seja utilizado. Esta sinalização impõe a condição geral de progresso mesmo que o fluxo de erro predefinido não seja direcionado para um terminal.

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

-n
--no-checkout

Nenhum checkout de HEAD é executado após o clone estar completo.

--bare

Faça um repositório Git vazio. Ou seja, em vez de criar o <diretório> e colocar os arquivos administrativos dentro do <diretório>/.git, faça com que o próprio <diretório> seja o $ GIT_DIR. Por questões óbvias, há a obrigatoriedade da utilização da opção --no-checkout porque não há onde averiguar a árvore de trabalho. Além disso os cabeçalhos do ramo remoto são copiados diretamente para os cabeçalhos locais correspondentes, sem mapeá-los para refs/remotes/origin/. Quando essa opção é utilizada, nem as ramificações monitoradas remotamente tão pouco as variáveis de configuração relacionadas à elas são criadas.

--sparse

Inicialize a averiguação esparsa para que o diretório de trabalho comece apenas com os arquivos na raiz do repositório. O arquivo "checkout esparso" pode ser modificado para aumentar o diretório de trabalho conforme a necessidade.

--filter=<filter-spec>

Utilize o recurso parcial de clonagem e solicite que o servidor envie um subconjunto de objetos acessíveis de acordo com determinados filtros do objeto. Ao utilizar a opção --filter, o <filter-spec> fornecido é usado para o filtro de clonagem parcial. Como, por exemplo, a opção --filter=blob:none irá filtrar todas as bolhas (conteúdo dos arquivos) até que sejam requisitados pelo Git. A opção --filter=blob:limit=<tamanho> também filtrará todas as bolhas com o tamanho de pelo menos <tamanho>. Para mais detalhes sobre as especificações dos filtros, consulte a opção --filter no git-rev-list[1].

--mirror

Configure um espelho do repositório de origem. Implica no uso da opção --bare. Comparado com a opção --bare, --mirror não apenas mapeia as ramificações locais da origem para as ramificações locais do destino, ele mapeia todas as refs (incluindo as ramificações monitoradas remotamente, anotações, etc.) e define uma configuração refspec onde todas estas refs sejam substituídas através um git remote update no repositório do destino.

-o <nome>
--origin <nome>

Em vez de utilizar o nome remoto origin para acompanhar o repositório "upstream" utilize o `<nome> `.

-b <nome>
--branch <nome>

Em vez de apontar o recém-criado HEAD para um ramo apontado pelo HEAD do repositório clonado, em vez disso, aponte para o ramo <nome>. Em um repositório não vazio, esse é o ramo que será averiguado. A opção --branch também pode pegar as tags e desanexar o HEAD daquele commit no repositório resultante.

-u <upload-pack>
--upload-pack <pacote-para-envio>

Quando informado e o repositório a ser clonado for acessível através do ssh, determina que seja executado um caminho fora do padrão na outra extremidade.

--template=<diretório-modelo>

Informe o diretório de onde os modelos serão utilizados; (Consulte a seção "DIRETÓRIO MODELO" do git-init[1].)

-c <chave>=<valor>
--config <chave>=<valor>

Define uma variável de configuração no repositório recém-criado; isso entra em vigor imediatamente após a inicialização do repositório, antes da captura remota do histórico ou da averiguação de quaisquer arquivos. Como é esperado, a chave está no mesmo formato de git-config[1] (ou seja, core.eol=true). Caso vários valores sejam informados para a mesma chave, cada valor será gravado no arquivo de configuração. Isso o torna mais seguro para incluir "fetch refspecs" adicionais ao "origin" remoto por exemplo.

Devido as limitações da implementação atual, algumas variáveis de configuração não entram em vigor até o próximo "fetch" e "checkout". As variáveis de configuração que são conhecidas por não terem efeito são: remote.<nome>.mirror and remote.<nome>.tagOpt. Em vez disso, utilize as opções correspondentes --mirror e --no-tags.

--depth <profundidade>

Crie um clone raso com um histórico truncado para uma quantidade determinada de revisões. Implica no uso da opção --single-branch a menos que --no-single-branch seja utilizado para resgatar os históricos próximos às pontas de todos os ramos. Caso queira clonar os submódulos superficialmente, utilize também --shallow-submodules.

--shallow-since=<data>

Crie um clone superficial com um histórico após o tempo especificado.

--shallow-exclude=<revisão>

Crie um clone superficial com um histórico, excluindo os commits acessíveis a partir de um ramo remoto ou tag específica. Esta opção pode ser utilizada várias vezes.

--[no-]single-branch

Clone apenas o histórico que leva à ponta de uma única ramificação, especificada pela opção --branch ou pelo ramo primário remoto onde HEAD aponta. As outras capturas feitas no repositório resultante, atualizarão apenas as ramificações monitoradas remotamente onde esta opção foi utilizada para a clonagem inicial. Caso o HEAD remoto não aponte para nenhuma ramificação quando o clone --single-branch foi feito, nenhuma ramificação de rastreamento remoto é criado.

--no-tags

Não clone nenhuma tag e defina remote.<remoto>.tagOpt=--no-tags na configuração, garantindo que futuras operações do comando git pull e do comando git fetch não sigam nenhuma tag. As buscas explícitas subsequentes das tags ainda funcionarão (consulte git-fetch[1]).

Pode ser utilizado em conjunto com o --single-branch para clonar e manter um ramo sem referências além de um único ramo clonado. É útil para manter uma quantidade mínima dos clones do ramo predefinido de algum repositório para a indexação da pesquisa por exemplo.

--recurse-submodules[=<pathspec>]

Depois que o clone é criado, inicialize e clone os submódulos com base no pathspec informado. Caso nenhum pathspec seja informado, todos serão inicializados e clonados. Esta opção pode ser utilizada várias vezes para a consulta de diversas entradas pathspec. O clone resultante de submodule.active define o pathspec informado ou "." (significa todos os submódulos) caso nenhum pathspec seja provido.

Os submódulos são inicializados e clonados utilizando as suas respectivas configurações predefinidas. Este é o equivalente a executar o comando git submodule update --init --recursive <pathspec> imediatamente após que a clonagem for finalizada. Esta opção é ignorada caso o repositório clonado não tenha uma árvore de trabalho/verificação (ou seja quaisquer dos comandos --no-checkout/-n, --bare, ou --mirror seja utilizado)

--[no-]shallow-submodules

Todos os submódulos clonados serão rasos e com uma profundidade 1.

--[no-]remote-submodules

Todos os submódulos que forem clonados, para realizar a atualização os submódulos usarão a condição remota do ramo do submódulo de rastreamento em vez do SHA-1 registrado no superprojeto. Equivale encaminhar --remote para git submodule update.

--separate-git-dir=<dir git>

Em vez de colocar o repositório clonado onde deveria estar, coloque o repositório clonado no diretório especificado e em seguida, faça um link simbólico Git independente do sistema de arquivos para lá. O resultado é que o repositório Git pode ser separado da árvore de trabalho.

-j <n>
--jobs <n>

A quantidade de submódulos que foram recuperados ao mesmo tempo. A predefinição retorna para a opção submodule.fetchJobs.

<repositório>

Os repositórios que serão clonados (possivelmente remotos). Consulte a seção GIT URLS abaixo para mais informações sobre as especificidades dos repositórios.

<diretório>

O nome de um novo diretório que será clonado. A parte "humanística" do repositório de origem é utilizada caso nenhum diretório seja explicitamente informado (repo para /path/to/repo.git e foo para host.xz:foo/.git). A clonagem em um diretório existente é permitida apenas caso o diretório esteja vazio.

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/

Essas duas sintaxes são basicamente equivalentes, exceto que a primeira implica no uso da opção --local.

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.

EXEMPLOS

  • Clonando a partir de um "upstream":

    $ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
    $ cd my-linux
    $ make
  • Faça uma clonagem local que pegue emprestado do diretório atual sem realizar uma averiguação:

    $ git clone -l -s -n . ../copy
    $ cd ../copy
    $ git show-branch
  • Clone a partir de um "upstream" enquanto pega emprestado de um diretório local já existente:

    $ git clone --reference /git/linux.git \
    	git://git.kernel.org/pub/scm/.../linux.git \
    	my-linux
    $ cd my-linux
  • Crie um repositório simples para publicar as suas alterações para o público:

    $ git clone --bare -l /home/proj/.git /pub/scm/proj.git

GIT

Parte do conjunto git[1]