Comando Git Clone: Do uso básico às técnicas avançadas

URLs e protocolos Git

Como dá pra ver no exemplo acima de clonagem do repositório “aws-cli”, pra clonar um repositório usando o comando` git clone`, a gente precisa dar a localização do repositório remoto, que é feita através de uma URL Git.

O Git suporta vários protocolos para acessar repositórios remotos, cada um com sua própria estrutura, modelo de segurança e melhores casos de uso. Entender os diferentes tipos de URLs do Git e quando usar cada um deles pode ajudar você a trabalhar com mais segurança e eficiência, principalmente quando estiver colaborando com outras equipes ou automatizando implantações.

Tipos de URLs do Git

Quando você clona um repositório, a URL que você fornece diz ao Git como se conectar ao servidor remoto. Os tipos de URL Git mais comuns são:

HTTPS

Protocolo Seguro de Transferência de Hipertexto (HTTPS). Mais usado pra acessar páginas da web através de um navegador. Esse tipo de URL é fácil de usar e não precisa de nenhuma configuração quando você clona um repositório público. Aqui estão alguns exemplos:

git clone https://github.com/<username>/<repo>.git
git clone https://github.com/aws/aws-cli.git
git clone https://gitlab.com/gitlab-org/gitlab.git

Detalhes da estrutura:

• https:// – Protocolo usado pra comunicação (seguro e compatível com firewall).
• github.com – Domínio do serviço de hospedagem Git.
• username/repo.git – Caminho para o repositório:
• username é o dono (usuário ou organização)
• repo.git é o nome do repositório Git

SSH

Shell Seguro (SSH). Um protocolo de rede autenticado que exige que você mostre suas credenciais ao servidor de hospedagem antes de se conectar. Precisa gerar um par de chaves SSH e adicionar a chave pública ao seu provedor Git (por exemplo, GitHub, GitLab).

git clone git@github.com:<username>/<repo>.git
git clone git@github.com:aws/aws-cli.git
git clone git@gitlab.com:gitlab-org/gitlab.git

Detalhes da estrutura:

• git@ – Diz qual é a conta de usuário SSH (normalmente só git).
• github.com: – Domínio do servidor Git, seguido de dois pontos : (não uma barra).
• username/repo.git – Caminho para o repositório no servidor.

Como não configurei nenhuma chave SSH na minha conta do GitHub, aparece a seguinte mensagem quando tento copiar a URL SSH.

Chave SSH não configurada

Vou falar sobre como configurar chaves SSH na próxima seção.

GIT

Um protocolo leve e não autenticado para acesso somente leitura. É um protocolo exclusivo do git. Hoje em dia, é pouco usado por causa de preocupações com segurança e porque os principais provedores, como GitHub e GitLab, não recomendam mais. Você nem vai encontrar a opção de clonar usando o protocolo git no GitHub ou GitLab.

# Not recommended
git clone git://github.com/<username>/<repo>.git

Detalhes da estrutura:

• git// – Protocolo Git (somente leitura, sem autenticação).
• github.com: – Domínio do servidor Git.
• username/repo.git – Caminho para o repositório no servidor.

Não importa o protocolo de clonagem usado, você pode conferir a URL e o protocolo usados executando os seguintes comandos:

git remote -v
git remote show origin

Escolhendo o protocolo URL certo

Cada protocolo tem suas vantagens e desvantagens. Usando a tabela abaixo, a gente compara os prós e contras de escolher o protocolo certo para o seu caso.

Procedimentos de clonagem específicos do protocolo

Depois de escolher um protocolo de URL Git, o processo de clonagem e o fluxo de trabalho de autenticação são diferentes. Embora os dois métodos acabem fazendo a mesma coisa (clonar um repositório remoto para o seu computador), eles atendem a diferentes preferências de segurança, necessidades dos usuários e complexidades de configuração. 

Nesta seção, vou falar sobre como clonar um repositório usando HTTPS e SSH, junto com as melhores práticas, etapas de configuração e dicas de solução de problemas para garantir um processo de clonagem seguro e tranquilo.

Fluxo de trabalho de clonagem Git HTTPS

Clonar um repositório Git por HTTPS é o jeito mais simples, sendo ideal pra quem tá começando e pra ambientes com restrições (como firewalls corporativos ou redes restritas).

Para clonar um repositório, vá até ele e copie o URL HTTPS. A imagem a seguir foi tirada do GitHub. Vai ser parecido com o seu provedor Git.

Pega o URL HTTPS de um repositório no GitHub

