Git e GitHub em 2026: Guia Prático do Zero ao Pull Request

Git e GitHub: qual é a diferença?

Git é distribuído: cada clone contém o histórico necessário para trabalhar, criar branches e commits localmente.

Você pode usar Git sem Internet e sem GitHub. GitLab, Bitbucket, Azure Repos e servidores próprios também hospedam repositórios Git.

GitHub oferece a camada de colaboração: permissões, issues, pull requests, revisão de código, Actions, releases, regras de branch e interface web.

Ao executar git push, você envia commits ao repositório hospedado; ao abrir um pull request, usa um recurso do GitHub para propor que uma branch seja integrada a outra.

Essa separação evita confusões frequentes. git commit não publica nada na Internet; git push não cria automaticamente um pull request; baixar o ZIP de um projeto não cria um clone com histórico.

O Git cuida dos objetos e referências; a plataforma organiza pessoas e processos em torno deles.

O modelo mental do Git

Pense em quatro áreas. O diretório de trabalho contém os arquivos que você edita. O staging area, também chamado de index, reúne exatamente o que entrará no próximo commit.

O repositório local guarda os commits. O remoto é uma cópia compartilhada, como a hospedada no GitHub.

• Arquivo modificado: existe apenas no seu diretório de trabalho.
• git add: copia a versão escolhida para o staging.
• git commit: registra o conteúdo preparado no histórico local.
• git push: envia commits locais para uma referência no remoto.
• git fetch: atualiza referências remotas sem misturá-las ao seu trabalho.
• git pull: busca e integra mudanças à branch atual.

O staging permite separar mudanças. Você pode corrigir um bug e ajustar uma documentação no mesmo diretório, mas preparar apenas a correção para o primeiro commit.

Use git diff para ver mudanças não preparadas e git diff --staged para revisar o que será confirmado.

Como instalar e configurar o Git

Instale o Git pelo pacote oficial do sistema ou pela página do projeto. Depois, confirme a instalação e configure nome e e-mail.

Esses dados identificam o autor do commit; eles não são automaticamente suas credenciais do GitHub. Use um e-mail associado à conta ou o endereço privado fornecido pela plataforma se não quiser expor o endereço pessoal.

git --version
git config --global user.name "Seu Nome"
git config --global user.email "seu-email@example.com"
git config --global init.defaultBranch main
git config --global --list

A opção --global aplica a configuração ao usuário. Dentro de um repositório, você pode omiti-la para definir outro e-mail somente naquele projeto.

Evite copiar configurações avançadas sem entender; aliases e comportamentos personalizados dificultam seguir tutoriais e diagnosticar máquinas diferentes.

Criar ou clonar um repositório

Para começar um projeto local, entre na pasta e execute git init. Isso cria o diretório interno .git, onde ficam histórico, referências e configurações.

Não apague essa pasta e não versione um repositório dentro de outro sem intenção.

mkdir meu-projeto
cd meu-projeto
git init
git status

Para trabalhar em um projeto existente, use git clone. O comando baixa arquivos, histórico e configura um remoto chamado origin.

Clone apenas uma vez; depois, atualize o mesmo diretório com fetch ou pull.

git clone git@github.com:usuario/repositorio.git
cd repositorio
git remote -v

Fluxo local: status, add, commit e log

Comece sempre por git status. Ele informa a branch, arquivos modificados, conteúdo preparado e relação com o remoto. Leia a saída antes de executar um comando destrutivo.

Em seguida, revise diferenças, selecione o que pertence à mudança e crie o commit.

git status
git diff
git add src/arquivo.js
git diff --staged
git commit -m "Corrige validação do formulário"
git log --oneline --decorate -10

Evite usar git add . por hábito quando o diretório contém arquivos temporários, credenciais ou mudanças sem relação.

O comando é útil quando você revisou tudo. Para preparar partes de um arquivo, use git add -p; o modo interativo permite escolher blocos e formar commits mais coerentes.

Uma mensagem de commit deve explicar a intenção, não repetir o nome do arquivo. “Corrige cálculo do desconto para cupom expirado” ajuda mais que “alterações” ou “ajustes finais”.

Se escrever código legível ainda for um desafio, os truques para código limpo ajudam a reduzir diffs difíceis de revisar.

Como usar o .gitignore sem esconder arquivos errados

O arquivo .gitignore descreve caminhos que não devem entrar no controle de versão: dependências instaladas, builds, caches, arquivos locais do editor e segredos.

Ele deve ser versionado para que a regra seja compartilhada.

node_modules/
.env
.env.local
dist/
coverage/
*.log

