Git e GitHub: qual a diferença e como eles se relacionam

Git e GitHub são confundidos o tempo todo, embora sejam coisas de níveis diferentes. O Git é um programa de controle de versão que você instala no computador: ele guarda cada estado salvo do projeto e permite voltar a ele. O GitHub é um serviço web que armazena cópias de repositórios Git e oferece, em torno delas, ferramentas para trabalho em equipe. O jeito mais fácil de lembrar: o Git é o motor, e o GitHub é a oficina com garagem onde você pode guardar esse motor.

O que é o Git

O Git é um sistema de controle de versão distribuído. Foi criado por Linus Torvalds em 2005 para o desenvolvimento do kernel do Linux e, desde então, virou o padrão da indústria. O Git funciona totalmente local: o histórico de alterações fica numa pasta oculta .git dentro do projeto, e a maioria das operações não precisa de internet.

A palavra "distribuído" é a chave aqui. Cada participante do projeto tem no computador uma cópia completa do repositório com todo o histórico, e não só os arquivos mais recentes. Se o servidor sumir, o projeto pode ser recuperado a partir de qualquer máquina de trabalho.

O que o Git faz por conta própria:

• registra as alterações em commits — snapshots do projeto com autor, data e descrição;
• mostra quem alterou uma linha específica, quando e por quê (git log, git blame);
• mantém linhas de desenvolvimento paralelas em branches e as mescla;
• desfaz erros sem perder o restante do trabalho;
• troca histórico com outros repositórios via git push, git pull e git fetch.

O Git é uma ferramenta de linha de comando. Os clientes gráficos e os painéis embutidos nos editores (VS Code, IntelliJ IDEA) são só camadas sobre os mesmos comandos.

O que é o GitHub

O GitHub é uma plataforma na nuvem para hospedar repositórios Git e hoje pertence à Microsoft. Você cria um repositório lá, envia seu código local com o comando git push, e ele fica disponível para colegas, para o empregador ou para a internet inteira, se o repositório for público.

Mas o valor do GitHub não está só no armazenamento. Em torno do repositório, o GitHub acrescenta o que o Git não tem:

• Pull request — pedido de merge de uma branch, com discussão e code review linha a linha;
• Issues — tarefas e relatórios de bugs vinculados ao projeto;
• GitHub Actions — CI/CD: execução automática de testes, build e deploy a cada push;
• controle de acesso — quem pode ler, escrever e mesclar em branches protegidas;
• perfil de desenvolvedor — gráfico de atividade e projetos públicos que os recrutadores olham;
• GitHub Pages — hospedagem gratuita de sites estáticos direto do repositório.

Buscas como "git hub" ou "github com" normalmente se referem justamente a esse serviço — o endereço dele é github.com. O site oficial do próprio Git é git-scm.com, de onde se baixa o instalador.

Git e GitHub: comparação em tabela

Como Git e GitHub trabalham juntos

A ligação entre eles é o remote, o repositório remoto. O repositório local guarda o endereço do repositório no GitHub sob um nome curto, por padrão origin. A partir daí, a troca acontece com três comandos:

• git push — enviar seus commits novos para o servidor;
• git fetch — baixar os commits dos outros, sem mexer nos seus arquivos;
• git pull — baixar e já integrar as alterações na branch atual (na prática, fetch + merge ou rebase).

Importante: o GitHub não vê o seu código enquanto você não o enviar. O commit existe só localmente até o primeiro git push. Daí vem o erro comum dos iniciantes: "fiz o commit, mas não aparece nada no GitHub".

Caminho típico: do projeto local ao GitHub

# 1. Criamos o repositório localmente
cd my-project
git init
git add .
git commit -m "Primeiro commit"

# 2. Criamos um repositório vazio no github.com (sem README),
#    copiamos o endereço e o conectamos como remote
git remote add origin git@github.com:username/my-project.git

# 3. Renomeamos a branch para main e enviamos
git branch -M main
git push -u origin main

A flag -u (forma completa --set-upstream) vincula a branch local main à remota. Depois disso, basta escrever git push e git pull, sem argumentos.

Caminho inverso: começar por um repositório no GitHub

Se o projeto já está no GitHub, ele não é criado de novo, e sim clonado:

git clone https://github.com/username/my-project.git
cd my-project

O comando baixa todo o histórico e configura automaticamente o remote origin.

Autenticação: SSH ou HTTPS

Desde 2021, o GitHub não aceita a senha da conta para operações Git via HTTPS. Há duas opções que funcionam.