Depois, execute o comando “ git clone ” no destino (por exemplo, seu laptop ou um pipeline CI/CD) onde você quer que o repositório seja clonado.

git clone https://github.com/aws/aws-cli.git

Comando git clone básico

Para clonar um repositório público, como fizemos com o repositório “aws-cli”, não é preciso autenticação, já que o repositório é público. Desde que você tenha o git instalado no seu sistema, você pode clonar o repositório público imediatamente, sem precisar de nenhuma configuração.

Mas, se você estiver clonando um repositório privado, vai precisar de autenticação. Você pode fazer a autenticação por:

• Token de acesso pessoal
• Chaves-mestras

Pra mostrar como funciona a autenticação com um token de acesso pessoal, eu montei um servidor no AWS EC2 e instalei o Git. Quando você usa o comando “ git clone ” num repositório privado, ele pede um nome de usuário e uma senha. Digite seu nome de usuário do GitHub como nome de usuário e seu token de acesso pessoal como senha.

Autenticação HTTPS por nome de usuário/senha

Por causa das novas regras de segurança, o GitHub e outros serviços agora pedem um token de acesso pessoal em vez de uma senha.

Clonagem com instruções de token de acesso a URLs HTTPS. Fonte: GitHub

Você vai ver o seguinte erro se não colocar seu token de acesso pessoal:

O suporte para autenticação por senha foi removido.

Para criar umtoken de acesso pessoal, vá até Criar um token do GitHub e siga as instruções: 

Crie um token de acesso pessoal no GitHub

Para evitar ter que digitar seu token de acesso pessoal toda vez que o Git precisar de autenticação por HTTPS, você pode usar um auxiliar de credenciais para armazenar suas credenciais com segurança. Uma opção popular é o Git Credential Manager. 

No macOS, o Git se integra perfeitamente ao Keychain do macOS, que é o que eu uso pra guardar minhas credenciais. No meu caso, eu autentico usando chaves armazenadas no Keychain, o que me dá uma experiência segura e sem complicações.

Ver auxiliar de credenciais

Chaves de acesso no MacOS

Para configurar uma chave de acesso, vá até as configurações de senha e autenticação do GitHubesiga as instruções.

Crie uma chave de acesso no GitHub

Embora o GitHub permita criar um token de acesso pessoal sem prazo de validade, a maioria das organizações tem políticas de segurança que exigem que os tokens tenham datas de validade. Isso quer dizer que, se um token for usado em ambientes automatizados, como pipelines de CI/CD, e ele expirar, o pipeline vai falhar por causa de erros de autenticação. É essencial regenerar o token antes que ele expire e atualizar seu uso de acordo com as novas regras.

Sem controles adequados, os desenvolvedores podem, sem querer, criar e usar vários tokens de acesso pessoal sem documentação ou rastreamento claros. Isso pode rapidamente causar confusão sobre qual token é usado e onde, dificultando a manutenção e a auditoria. Para uma melhor higiene, é recomendável manter o uso de tokens ao mínimo, documentado e vinculado a casos de uso específicos.

Como clonar um repositório Git usando SSH

O SSH oferece um jeito seguro e persistente de autenticação, especialmente legal para quem contribui com frequência e usuários avançados. Depois de configurado, ele oferece uma maneira fácil de interagir com repositórios sem precisar ficar digitando suas credenciais.

Para configurar a autenticação SSH, primeiro precisamos gerar um par de chaves SSH, que consiste em uma chave pública e uma chave privada.

# ed25519 specifies the key type
ssh-keygen -t ed25519 -C "your_email@google.com"

Crie um par de chaves SSH

Como já tenho uma chave SSH em ~/.ssh/id_ed25519, sobrescrevi o diretório padrão onde as chaves vão ficar. Mas se você estiver criando a chave SSH pela primeira vez no seu dispositivo, aceite o diretório padrão.

Vá até as chaves SSH e GPC no GitHub para configurar sua chave SSH.

Configurar chave SSH no GitHub

Copie o conteúdo da chave pública na seção “Chave”. No meu caso, é o conteúdo do arquivo id_ed25519.pub.

Coloque o conteúdo de id_ed25519.pub

O SSH usa criptografia de chave pública/privada. Mantenha sua chave privada em segurança no seu computador. Pronto, agora você já sabe como clonar um repositório, seja ele público ou privado, usando SSH.

Depois de configurar o SSH, ao selecionar a URL do SSH, a mensagem de aviso não aparece mais, como você pode ver na seção “Tipos de URLs do Git” acima.