O .gitignore não remove um arquivo já rastreado. Se um .env entrou em commit, remova-o do index com git rm --cached .env, faça commit e rotacione imediatamente qualquer credencial exposta.

Apagar no commit seguinte não remove o segredo do histórico nem de clones existentes.

Não ignore o arquivo de lock de dependências de uma aplicação sem motivo.

Ele normalmente garante versões reproduzíveis. Também não adicione uma regra ampla como config* sem verificar se arquivos necessários desaparecerão do staging. Use git status --ignored quando uma pasta parece sumir.

Branches, switch e merge

Branch é um nome que aponta para uma sequência de commits. Criar uma branch é barato e não duplica fisicamente o projeto.

Use uma branch curta por correção ou funcionalidade, com nome descritivo.

git switch main
git pull --ff-only
git switch -c feature/cadastro-cliente

# edite, teste e crie commits
git status
git add -p
git commit -m "Adiciona validação do cadastro"

O comando git switch deixa explícita a troca de branch; git checkout continua existente e também atende fluxos antigos.

Antes de mudar, confirme se alterações locais podem acompanhar a troca. Faça commit coerente, use stash ou finalize o trabalho, em vez de misturar estados sem entender.

Para integrar localmente, volte à branch de destino e use git merge nome-da-branch. Em equipes, essa integração costuma ocorrer no GitHub depois de revisão e testes.

Não faça merge em main local e depois tente abrir um pull request da branch já esvaziada.

Repositório remoto: remote, fetch, pull e push

origin é apenas o nome convencional do remoto criado pelo clone. Confira a URL com git remote -v. Para conectar um projeto iniciado localmente, adicione o remoto e envie a branch principal.

git remote add origin git@github.com:usuario/repositorio.git
git push -u origin main

O parâmetro -u define a relação de acompanhamento. Depois, git push e git pull sabem qual referência usar. Para publicar uma branch nova, execute git push -u origin feature/cadastro-cliente.

git fetch origin atualiza referências como origin/main sem alterar seus arquivos. Você pode comparar antes de integrar. git pull combina fetch com integração — merge ou rebase conforme configuração.

Para iniciantes, git pull --ff-only é útil quando você quer avançar somente sem criar merge automático inesperado.

Autenticação segura no GitHub

Para operações Git pela rede, use SSH, GitHub CLI ou HTTPS com credencial apropriada.

A senha da conta não deve ser usada como senha de Git em HTTPS. Nunca coloque token na URL, em script versionado ou captura de tela.

Com SSH, você gera um par de chaves, protege a chave privada e adiciona apenas a pública ao GitHub.

A documentação oficial de SSH do GitHub explica autenticação e recomenda passphrase e revisão periódica das chaves. A chave privada permanece na sua máquina e não deve ser enviada a ninguém.

Proteja também a conta com autenticação multifator e revise sessões, aplicações e chaves antigas.

Se uma credencial for publicada, revogue-a primeiro e só depois limpe o histórico. Tratar apenas o commit deixa uma janela de acesso aberta.

Como criar um pull request

Depois de enviar sua branch, abra um pull request comparando-a com a branch de destino.

O PR é uma proposta: mostra commits e diff, permite discussão, executa verificações e registra a decisão de merge. Conforme a documentação do GitHub sobre pull requests, as branches de origem e destino precisam ser diferentes.

• Título: descreva o resultado da mudança.
• Contexto: explique o problema e por que ele importa.
• Solução: resuma a abordagem e decisões relevantes.
• Validação: informe testes executados e evidências úteis.
• Riscos: destaque migração, compatibilidade, segurança ou rollback.
• Escopo: aponte o que ficou deliberadamente fora.

Um pull request pequeno é mais fácil de revisar e reverter. Evite combinar refatoração ampla, formatação automática e funcionalidade nova sem necessidade.

Se o projeto vai compor seu portfólio, o artigo sobre portfólio de desenvolvedor web mostra como apresentar decisões e resultados além do código.

Revisão, verificações e proteção de branch

Revisar não significa procurar apenas erros de sintaxe. Confira regra de negócio, nomes, testes, impacto em segurança, desempenho, migrações e clareza. Faça perguntas específicas e critique o código, não a pessoa.

O autor deve responder dúvidas, atualizar a branch e manter o PR compreensível.

Branches protegidas podem exigir aprovação, verificações de status e resolução de conversas antes do merge.

A documentação de branches protegidas do GitHub lista controles como reviews, status checks, commits assinados e restrição de push. Escolha regras compatíveis com o risco do repositório.

