O que é GitHub e qual a diferença entre GitHub e Git

Segundo o relatório Octoverse 2024 do GitHub, o Brasil tem uma das comunidades de desenvolvedores que mais crescem na plataforma e já aparece entre os quatro países com mais desenvolvedores nela, atrás de Estados Unidos, Índia e China. Mesmo assim, uma confusão continua aparecendo em toda turma de iniciantes: “instalei o GitHub, então já sei Git”, ou o contrário.

São coisas diferentes. Git é a ferramenta que roda no seu computador e registra o histórico do código. GitHub é um site (e uma empresa, hoje da Microsoft) que hospeda repositórios Git na nuvem e adiciona por cima recursos de colaboração, automação e vitrine. Você pode usar Git a vida inteira sem GitHub; não dá para usar o GitHub de verdade sem Git.

Git e GitHub frente a frente

A documentação oficial resume a relação na página sobre o GitHub e o Git, em português. Se ainda não está claro como o Git guarda o histórico localmente, vale ler isso primeiro; o resto deste texto pressupõe essa base.

A partir daqui, a pergunta prática deixa de ser “qual a diferença” e passa a ser “para que eu uso o GitHub”. Organizamos pelos usos que mais pesam para quem está começando, do mais ao menos importante.

GitHub como cópia de segurança do seu código

O uso mais básico já justifica a conta gratuita. Notebook roubado, HD que morreu, café derramado: se o repositório está no GitHub, o código está salvo. Você liga o projeto local ao remoto uma vez e depois é só enviar:

git remote add origin https://github.com/seu-usuario/estoque.git
git push -u origin main

Repositórios privados são gratuitos, então não há motivo para guardar código de estudo só no disco. Cuidado com um detalhe: o GitHub guarda o que você enviou, inclusive senhas e chaves esquecidas no código. Arquivo .env vai no .gitignore antes do primeiro push.

Pull request é onde a colaboração acontece

Este é o recurso que fez o GitHub virar padrão. O fluxo comum numa equipe:

1. Você cria uma branch para a tarefa e faz seus commits.
2. Envia a branch com git push.
3. No site, abre um pull request (PR) pedindo que ela seja incorporada à main.
4. Colegas comentam linha por linha, sugerem mudanças, aprovam.
5. Testes automáticos rodam no PR; se passarem e houver aprovação, alguém faz o merge.

Repare que o merge em si é coisa do Git. O GitHub organiza a conversa em volta dele. A seção de documentação de pull requests cobre desde abrir o primeiro até resolver conflitos pela interface.

Em projetos de código aberto, o caminho é parecido, com um passo a mais: você faz um fork (sua cópia do repositório de outra pessoa), trabalha nela e abre o PR para o projeto original. Muita gente consegue a primeira experiência real de revisão de código assim.

Autenticar no GitHub sem senha da conta

O primeiro git push costuma travar aqui. O GitHub não aceita mais a senha da conta para operações Git pelo terminal. Você tem três caminhos:

Token de acesso pessoal (HTTPS)

Gerado em Settings, Developer settings. Funciona como uma senha específica, com prazo de validade e permissões limitadas. Quando o terminal pedir senha, cole o token. Guarde-o num gerenciador de credenciais, nunca num arquivo do projeto.

Chave SSH

Você gera um par de chaves no computador (ssh-keygen -t ed25519), cadastra a chave pública no GitHub e passa a usar endereços no formato [email protected]:usuario/repo.git. Dá um pouco mais de trabalho na primeira vez e depois some da sua frente.

GitHub CLI ou app desktop

O comando gh auth login ou o GitHub Desktop fazem a autenticação pelo navegador e configuram tudo sozinhos. É o caminho mais rápido para quem só quer subir o primeiro projeto sem brigar com o terminal.

O perfil do GitHub como portfólio

Para quem busca a primeira vaga, o perfil público funciona como vitrine. Recrutadores técnicos abrem, olham dois ou três repositórios e tiram conclusões em poucos minutos. O que costuma contar:

• Repositórios fixados (até seis) com os projetos que você mais quer mostrar, não os exercícios do curso.
• README de cada projeto explicando o que ele faz, como rodar e uma captura de tela ou link do projeto no ar.
• Histórico de commits com mensagens claras, mostrando como você pensou, e não um único commit “projeto pronto”.
• Um README de perfil, criado num repositório com o mesmo nome do seu usuário, que o GitHub exibe no topo da sua página.

Um exemplo concreto: o controle de estoque feito para a loja de um parente, com README explicando o problema, link do sistema no ar e uma seção “o que eu faria diferente”, diz mais sobre você do que dez clones de tela de streaming.

O quadradinho verde de contribuições impressiona menos do que parece. Três projetos completos e bem documentados valem mais do que um ano inteiro de commits diários em tutoriais.

Automação com Actions e sites com Pages

Dois recursos que iniciantes descobrem tarde e poderiam usar desde cedo:

• GitHub Actions: roda tarefas automaticamente a cada push ou PR, como executar testes, verificar formatação ou publicar o projeto. Um arquivo YAML na pasta .github/workflows é suficiente para começar. Para repositórios públicos, o uso nos executores padrão é gratuito.
• GitHub Pages: publica um site estático direto de um repositório, de graça, num endereço como seu-usuario.github.io. Ótimo para portfólio, documentação e projetos de front-end.

A plataforma também vem ganhando recursos de IA e automação de agentes. Acompanhamos alguns, como o lançamento do GitHub Agentic Workflows, mas para quem está começando o par Actions e Pages já rende muito.

GitHub, GitLab ou Bitbucket

Como todos hospedam Git, os comandos no seu terminal são os mesmos. A diferença está no ecossistema:

• GitHub: maior comunidade de código aberto, mais visibilidade para portfólio, onde está a maioria das bibliotecas que você vai usar.
• GitLab: forte em CI/CD integrado e pode ser instalado no servidor da própria empresa, por isso aparece muito em bancos e órgãos públicos.
• Bitbucket: integra bem com Jira e outras ferramentas da Atlassian, comum em empresas que já usam esse pacote.

Para iniciante, a recomendação direta é criar conta no GitHub para o portfólio e aprender o fluxo de PR por lá. Se o emprego usar GitLab, a adaptação leva poucos dias, porque a base (Git) é a mesma.

Primeira semana no GitHub, na ordem certa

Crie a conta com um nome de usuário profissional, configure autenticação em dois fatores, suba um projeto pequeno com README decente e abra um pull request para você mesmo, numa branch separada, só para treinar o fluxo. Na semana seguinte, procure uma issue marcada como good first issue num projeto que você usa. Termos como fork, issue e merge estão no glossário de programação do portal, caso algum ainda esteja nebuloso.