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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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.

Em vez de utilizar o nome remoto origin para acompanhar o repositório "upstream" utilize o `<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.

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.

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

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.

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.

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

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.

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.

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

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.

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

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.

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.

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

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.

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.