Clonar um repositório Git no Linux sem se enganar de chave nem de pasta

Um git clone cria uma cópia de trabalho e geralmente adiciona o repositório remoto com o nome origin. O problema surge antes do primeiro comando: uma URL SSH usa sua chave, uma URL HTTPS geralmente requer um token, e a pasta de destino não deve já conter arquivos úteis. Reserve dois minutos para verificar esses três pontos antes de executar um script baixado da internet.

Tux segurando um repositório Git e uma chave SSH diante de dois caminhos de clonagem Linux — Antes de clonar um repositório, verifique a URL, a chave utilizada e a pasta de destino.

Escolher HTTPS ou SSH antes de clonar

Use HTTPS para recuperar um projeto público ou quando você não deseja configurar uma chave neste computador. Para enviar para GitHub, GitLab ou sua forge, a senha da conta geralmente não é mais suficiente: o serviço pede um token de acesso pessoal.

Use SSH se sua chave pública já estiver associada à sua conta na forge. Este método evita a necessidade de digitar um token, mas falha se a chave errada for proposta ou se o agente SSH não a carregar. Comece verificando a identidade utilizada:

ssh -T [email protected]
ssh-add -l

Adapte o primeiro host à sua forge. Uma resposta de autenticação sem shell remoto é normal em vários provedores de Git. Se você gerencia várias chaves, verifique seu arquivo ~/.ssh/config com ssh -G [email protected] antes de culpar o Git. Nosso guia para configurar SSH para vários servidores explica como definir uma chave e uma conta por alias.

Criar a cópia em um diretório vazio e identificável

Posicione-se em um diretório reservado para seus projetos. Sem um segundo argumento, o Git cria uma pasta a partir do nome do repositório. Com um nome explícito, você evita confundir uma cópia de teste com aquela que contém suas modificações.

mkdir -p ~/projetos
cd ~/projetos
pwd
ls -la

git clone https://github.com/octocat/Hello-World.git hello-test
cd hello-test

Não inicie um clone em uma pasta cujo conteúdo você não conhece. O Git geralmente recusa um diretório não vazio, mas é mais seguro verificar pwd e ls -la antes do comando. Para uma cópia destinada apenas à leitura do código, HTTPS continua sendo a escolha mais simples.

Com SSH, a mesma operação se parece com isto:

git clone [email protected]:meu-conta/meu-projeto.git meu-projeto
cd meu-projeto

Substitua o host, a conta e o repositório pelos valores exibidos pela sua forge. Nunca copie uma URL recebida em uma mensagem suspeita. Primeiro, abra a página oficial do projeto e compare o proprietário, o nome do repositório e a URL de clonagem.

Verifique o remote e os arquivos antes de executar qualquer coisa

Após o clone, verifique a origem, a branch ativa e o estado do diretório. Esses comandos não modificam o projeto:

git remote -v
git branch --show-current
git status
git log -1 --oneline
find . -maxdepth 2 -type f -name 'README*' -o -name 'INSTALL*'

git remote -v exibe as URLs usadas para recuperar e enviar mudanças. Verifique-as antes de um primeiro git push, especialmente se o projeto contém uma configuração de implantação. Em seguida, leia o README, os arquivos INSTALL, as dependências e os scripts de inicialização. Um repositório Git pode conter um script válido, antigo ou francamente arriscado, ele não adquire sua confiança porque o clone foi bem-sucedido.

Para recuperar uma atualização mais tarde, permaneça na pasta clonada e comece verificando seu trabalho:

git status
git fetch origin
git log --oneline HEAD..origin/$(git branch --show-current)
git pull --ff-only

git pull --ff-only recusa uma fusão automática se seus commits locais e o repositório remoto divergirem. Isso é preferível a uma atualização que mistura mudanças enquanto você ainda não olhou para a branch ou o remote.

A documentação oficial do git clone detalha as opções como --depth, --branch e --recurse-submodules. Guarde-as para uma necessidade identificada. Para um primeiro clone, uma URL verificada, uma pasta limpa e a leitura do README já evitam a maioria dos erros.