Pega o URL SSH de um repositório no GitHub

Como a chave privada SSH tá no meu dispositivo local, vou mostrar como fazer um git clone usando SSH no meu local em vez do servidor EC2.

git clone git@github.com:aws/aws-cli.git

Clonar repositórios públicos e privados usando SSH

Conseguimos fazer o git clone usando SSH!

As vantagens do SSH incluem a segurança e o uso generalizado nas organizações, já que permite a autenticação sem senha, o que é ideal para interações frequentes. As conexões SSH também são resistentes a interrupções de rede e costumam ser mais rápidas do que HTTPS em longas distâncias.

Mas, os desenvolvedores geralmente têm problemas durante a configuração da chave SSH, porque copiam a chave pública errada para o provedor Git. Se você tem várias chaves privadas para diferentes fins, precisa definir no arquivo ~/.ssh/config qual chave usar por host. Caso contrário, ao fazer a autenticação no GitHub, a chave privada destinada ao Bitbucket poderá ser usada, resultando em falha na autenticação.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519

Para testar a conexão e ver se a chave está certa:

Verifique a conexão SSH

Exemplos de uso do git clone

Os exemplos do git clone até agora cobrem as funcionalidades básicas que o comando oferece.

Nesta seção, vou te mostrar as várias opções do comando, que permitem que você personalize o processo de clonagem de um repositório para o seu computador. Se você está trabalhando com ramificações específicas ou otimizando a velocidade, entender essas variações vai te ajudar a usar o git clone de forma mais eficaz.

Clone do repositório básico

O jeito mais simples de usar o ` git clone`, como já vimos, é clonar um repositório remoto para o seu computador.

# HTTPS protocol
git clone https://github.com/aws/aws-cli.git

# SSH protocol
git clone git@github.com:aws/aws-cli.git

Esses comandos criam uma pasta chamada “aws-cli” e inicializam uma cópia local do repositório dentro dela, com o histórico de versões e a configuração de rastreamento remoto.

Clonando para uma pasta específica

Por padrão, o comando ` git clone ` cria um diretório com o nome do repositório. Para especificar um nome de diretório de destino diferente, basta fornecê-lo como segundo argumento. 

Isso clona o conteúdo de aws-cli.git para a pasta local chamada my-project-folder:

git clone https://github.com/aws/aws-cli.git my-project-folder

Clonando para uma pasta específica

Clonando um ramo ou tag específico

Use a bandeira “ --branch ” (ou “ -b ”) para fazer o checkout para o branch especificado depois de clonar todos os branches do remoto. O ramo que você escolheu vira o “HEAD” que tá sendo verificado, com os outros ramos disponíveis localmente pra serem verificados.

Usando nosso exemplo de repositório “aws-cli”, o branch padrão é develop. Vamos tentar clonar e fazer o checkout para o branch master.

# Clone a branch
git clone --branch master https://github.com/aws/aws-cli.git

Clonando um ramo específico

Também dá pra clonar uma tag específica: 

# Clone a tag (read-only snapshot)
git clone --branch 2.27.43 https://github.com/aws/aws-cli.git

Clonando uma tag específica

Essa bandeira é útil quando você está trabalhando em uma versão específica ou em um ramo relacionado ao ambiente (por exemplo, staging, hotfix ou release).

Clone raso (limitado em profundidade)

Se você só precisa da versão mais recente do projeto sem o histórico completo de commits, use a flag --depth para fazer um clone superficial. A bandeira ` --depth ` diz quantos commits você quer clonar.

# Download only the latest commit history
git clone --depth 1 https://github.com/aws/aws-cli.git

Clone superficial

Isso agiliza o processo de clonagem e reduz o uso do disco, ideal para pipelines de CI/CD ou quando você não está interessado no histórico de commits. Isso é super útil pro repositório “aws-cli” que a gente clonou. Como o repositório “aws-cli” tem um longo histórico de commits, a diferença de tempo na inclusão do sinalizador “ --depth ” é enorme.

Diferença de tempo com e sem clonagem superficial

Deixar de lado o histórico de commits, só pegando o mais recente, ajudou a reduzir a quantidade de informação que precisava ser baixada e, assim, diminuiu o tempo necessário.

Configurações avançadas de clonagem

Embora o comando “ git clone ” seja mais usado na sua forma básica, o Git tem várias opções avançadas que dão mais controle, eficiência e personalização durante o processo de clonagem.

Esses recursos são super úteis quando você tá lidando com repositórios grandes, gerenciando repositórios no nível da infraestrutura ou otimizando pra fluxos de trabalho de desenvolvimento específicos. 

