Tutorial de Git para iniciantes: do zero ao pull request

Tutorial de Git para iniciantes: instale, configure, faça commits, branches, merge, resolva conflitos e publique no GitHub. Com cola dos comandos.

Git é o programa que guarda o histórico de tudo que você muda no código, permite voltar no tempo quando algo quebra e deixa várias pessoas trabalharem no mesmo projeto sem se atropelar. Para o dia a dia, você precisa de uns 12 comandos — e este tutorial ensina todos eles, na ordem em que você vai usá-los, até abrir seu primeiro pull request no GitHub.

Não existe vaga de desenvolvimento em 2026 que não use Git. Se você está aprendendo a programar, aprenda Git junto, desde o primeiro projeto, e não "depois".

Os 3 conceitos que destravam o Git

Antes dos comandos, entenda onde seus arquivos podem estar. Quase toda confusão de iniciante vem daqui.

1. Diretório de trabalho (working directory): os arquivos como estão agora na sua pasta.
2. Área de preparação (staging area): o que você marcou para entrar no próximo commit.
3. Repositório: o histórico de commits, guardado na pasta oculta .git.

O fluxo é sempre: você edita arquivos → escolhe o que vai entrar com git add → registra uma "foto" com git commit. Um commit é um ponto salvo no histórico, com autor, data e mensagem. Uma branch é só um ponteiro para um commit, uma linha do tempo paralela onde você trabalha sem mexer na principal.

Instalando o Git

Windows

Baixe o instalador em git-scm.com ou use o winget no PowerShell:

winget install --id Git.Git -e --source winget

O instalador traz o Git Bash, um terminal que aceita os mesmos comandos do Linux e macOS. Use ele para seguir este tutorial. Nas opções de instalação, os padrões estão bons; só escolha o VS Code como editor se for o que você usa.

macOS

O jeito mais rápido é instalar as ferramentas de linha de comando da Apple:

xcode-select --install

Se você usa Homebrew, prefira brew install git, que costuma trazer uma versão mais recente.

Linux (Ubuntu/Debian)

sudo apt update
sudo apt install git

Confira se deu certo:

git --version

Configuração inicial (faça uma vez só)

O Git assina cada commit com seu nome e e-mail. Use o mesmo e-mail da sua conta do GitHub, senão seus commits não aparecem no seu perfil.

git config --global user.name "Seu Nome"
git config --global user.email "voce@exemplo.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"

A terceira linha faz todo repositório novo começar com a branch main (o padrão do GitHub). A quarta define o VS Code como editor para mensagens de commit; se não usa VS Code, pule essa.

Para ver tudo que está configurado:

git config --list

Seu primeiro repositório: init, status, add, commit

Crie uma pasta e transforme-a em um repositório:

mkdir meu-projeto
cd meu-projeto
git init

Crie um arquivo qualquer, por exemplo index.html, e pergunte ao Git o que está acontecendo:

git status

O git status é o comando que você mais vai digitar na vida. Ele mostra arquivos novos (untracked), modificados e o que já está preparado para o commit. Na dúvida, rode git status.

Agora prepare o arquivo e faça o commit:

git add index.html
git commit -m "Cria página inicial"

Para adicionar tudo que mudou na pasta de uma vez:

git add .

Dica: antes de um git add ., rode git status e confira a lista. É assim que senhas, arquivos .env e pastas gigantes acabam no GitHub por acidente.

Como escrever boas mensagens de commit

Mensagem de commit é para o você do futuro, que vai procurar "quando foi que quebrou o login". Regras simples:

• Use o imperativo e seja específico: "Corrige validação de e-mail no cadastro", não "ajustes" ou "update".
• Um commit = uma mudança lógica. Corrigiu um bug e mudou o CSS do rodapé? São dois commits.
• Commite com frequência. Commits pequenos são fáceis de entender e de desfazer.

Muitos times usam o padrão Conventional Commits (feat:, fix:, docs:). Vale conhecer, mas siga o padrão do projeto em que você estiver.

Vendo o histórico e as diferenças