HTTPS + Personal Access Token. O token é criado nas configurações da conta (Settings → Developer settings) e digitado no lugar da senha. Para não digitá-lo toda vez, o Git usa um gerenciador de credenciais — no Windows, ele é instalado junto com o Git for Windows.

Chaves SSH. A opção que os empregadores esperam que você saiba configurar sozinho:

# Geramos a chave
ssh-keygen -t ed25519 -C "you@example.com"

# Exibimos a parte pública e a adicionamos no GitHub:
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# Testamos a conexão
ssh -T git@github.com

Se der certo, o GitHub responde com uma saudação com o seu usuário e explica que não oferece acesso shell — isso é normal. Nesse caso, o endereço do repositório deve estar no formato git@github.com:user/repo.git, e não https://.

Se o repositório já está conectado via HTTPS, dá para trocar para SSH com um único comando:

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab e outros: qual a diferença

O GitHub não é a única hospedagem para Git. Todas trabalham com o mesmo Git, então um repositório pode ser migrado de uma para outra sem perder o histórico. A diferença está no conjunto de ferramentas em torno do código.

No GitLab, o pedido de merge se chama merge request; no GitHub, pull request, mas a ideia é a mesma: propor alterações de uma branch e discuti-las antes do merge. A terminologia muda, os comandos Git são os mesmos.

Um mesmo repositório local pode ter vários remotes ao mesmo tempo — por exemplo, para espelhar o projeto no GitHub e no GitLab:

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

Preciso do GitHub se trabalho sozinho?

Tecnicamente não: o Git funciona muito bem localmente. Mas, mesmo num projeto individual, um repositório remoto tem três vantagens importantes.

• Backup. O notebook quebrou — o código e todo o histórico estão intactos no servidor.
• Trabalho em vários dispositivos. Em casa e no escritório, você sincroniza com push e pull.
• Portfólio. Em processos seletivos para vagas júnior, o perfil no GitHub muitas vezes é visto antes do currículo: se há projetos de verdade, mensagens de commit que fazem sentido, README.

Por onde começar se você é iniciante

Não é preciso aprender Git e GitHub ao mesmo tempo — a ordem importa. Primeiro domine o ciclo local: git init, git status, git add, git commit, git log, branches e merge. Quando isso funcionar sem consulta, crie a conta no GitHub, configure o SSH e aprenda push, pull, fetch. O último passo é o processo em equipe: fork, branch por tarefa, pull request, review.

O que o empregador olha no seu GitHub

Os quadradinhos verdes de atividade não são o principal. Um avaliador experiente analisa outras coisas em poucos minutos:

• mensagens de commit claras, em vez de "fix", "123", "ajustes";
• commits pequenos e lógicos, e não um único gigante "subi o projeto";
• um README explicando como rodar o projeto;
• um arquivo .gitignore: o repositório não tem node_modules, .env com senhas nem arquivos da IDE;
• branches e pull requests mesmo em projetos de estudo — isso mostra que você conhece o processo em equipe.

Erros comuns de iniciantes

"fatal: not a git repository"

Você está executando um comando Git fora de um repositório. Vá para a pasta do projeto ou execute git init. A conta no GitHub não tem nada a ver com isso — é um erro local do Git.

"Permission denied (publickey)"

A chave SSH não foi criada, não foi adicionada ao GitHub ou não foi carregada no ssh-agent. Teste com ssh -T git@github.com e confira a lista de chaves nas configurações da conta.

"rejected … (fetch first)" no push

O servidor tem commits que você não tem — por exemplo, você criou o repositório no GitHub com README. Traga as alterações primeiro: git pull --rebase origin main, depois repita o git push. Não use --force enquanto não entender o trabalho de quem você vai sobrescrever.

Segredos num repositório público

Uma senha ou chave de API que entrou num commit permanece no histórico, mesmo que o arquivo seja apagado depois. Essa chave precisa ser reemitida imediatamente, e o .env deve ser adicionado ao .gitignore com antecedência.

Resumo

O Git é a ferramenta de controle de versão no seu computador; o GitHub é o serviço onde esses repositórios vivem na nuvem e onde se organiza o trabalho em equipe em torno deles. GitLab, Bitbucket e outros são alternativas ao GitHub, não ao Git: por baixo dos panos, todos usam os mesmos commits, branches e comandos. Comece pelo Git local, depois conecte um remote e configure o SSH. A ligação do repositório local com o GitHub, push, pull e fetch são praticados no curso de Git.