Nesta seção, vamos ver operações específicas de ramificações, clones superficiais e parciais, especializações de repositórios e configurações de clonagem detalhadas que ajudam tanto desenvolvedores quanto engenheiros de DevOps.

Operações de clonagem específicas de ramos

Por padrão, git clone pega todos os branches e faz o checkout do branch padrão. Mas, quando você tá trabalhando com repositórios grandes ou contribuindo pra um recurso específico, geralmente é mais eficiente clonar só um branch. Isso pode ser feito usando a flag “ --single-branch ”.

git clone --branch <branch-name> --single-branch <repo-url>
git clone --branch feature/cliq --single-branch https://github.com/aws/aws-cli.git

Clonar um ramo específico

Os benefícios incluem tamanho e tempo de download reduzidos, configuração mais rápida para desenvolvimento específico de recursos e prevenção de histórico de ramificações desnecessárias.

Essa abordagem é ideal quando você quer trabalhar em um branch de lançamento ou evitar baixar todos os branches em repositórios CI/CD ativos. Se o nome do branch não estiver especificado no comando, o Git só vai clonar o branch padrão.

Para saber mais sobre como clonar um branch específico, dá uma olhada no tutorial Clonar branch do Git.

Tipos de repositórios especializados

Quando a gente clona um repositório, dois componentes são clonados: o repositório (a pasta.git ) e o diretório de trabalho. O diretório de trabalho também é conhecido como cópia de trabalho, árvore de trabalho ou área de trabalho.

Diferença entre diretório de trabalho e repositório

O que tem na pasta “ .git ” é o seguinte:

Conteúdo da pasta .git

Isso nos leva ao assunto do repositório vazio.

Repositórios vazios

Um repositório vazio só tem a pasta “ .git ” e não tem diretório de trabalho.

git clone --bare <repo-url>
git clone --bare https://github.com/aws/aws-cli.git

Clonar um repositório vazio

A partir do que vimos acima, dá pra perceber que o que foi clonado com a flag “ --bare ” é só o conteúdo da pasta “ .git ” do repositório que não é bare. Como esse é um repositório vazio, não tem diretório de trabalho, o que significa que não dá pra usar os comandos git, como mostra a imagem abaixo:

A operação precisa ser executada em uma árvore de trabalho

Repositórios vazios são normalmente usados como um repositório central em um ambiente compartilhado para colaboração ou espelhamento, em vez de desenvolvimento ativo. Pra mostrar como clonar a partir do repositório vazio, vou usar o repositório vazio “aws-cli” que tenho no meu computador.

Clonar do meu repositório local vazio

Dá pra ver que esse repositório “aws-cli-non-bare” tem o diretório de trabalho. Execute git remote -v para ver que ele faz referência ao repositório vazio.

Repositórios espelhados

O comando “ git clone --mirror ” cria um espelho do repositório de origem. A bandeira --mirror significa --bare, ou seja, o repositório espelho também não tem um diretório de trabalho.

git clone --mirror <repo-url>
git clone --mirror https://github.com/aws/aws-cli.git

Clonar um repositório (central) para criar um repositório espelho

Mas, comparado com --bare, --mirror não só mapeia os branches locais da fonte para os branches locais do destino, mas também mapeia todas as referências (incluindo branches de rastreamento remoto, notas, etc.) e configura uma configuração refspec de forma que um git remote update no repositório de destino sobrescreva todas essas referências. Isso nos dá uma cópia mais completa, com todas as referências (ramificações, tags, etc.).

Você pode ver a documentação do GitHub pra saber todos os passos pra espelhar um repositório.

Espelhando um repositório em outro lugar. Fonte: GitHub

Filtros de clones parciais e redução do tamanho dos clones

Clones parciais permitem que os usuários peguem só uma parte dos objetos do repositório usando a bandeira “ --filter ”, o que é ótimo pra desenvolvedores que só precisam de uma parte do código, principalmente em ambientes com pouca largura de banda ou espaço em disco. Alguns exemplos comuns da bandeira “ --filter ” são:

• --filter=blob:none: pula o conteúdo do arquivo (blobs)
• --filter=blob:limit=: exclui arquivos com um tamanho específico ou maior
• --filter=tree:: omite todos os blobs e árvores cuja profundidade a partir da árvore raiz é maior ou igual à profundidade definida.

blob:none

A bandeira --filter=blob:none é usada para otimizar as operações de clonagem, evitando o download imediato do conteúdo dos arquivos (blobs).

