Git e GitHub: o que são, como usar e por que todo dev precisa dos dois

Entenda o sistema de controle de versão, a plataforma de colaboração e o fluxo real de trabalho usado por equipes de software.

Por Marcos Guimarães23 set 2026
Git e GitHub: o que são, como usar e por que todo dev precisa dos dois

Linus Torvalds escreveu o Git em 2005 depois que o BitKeeper, ferramenta usada até então no desenvolvimento do kernel Linux, deixou de ser licenciado gratuitamente para o projeto.

O Git é software livre, roda na máquina local e guarda o histórico completo do projeto.

Cada pessoa que clona um repositório recebe uma cópia integral dos commits, não um arquivo resumido.

Esse modelo é chamado de distribuído.

Você consegue commitar, consultar versões antigas e criar branches sem internet.

A sincronização com um servidor vem depois. ## GitHub é a camada de colaboração em cima do Git GitHub entrou no ar em 2008 e foi comprado pela Microsoft em 2018.

A plataforma hospeda repositórios Git e acrescenta recursos que o Git sozinho não tem: pull requests, issues, revisão de código, páginas estáticas e pipelines de integração contínua.

Todo repositório no GitHub é um repositório Git, mas nem todo repositório Git está no GitHub.

Você pode hospedar o mesmo projeto no GitLab, no Bitbucket ou em um servidor próprio.

O Git não depende de nenhuma dessas plataformas para funcionar. ## Os cinco comandos que resolvem o dia a dia git init cria um repositório local. git clone baixa um repositório remoto inteiro. git add seleciona arquivos para o próximo commit. git commit -m "mensagem" grava a alteração no histórico local. git push envia os commits para o repositório remoto.

Existe também git pull, que traz as mudanças do remoto e as integra ao seu branch atual. git status mostra o que está modificado.

Você vai usar esses comandos em quase toda sessão de trabalho, então decore esse conjunto antes de partir para merge e rebase. ## O fluxo de quem trabalha em equipe, passo a passo 1.

Clone o repositório com git clone.

2.

Crie um branch para a tarefa: git checkout -b nome-da-tarefa.

3.

Faça as alterações e confira com git status.

4.

Adicione os arquivos com git add.

5.

Registre com git commit -m.

6.

Envie o branch para o GitHub com git push origin nome-da-tarefa.

7.

Abra um pull request na interface do GitHub.

8.

Peça revisão.

Um colega comenta linha por linha.

9.

Faça o merge na branch principal depois da aprovação.

10.

Apague o branch e atualize sua cópia local com git pull.

Esse ciclo é o coração do trabalho profissional.

O pull request não é um comando do Git.

É um recurso do GitHub que cria uma discussão em torno de um branch antes de integrá-lo. ## Branches e a diferença entre main e feature A branch main guarda a versão estável do projeto.

Branches de feature isolam cada mudança para que o trabalho em andamento não quebre o que já funciona.

No Git, criar um branch custa quase nada porque ele é apenas um ponteiro para um commit.

Sem esse mecanismo, duas pessoas editando o mesmo arquivo ao mesmo tempo produziriam conflitos constantes.

Com branches separados, o conflito aparece apenas no momento do merge e pode ser resolvido com calma. ## Erros comuns na primeira semana Iniciantes costumam commitar arquivos de configuração pessoal, esquecer o git pull antes de começar e escrever mensagens de commit genéricas.

Um arquivo .gitignore na raiz do projeto evita que pastas como node_modules ou arquivos de ambiente subam para o repositório.

Mensagens como "ajustes" não ajudam ninguém a entender o histórico.

O padrão mais aceito descreve o que mudou e por quê, em uma linha curta.

Outro tropeço é trabalhar direto na main em projetos com mais de uma pessoa.

Sem branch, não existe revisão antes do merge, e qualquer erro vai para a versão principal sem filtro. ## Onde aprender na prática A documentação oficial do GitHub tem um guia de início para quem nunca criou um repositório.

O freeCodeCamp publica um guia do iniciante em português com os comandos em ordem.

A Alura tem um artigo de primeiros passos, e o DataCamp compara Git e GitHub em detalhe.

Nenhum deles substitui a prática: crie um repositório de teste, suba um arquivo, quebre o código de propósito e use git log para ver o histórico.

Ver o Git funcionando com as próprias mãos ensina mais que qualquer lista de comandos.