git log
git log --oneline --graph --all
git diff
git diff --staged

O git log --oneline --graph --all mostra o histórico compacto com o desenho das branches. O git diff mostra o que mudou e ainda não foi para a staging; com --staged, mostra o que vai entrar no próximo commit. Para sair do log, aperte q.

.gitignore: o que nunca deve ir para o repositório

O arquivo .gitignore, na raiz do projeto, lista o que o Git deve ignorar. Crie ele antes do primeiro commit. Um exemplo para projeto JavaScript:

# dependências (são reinstaladas com npm install)
node_modules/

# variáveis de ambiente e segredos
.env
.env.local

# builds e caches
dist/
build/
.cache/

# lixo de sistema e editor
.DS_Store
Thumbs.db
.idea/

Não precisa decorar: o GitHub oferece modelos prontos por linguagem ao criar um repositório, e o repositório github/gitignore tem modelos para praticamente tudo.

Atenção: se um arquivo já foi commitado, colocá-lo no .gitignore não remove do histórico. Para parar de rastreá-lo, use git rm --cached nome-do-arquivo e faça um commit. Se era uma senha ou chave de API, troque a chave: considere que ela vazou.

Branches: trabalhe sem medo de quebrar a main

A regra de ouro dos times: a main sempre funciona. Toda feature ou correção nasce em uma branch separada.

git switch -c feature/formulario-contato

Isso cria a branch e já muda para ela. Para ver as branches e trocar entre elas:

git branch
git switch main

Você vai encontrar tutoriais antigos usando git checkout -b. Funciona igual, mas o git switch (e o git restore, que veremos adiante) foram criados justamente para separar as funções que o checkout acumulava. Prefira os novos.

Dica: antes de trocar de branch, faça commit ou guarde as mudanças com git stash. Depois, recupere com git stash pop.

Merge: juntando o trabalho

Terminou a feature na branch? Volte para a main e traga as mudanças:

git switch main
git merge feature/formulario-contato

Se a main não mudou desde que você criou a branch, o Git faz um fast-forward: só avança o ponteiro. Se as duas andaram, ele cria um commit de merge juntando as linhas do tempo.

Branch já mesclada pode ser apagada:

git branch -d feature/formulario-contato

Conflitos: o que fazer quando o Git não sabe decidir

Conflito acontece quando duas branches mudaram as mesmas linhas do mesmo arquivo. Não é erro, não é bug, e não quebrou nada. É o Git pedindo para você decidir.

O git merge vai avisar CONFLICT e o arquivo vai ficar assim:

<<<<<<< HEAD
<h1>Bem-vindo ao meu site</h1>
=======
<h1>Olá, seja bem-vindo</h1>
>>>>>>> feature/formulario-contato

O que está entre <<<<<<< HEAD e ======= é a versão da branch atual; o que está entre ======= e >>>>>>> vem da outra branch. Para resolver:

1. Abra o arquivo e escolha uma versão, a outra, ou uma combinação das duas.
2. Apague as três linhas de marcação (<<<<<<<, =======, >>>>>>>).
3. Salve, marque como resolvido e conclua:

git add index.html
git commit

O VS Code mostra botões "Accept Current", "Accept Incoming" e "Accept Both" em cima de cada conflito, o que ajuda bastante. Se você se perdeu e quer começar de novo:

git merge --abort

A melhor prevenção é simples: branches curtas, merges frequentes e git pull antes de começar a trabalhar.

GitHub: remote, push, pull e pull request

Até aqui, tudo ficou no seu computador. O GitHub guarda uma cópia na nuvem e é onde o trabalho em equipe acontece (GitLab e Bitbucket funcionam de forma parecida).

Autenticação

O GitHub não aceita a senha da conta no git push. O caminho mais simples é instalar o GitHub CLI e rodar:

gh auth login

Siga as perguntas e pronto, o Git passa a se autenticar sozinho. A alternativa clássica é configurar uma chave SSH, explicada na documentação oficial do GitHub.

Conectando e enviando (push)

Crie um repositório vazio no GitHub (sem README, para não gerar conflito no primeiro envio) e conecte:

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