# Binary Large Objects (BLOB)
git clone --filter=blob:none <repo-url>
git clone --filter=blob:none https://github.com/aws/aws-cli.git

Clonar com filtro=blob:nenhum

Isso é super útil em repositórios grandes ou quando só precisamos de uma parte do projeto. Por exemplo, em monorepos, nem todas as equipes ou desenvolvedores precisam de toda a base de código. 

Um engenheiro front-end que trabalha só em um frontend/ não precisa de serviços back-end ou bibliotecas compartilhadas. Usar o sinalizador “ --filter ” acelera a clonagem e reduz o armazenamento, adiando o download do blob até que seja necessário (por exemplo, quando o arquivo é aberto). A imagem a seguir mostra o que o Git faz nos bastidores quando eu abro um arquivo, baixando o blob do arquivo quando necessário.

O Git baixa o blob do arquivo quando você precisa.

Outro exemplo seria em pipelines de CI/CD. Os pipelines geralmente não precisam de todo o histórico do repositório ou de todos os arquivos. Quando usado junto com o checkout esparso, o comando ` --filter=blob:none ` faz com que o pipeline clone só os diretórios que importam (por exemplo, scripts de implantação).

blob:limit=<size>

A bandeira ` --filter=blob:limit= ` é útil para desenvolvedores que querem evitar baixar arquivos grandes (blobs) durante a clonagem, mas ainda assim recuperar arquivos menores imediatamente. Isso faz parte da funcionalidade de clonagem parcial do Git e é super útil quando você está trabalhando com repositórios que têm conteúdos de tamanhos diferentes.

Por exemplo, em alguns projetos, especialmente aqueles que usam Git LFS ou com ativos de mídia confirmados (por exemplo, vídeos, grandes conjuntos de dados, ativos de jogos), os desenvolvedores podem querer pular arquivos grandes durante a clonagem, acelerando assim a clonagem inicial e adiando o download de arquivos grandes até que sejam explicitamente necessários.

# Binary Large Objects (BLOB)
git clone --filter=blob:limit=<size> <repo-url>
#  The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB
git clone --filter=blob:limit=<n>[kmg] <repo-url>
git clone --filter=blob:limit=1m https://github.com/aws/aws-cli.git

Clonar com filtro=blob:limite

árvore:&lt;profundidade&gt;

A bandeira ` --filter=tree: ` é usada pra limitar a profundidade da estrutura de diretórios que o Git busca objetos de árvore durante uma clonagem, ajudando a reduzir o tamanho da transferência de dados, especialmente útil quando se trabalha com projetos profundamente aninhados, como monorepos. Por exemplo, se você quiser dar uma olhada rápida em uma estrutura monorepo grande, pra auditoria, integração ou revisão, baixar árvores profundas é um desperdício.

git clone --filter=tree:<depth> <repo-url>
git clone --filter=tree:0 https://github.com/aws/aws-cli.git

Clonar com filtro=árvore

Lembre-se de que o servidor Git do qual você está clonando (neste caso, o GitHub) pode suportar apenas determinados valores para a profundidade de filtragem da árvore.

O filtro em árvore permite uma profundidade máxima de 0

Configuração específica do clone

O Git tem várias opções pra personalizar o comportamento durante a clonagem:

• --origin : define um nome remoto personalizado em vez de origem
• --template : usa um diretório de arquivos de modelo para a configuração inicial do .git
• --single-branch: evita buscar outros ramos
• --recurse-submodules: inicializa e clona submódulos automaticamente

Essas opções são úteis quando você está configurando ambientes padronizados, trabalhando com repositórios modulares ou integrando com ferramentas de implantação.

origem

A bandeira ` --origin ` permite que os desenvolvedores personalizem o nome do remoto do qual o repositório é clonado. Por padrão, o Git nomeia o remoto como origin, mas essa flag permite que você mude para outra coisa durante a operação de clonagem.

git clone --origin <remote name> <repo-url>
# Name the remote as “upstream”
git clone --origin upstream https://github.com/aws/aws-cli.git

Renomeie o remoto de origem para upstream

Os desenvolvedores podem precisar mudar o nome remoto pra ficar mais claro, já que podem precisar adicionar outro remoto depois (por exemplo, upstream vs. origem bifurcada). Mudar o nome do primeiro controle remoto ajuda a evitar confusão e conflitos.

modelo