Testes automáticos no PR reduzem regressões. O guia de CI/CD com GitHub Actions mostra como ligar lint, testes e build ao fluxo de revisão. Para melhorar a suíte desde a origem, veja também Test-Driven Development.

Como resolver conflitos de merge

Um conflito ocorre quando o Git não consegue combinar automaticamente alterações concorrentes.

Isso não significa que o repositório quebrou; significa que uma pessoa precisa decidir o resultado. Atualize as referências, integre a branch de destino e abra os arquivos indicados por git status.

git fetch origin
git switch feature/cadastro-cliente
git merge origin/main
git status

Os marcadores <<<<<<<, ======= e >>>>>>> delimitam as versões. Edite o arquivo para manter o resultado correto, remova os marcadores, execute testes, faça git add e conclua o merge com commit.

Não escolha “aceitar ambos” automaticamente; o código combinado pode duplicar lógica.

Se perceber que iniciou o merge errado e ainda não concluiu, use git merge --abort. Antes de resolver, converse com quem alterou a outra parte quando a decisão envolve regra de negócio.

O compilador pode aceitar duas versões incompatíveis com o produto.

Merge ou rebase: quando usar

Merge preserva a relação entre as linhas de desenvolvimento e pode criar um commit de merge.

Rebase reaplica commits sobre outra base, produzindo histórico linear. Ambos podem ser corretos; a equipe deve escolher uma política e entender as consequências.

Use rebase com segurança em commits locais ou em uma branch cuja reescrita foi combinada.

Evite rebase de histórico público usado por outras pessoas, pois os commits recebem novos identificadores.

Depois de rebase em uma branch remota própria, pode ser necessário git push --force-with-lease; prefira essa opção a --force, porque ela verifica se o remoto mudou inesperadamente.

Para começar, merge é mais fácil de visualizar. Aprenda rebase depois que HEAD, branch e remoto estiverem claros. Um histórico “bonito” não compensa a perda de trabalho causada por reescrita sem coordenação.

Como desfazer mudanças com segurança

Antes de desfazer, responda: a mudança está sem commit, apenas no staging, em commit local ou já foi compartilhada? A documentação oficial do Git diferencia restore, revert e reset pelo objeto alterado e pelo efeito no histórico.

git restore: descarte ou retire mudanças do staging

git restore arquivo restaura o arquivo do diretório de trabalho usando o index por padrão e descarta alterações não salvas. Confira o diff antes. Para retirar do staging mantendo a edição, use git restore --staged arquivo.

git diff
git restore src/arquivo.js

# manter o conteúdo, mas retirar do próximo commit
git restore --staged src/arquivo.js

git revert: desfaça um commit compartilhado

git revert HASH cria um novo commit que aplica o inverso. É a opção normal para desfazer uma mudança já enviada e compartilhada, pois preserva o histórico.

O Git pode pedir resolução de conflitos se o código evoluiu depois.

git reset: mova o histórico local com cuidado

git reset move a referência da branch e pode alterar staging e arquivos conforme o modo. --soft mantém mudanças preparadas; o modo padrão, mixed, mantém arquivos fora do staging; --hard descarta conteúdo rastreado.

Use reset para ajustar histórico local que ainda não foi compartilhado e trate --hard como operação destrutiva.

Como guardar trabalho temporário com stash

Stash guarda temporariamente mudanças rastreadas para limpar o diretório.

É útil ao alternar para uma correção urgente, mas não substitui commits nem backup. Dê uma mensagem e não acumule entradas sem contexto.

git stash push -m "WIP cadastro de cliente"
git stash list
git stash show -p stash@{0}
git stash apply stash@{0}

apply mantém a entrada; pop tenta aplicar e removê-la. Prefira apply até confirmar que tudo voltou.

Arquivos não rastreados não entram por padrão; -u os inclui. Segredos ignorados continuam fora e não devem ser usados como mecanismo de transporte.

Como criar commits fáceis de revisar

• Faça uma mudança lógica por commit.
• Revise git diff --staged antes de confirmar.
• Não misture formatação ampla com alteração funcional.
• Use mensagens no imperativo que expliquem a intenção.
• Inclua testes junto da regra que eles validam.
• Não versione segredos, builds ou dependências instaladas.
• Evite commits gigantes no fim do dia; registre etapas funcionais.
• Corrija o commit local antes do push quando isso torna a história mais clara.

Ferramentas de IA podem sugerir comandos e mensagens, mas revise cada diff e nunca execute uma sequência destrutiva sem entender.

O artigo sobre GitHub Copilot discute onde assistência ajuda e onde a validação humana continua indispensável.

Um fluxo Git simples para equipes