origin é o apelido padrão do repositório remoto. O -u liga sua main local à main remota; depois disso, basta git push.

Clonando um projeto existente

git clone https://github.com/usuario/projeto.git

O clone já vem com o origin configurado.

Baixando mudanças (pull)

git pull

O git pull busca as novidades do remoto e mescla na sua branch. Se quiser só ver o que chegou sem mesclar, use git fetch.

Pull request, passo a passo

O pull request (PR) é como se propõe uma mudança em um time: você mostra o que fez, alguém revisa, e só então vai para a main.

git switch main
git pull
git switch -c fix/link-quebrado-rodape
# ...edita os arquivos...
git add .
git commit -m "Corrige link quebrado no rodapé"
git push -u origin fix/link-quebrado-rodape

O GitHub vai mostrar um botão "Compare & pull request". Clique, escreva o que mudou e por quê, e peça revisão. Se o revisor pedir ajustes, é só fazer novos commits na mesma branch e dar git push: o PR atualiza sozinho. Depois do merge, apague a branch.

Dica: para recrutador, um GitHub com projetos bem documentados e PRs em projetos open source pesa mais que certificado. Comece por issues marcadas como good first issue.

Comandos de emergência: desfazendo erros

Quase tudo no Git tem volta. O segredo é saber qual ferramenta usar e se o commit já foi enviado para o remoto.

Descartar mudanças que ainda não foram commitadas

git restore arquivo.js

Volta o arquivo para como estava no último commit. Isso apaga suas mudanças nesse arquivo de vez, sem lixeira.

Tirar um arquivo da staging (desfazer o add)

git restore --staged arquivo.js

O arquivo continua modificado, só sai do próximo commit.

Corrigir o último commit

Errou a mensagem ou esqueceu um arquivo?

git add arquivo-esquecido.js
git commit --amend -m "Mensagem corrigida"

Só faça isso se o commit ainda não foi enviado com push.

Desfazer um commit que já está no GitHub: revert

git revert a1b2c3d

O revert cria um novo commit que desfaz as mudanças do commit indicado (pegue o hash no git log --oneline). O histórico é preservado, ninguém do time é prejudicado. Para commits já compartilhados, essa é a resposta certa.

Reset: poderoso e perigoso

O reset move a branch para trás, como se commits não tivessem existido. Use só em commits locais, que ainda não foram enviados.

git reset --soft HEAD~1   # desfaz o último commit, mantém as mudanças na staging
git reset HEAD~1          # desfaz o último commit, mantém as mudanças nos arquivos
git reset --hard HEAD~1   # desfaz o último commit e APAGA as mudanças

Atenção: git reset --hard apaga trabalho não commitado sem perguntar. E fazer reset em commits que já estão no remoto obriga um git push --force, que pode apagar o trabalho de colegas. Em branch compartilhada, use revert.

A rede de segurança: reflog

Fez besteira com reset? O git reflog lista tudo por onde o HEAD passou recentemente, inclusive commits "perdidos":

git reflog
git reset --hard HEAD@{2}

Ache a linha de antes do erro e volte para ela. Já salvou muita gente.

Cola: os comandos mais usados

Como praticar de verdade

Ler sobre Git não ensina Git. Faça isto esta semana:

1. Pegue um projeto seu (mesmo um exercício simples) e coloque no GitHub com .gitignore e README.
2. Crie uma branch, mude algo, abra um PR para você mesmo e faça o merge pelo GitHub.
3. Provoque um conflito de propósito: mude a mesma linha em duas branches e resolva.
4. Faça um commit errado e desfaça com revert. Depois, local, com reset --soft.

Para treinar branches de forma visual, o Learn Git Branching é gratuito, está em português e é excelente. Para se aprofundar, o livro Pro Git é a referência oficial e também é gratuito.

Git é uma das práticas que separam quem programa de quem é um bom desenvolvedor. Se você ainda está montando sua trilha de estudos, veja nossa seleção dos melhores cursos de programação e o guia de como programar do jeito certo — e coloque cada exercício que fizer em um repositório.