A flag --template permite que os desenvolvedores especifiquem um diretório de modelos personalizado que o Git vai usar ao criar o diretório .git no repositório recém-clonado. Os diretórios de modelos permitem que você defina antecipadamente ganchos, arquivos de configuração ou estruturas de diretórios que são automaticamente aplicados ao repositório durante a inicialização.

# Specify the directory from which templates will be used
git clone --template=<template-directory> <repo>
git clone --template=./git-template https://github.com/aws/aws-cli.git

Como usar a flag --template

Vou falar mais sobre a bandeira de modelo na seção “Aplicativo de diretório de modelos”.

single-branch

A bandeira ` --single-branch ` é usada para clonar só o histórico do branch especificado, em vez de todos os branches no repositório remoto. Isso pode reduzir bastante a quantidade de dados clonados, principalmente em repositórios com muitos branches de longa duração ou um histórico grande de commits.

Quando você é designado para trabalhar em um recurso específico ou ramificação de lançamento (por exemplo, feature/login-ui, release/v2.0), não precisa clonar o histórico de outras ramificações não relacionadas.

git clone --branch feature/login-ui --single-branch <repo-url>

# If you do not specify a branch, Git will clone only the remote's default branch, usually main or master
git clone --single-branch <repo-url>
git clone --single-branch https://github.com/aws/aws-cli.git

Um programa típico do git clone rastreia todos os branches remotos, como mostrado na saída do git branch -r abaixo.

Todas as ramificações remotas são rastreadas

Já que adicionar o comando ` --single-branch ` só clona o histórico do branch especificado.

Só o ramo padrão é rastreado

recurse-submodules

Os submódulos Git são uma referência a outro repositório, fixado a um commit específico. Isso permite que você mantenha o outro repositório Git como um subdiretório do seu repositório Git, geralmente usado para incluir código de terceiros, bibliotecas compartilhadas ou componentes específicos do fornecedor. 

Crieium repositório GitHub público pra mostrar esse conceito.

Mostrar submódulos

Quando a gente clona um projeto com um submódulo, por padrão, a gente pega os diretórios que têm os submódulos, mas não os arquivos dentro deles.

Pasta do submódulo vazia

Em vez de usar o comando “ git submodule init ” pra inicializar o arquivo de configuração local e “ git submodule update ” pra pegar todos os dados desse projeto, a gente pode usar a opção “ --recurse-submodules ” junto com o comando “ git clone ” pra inicializar e clonar automaticamente todos os submódulos definidos no arquivo “ .gitmodules ” de um repositório.

git clone --recurse-submodules <repo-url>

Clonar arquivos dentro do diretório do submódulo

Aplicativo de diretório de modelos

O Git permite usar diretórios de modelos pra definir ganchos padrão, configurações e outros arquivos durante a clonagem ou inicialização do repositório:

A estrutura do diretório de modelos pode ser parecida com a que tá abaixo, com hooks/pre-commit contendo um script shell para bloquear commits sem um ID JIRA e hooks/commit-msg contendo o modelo para mensagens de commit.

/home/devops/git-template/
├── config
├── description
├── hooks/
│   ├── pre-commit
│   └── commit-msg
├── info/
│   └── exclude

Depois de definir os arquivos necessários no diretório de modelos, você pode usá-lo para suas operações de clonagem git.

git clone --template=</path/to/template> <repo-url>
git clone --template=/home/devops/git-template https://github.com/aws/aws-cli.git

Isto é ideal para:

• Como fazer as regras do repositório funcionarem com ganchos (por exemplo, pré-confirmação)
• Definir previamente arquivos de configuração para CI/CD ou ferramentas
• Iniciando projetos com uma estrutura comum

Os diretórios de modelos simplificam o fluxo de trabalho da equipe e garantem a consistência entre repositórios clonados.

Clonagem em diferentes sistemas operacionais

Embora o comando “ git clone ” funcione da mesma forma em todas as plataformas, a experiência pode ser um pouco diferente dependendo do sistema operacional.

Considerações específicas do ambiente — como ferramentas de terminal, formatos de caminho de arquivo e gerenciamento de permissões — podem afetar a forma como os desenvolvedores interagem com o Git. Nesta seção, vou explicar o processo de clonagem no Windows, Linux/Ubuntu e macOS pra te ajudar a entender todas as diferenças.

Windows

No Windows, os desenvolvedores geralmente usam o Git Bash, o PowerShell ou o Prompt de Comando para executar comandos Git. A gente pode instalar o Git na página de downloads, que vem junto com o Git Bash, um shell tipo Unix feito pra usar o Git no Windows.

git clone no Git Bash