1. Crie ou selecione uma issue com objetivo claro.
2. Atualize main e abra uma branch curta.
3. Implemente em commits pequenos e execute testes localmente.
4. Envie a branch e abra um pull request com contexto.
5. Aguarde verificações e trate comentários de revisão.
6. Atualize a branch conforme a política do projeto.
7. Faça merge pela estratégia definida: merge commit, squash ou rebase.
8. Remova a branch concluída e atualize seu repositório local.

Squash reúne commits do PR em um commit na branch principal; é útil quando os commits intermediários são ruidosos.

Merge commit preserva a topologia; rebase and merge mantém linha única. Não existe estratégia universal. Consistência, rastreabilidade e facilidade de reversão importam mais que preferência estética.

Exercício: do zero ao pull request

Crie um repositório de teste no GitHub sem arquivos iniciais e execute o fluxo abaixo. Substitua a URL e não use dados sensíveis.

mkdir pratica-git
cd pratica-git
git init

echo "# Prática Git" > README.md
git add README.md
git commit -m "Adiciona README inicial"

git remote add origin git@github.com:usuario/pratica-git.git
git push -u origin main

git switch -c docs/adiciona-instalacao
echo "" >> README.md
echo "## Instalação" >> README.md
git add README.md
git commit -m "Documenta instalação"
git push -u origin docs/adiciona-instalacao

No GitHub, abra o pull request de docs/adiciona-instalacao para main. Confira Files changed, explique o objetivo, faça o merge e depois execute localmente git switch main e git pull --ff-only.

Esse ciclo ensina mais que uma lista desconectada de comandos.

Erros comuns com Git e GitHub

• Commitar na branch errada: crie a branch no commit atual antes de continuar.
• Usar add sem revisar: arquivos temporários e segredos entram no commit.
• Confundir commit com backup remoto: sem push, o commit continua só na máquina.
• Executar reset –hard por sugestão: alterações não confirmadas podem ser perdidas.
• Usar force em branch compartilhada: commits de colegas podem desaparecer da referência.
• Resolver conflito mecanicamente: código compila, mas a regra fica duplicada.
• Fazer pull sem saber a estratégia: merges inesperados aparecem no histórico.
• Versionar credencial: apagar depois não invalida o segredo.
• Manter PR enorme: revisão demora e defeitos ficam difíceis de localizar.

Checklist de Git e GitHub

• Nome, e-mail e branch padrão estão configurados.
• git status e os dois tipos de diff são compreendidos.
• O .gitignore cobre segredos, dependências e arquivos gerados.
• Cada tarefa usa uma branch curta e descritiva.
• Commits possuem escopo lógico e mensagem clara.
• O remoto e a branch de acompanhamento foram confirmados.
• SSH ou outro método seguro está configurado sem expor credenciais.
• Pull requests explicam contexto, testes, risco e escopo.
• Branches importantes exigem as verificações adequadas.
• Conflitos são resolvidos com revisão e testes.
• Restore, revert e reset são escolhidos conforme o estado da mudança.
• Force push, quando indispensável, usa --force-with-lease e coordenação.

Perguntas frequentes

Git precisa do GitHub para funcionar?

Não. Git funciona localmente e pode sincronizar com diferentes servidores. GitHub é uma plataforma de hospedagem e colaboração construída em torno de repositórios Git.

Qual é a diferença entre git pull e git fetch?

git fetch atualiza referências do remoto sem alterar sua branch. git pull faz fetch e integra o resultado. Use fetch quando quiser inspecionar antes de combinar.

Qual é a diferença entre commit e push?

Commit registra uma versão no repositório local. Push envia commits para o remoto. Você pode criar vários commits offline e publicá-los depois.

Apaguei um arquivo. O Git consegue recuperá-lo?

Se o arquivo era rastreado, geralmente sim. Antes do commit, git restore caminho pode recuperá-lo do index. Depois, é possível restaurar a partir de outro commit. Arquivos nunca versionados não estão no histórico do Git.

Conclusão: aprenda pelo fluxo, não pela lista de comandos

Dominar Git e GitHub começa por entender o caminho da mudança: diretório de trabalho, staging, commit local, branch remota e pull request.

Status e diff mostram onde você está; add e commit registram a intenção; branch e PR organizam colaboração; restore, revert e reset resolvem problemas diferentes.

Pratique em um repositório descartável até conseguir explicar cada etapa. Depois, adicione revisão, testes e proteção de branch ao projeto real.

Quando você entende o estado antes de executar o comando, o Git deixa de ser uma sequência de tentativas e se torna uma ferramenta previsível para trabalhar sozinho ou em equipe.