git clone no PowerShell

Algumas coisas pra ficar de olho:

• Os caminhos dos arquivos no Git Bash usam o formato Unix (/c/Users/username/), enquanto o PowerShell e o Prompt de Comando usam o formato Windows (C:\Users\username\).
• Se estiver usando o PowerShell, certifique-se de que o Git esteja adicionado ao PATH do seu sistema.

Linux/Ubuntu

Distribuições Linux como o Ubuntu oferecem uma experiência Git perfeita através do seu terminal nativo. Para o exemplo a seguir, eu criei uma instância Ubuntu EC2 na AWS e me conectei a ela via SSH.

Faça SSH na instância Ubuntu EC2

O Git já está instalado por padrão. Mas, se não estiver no seu, é só executar o comando “ sudo apt install git ”.

Instalar o git no Ubuntu

Vá até a pasta que você quer e execute o comando “ git clone ”.

git clone no Ubuntu

Algumas coisas pra ficar de olho:

• Verifique se as chaves SSH estão configuradas corretamente para repositórios privados (~/.ssh/id_rsa).
• As permissões de arquivos e a propriedade do diretório podem afetar as operações do repositório, principalmente quando você clona em caminhos no nível do sistema.

Mac

O macOS tem um ambiente tipo Unix que é bem parecido com o Linux, o que deixa as operações do Git bem intuitivas. O Git geralmente já vem instalado. Se não, instalar o Xcode Command Line Tools (xcode-select --install) também vai instalar o Git.

Abra o Terminal e execute o comando git clone.

git clone no Mac

Algumas coisas pra ficar de olho:

• Assim como no Linux, o gerenciamento de chaves SSH é importante para repositórios privados.
• Os usuários do macOS costumam usar clientes GUI como GitHub Desktop ou Sourcetree; certifique-se de que a configuração do Git esteja correta.

Cenários práticos de implementação

Embora o comando “ git clone ” seja frequentemente usado só para pegar uma cópia de um repositório, ele é muito mais útil do que isso nos fluxos de trabalho de engenharia do mundo real. 

Nesta seção, eu vejo como as estratégias de clonagem podem ser usadas em situações reais, cada uma precisando de uma abordagem personalizada pra garantir a eficiência e a consistência.

Fluxo de trabalho de desenvolvimento empresarial

Em grandes empresas, clonar repositórios de forma eficiente é essencial pra agilizar a integração de desenvolvedores e padronizar a configuração de projetos. A gente pode tentar fazer assim:

• Primeiro, clones superficiais (--depth=1). Costuma ser usado pra reduzir o tempo de configuração pra novos desenvolvedores que não precisam de todo o histórico de commits.
• Segundo, repositórios de modelos. Não confundir com diretórios de modelos. Os repositórios de modelos têm estruturas de pastas, ganchos e submódulos já definidos para serem copiados e começarem projetos rapidinho. No GitHub, você pode ativar um repositório como repositório modelo acessando as configurações.

Configuração do repositório de modelos

Depois de ativar, você vai ver o botão “Usar este modelo” na página inicial do seu repositório.

Use o repositório como modelo

• Por último, ter espelhos internos de repositórios externos reduz a dependência de redes públicas e acelera a clonagem em ambientes seguros.

Como migrar um repositório

As organizações podem migrar repositórios entre plataformas (por exemplo, do GitHub para o GitLab) por vários motivos, incluindo segurança, conformidade ou questões financeiras. A migração vai precisar de um clone espelho pra garantir uma cópia completa, incluindo todos os branches, tags e histórico de commits.

Um processo típico pode ser assim:

# --mirror flag clones all refs and configuration.
git clone --mirror https://source-url.com/your-repo.git
cd your-repo.git
git push --mirror https://target-url.com/your-new-repo.git

Esse método mantém os metadados do Git melhor do que um clone padrão seguido de um push. Depois de migrar, atualize os URLs remotos e veja se as permissões de acesso estão certas.

Otimização do pipeline de CI/CD

Em ambientes automatizados, otimizar as operações de clonagem economiza tempo e reduz o uso de recursos, principalmente em implantações frequentes. A gente pode seguir essas dicas para garantir que tudo corra bem:

• Primeiro, use clones rasos (--depth=1) para acelerar o tempo de início das tarefas.

git clone --depth 1 <repository-url>

• Depois, clona só o ramo que precisas pra evitar referências desnecessárias.

git clone --branch <branch-name> --single-branch <repo-url>

• Por último, se várias etapas do seu pipeline de CI/CD precisarem acessar o mesmo conteúdo do repositório, pense em implementar um mecanismo de cache para evitar operações repetidas de git clone. Em vez de clonar o repositório em cada etapa, armazene em cache o diretório de trabalho após o checkout inicial e passe-o como um artefato ou volume compartilhado para as etapas seguintes. 

Essa abordagem reduz bastante as operações repetidas, acelera a execução do pipeline e economiza recursos de computação e rede.

Solução de problemas e diagnóstico

Embora git clone seja um comando bem usado e simples, os desenvolvedores podem, às vezes, ter problemas durante o processo de clonagem, principalmente em ambientes com controles de autenticação rígidos, configurações personalizadas de repositório ou acesso limitado à rede.

Nesta seção, vou falar sobre os problemas comuns de clonagem e como resolver tudo de um jeito eficiente.

Resolução de falha de autenticação

Falhas de autenticação geralmente acontecem quando você tenta acessar repositórios privados ou usa credenciais que já expiraram. Dependendo do protocolo, HTTPS ou SSH, mensagens de erro e correções diferentes se aplicam. Para ambientes habilitados para MFA, sempre use SSH ou HTTPS com PATs.

Para HTTPS, um erro comum é a falha na autenticação. Isso pode acontecer porque você está usando um token de acesso pessoal que já expirou. Se a MFA estiver ativada, outra razão possível é que o token de acesso pessoal não foi usado como senha.

Falha na autenticação HTTPS

Para SSH, um erro comum seria o erro “Permissão negada (chave pública)”. Isso pode ser porque a chave pública não foi adicionada à conta do provedor Git ou porque a chave privada salva no seu dispositivo local não está no diretório certo.

Falha na autenticação SSH

Você pode ver se tá tudo certo com a conexão usando:

ssh -T git@github.com

Recuperação parcial de objetos clonados

Raramente, ao usar clones parciais ( flags --filter ou --depth ), você pode encontrar objetos ausentes (por exemplo, “erro: objeto &lt;sha&gt; está faltando”) se o Git tentar acessar partes do repositório que não foram buscadas inicialmente.

Nunca passei por isso antes. Mesmo assim, você pode encontrar erros ao acessar commits, branches ou tags antigos. Se isso estiver em um pipeline, as ferramentas ou scripts de compilação podem falhar. Você pode pegar os dados que faltam usando:

# Have Git refetch all objects from the remote, even if it thinks it already has them.
# For dealing with a broken or corrupted partial clone
git fetch --filter=blob:none --refetch

# Convert a shallow clone into a full clone. Retrieves the rest of the commit history that was omitted during the shallow clone.
git fetch --unshallow

# Obtain a deeper history of the branch
git fetch origin <branch> --depth=50

# Fetches 30 more commits from the current branch’s history. Repeat as needed.
git fetch --deepen=30

Faça o Git buscar de novo todos os objetos do remoto

Mensagens de erro comuns do git clone e soluções

Além dos problemas acima que você pode encontrar durantea instalação do git clone, a tabela a seguir mostra outros erros comuns.

Conclusão

O comando “ git clone ” pode parecer simples à primeira vista e, pra muita gente, o uso básico já é suficiente. Mas, como este artigo mostrou, é uma ferramenta básica com aplicações que vão muito além. 

Falamos sobre como funciona o git clone, vimos os tipos de URL e protocolos, demos uma olhada em configurações avançadas e comportamentos específicos do sistema operacional e analisamos cenários reais, como CI/CD, fluxos de trabalho corporativos e técnicas comuns de solução de problemas.

Adaptar o git clone ao seu ambiente — seja para clones superficiais em pipelines, migrações de repositórios ou colaboração em grande escala — pode aumentar significativamente o desempenho e a eficiência da equipe. À medida que os ambientes de desenvolvimento modernos ficam cada vez mais complexos e distribuídos, dominar essas configurações garante que você não esteja só usando o Git, mas também usando-o de forma eficaz.

Olhando para o futuro, os mecanismos de clonagem do Git podem ser melhorados, como clones parciais mais inteligentes, melhor suporte para monorepos grandes e um manuseio mais intuitivo de submódulos e filtros. À medida que o Git evolui, ficar por dentro dessas melhorias vai ajudar os desenvolvedores a trabalhar mais rápido e com mais eficiência em qualquer sistema ou escala.

Pra saber mais sobre o Git, recomendofazer o curso Introdução ao Git. Se você quer levar suas habilidades para o próximo nível, o curso Git Avançado é pra você!