Git guarda a história do seu código no seu computador, e o GitHub hospeda essa história na internet para você mostrar e compartilhar. É o quinto artigo da trilha "Quero virar dev em casa", e ele resolve um problema que todo iniciante tem: a pasta cheia de projeto-final, projeto-final2 e projeto-final-agora-vai. No fim, você terá a lista de tarefas do artigo anterior publicada em um repositório organizado, com README e um histórico limpo. Antes, veja JavaScript para iniciantes, que cria o projeto que vamos versionar.

Para quem é este artigo

Para quem já tem pelo menos um projeto no computador e quer guardá-lo, publicá-lo e mostrá-lo. Pré-requisito: um terminal (o Terminal do macOS, o do Linux ou o Git Bash no Windows) e uma conta no GitHub. Tempo de estudo sugerido: de 4 a 8 horas, entre leitura, vídeos e prática (estimativa da Redação).

O que você vai aprender

  1. A diferença entre Git e GitHub.
  2. Instalar e configurar o Git.
  3. Os comandos essenciais, com saídas reais.
  4. Como escrever bons commits e ignorar arquivos.
  5. Branches, merge e como resolver um conflito.
  6. O fluxo de pull request e como montar o portfólio.

Git e GitHub não são a mesma coisa

Segundo o GitHub, Git é um sistema de controle de versão que rastreia mudanças em arquivos e roda no seu computador. O GitHub é uma plataforma construída sobre o Git: hospeda seus repositórios na nuvem e acrescenta ferramentas de colaboração, como as issues e os pull requests. Em resumo, o Git gerencia a história do código, e o GitHub a hospeda online.

Como o Git pensa: instantâneos e três estados

O livro Pro Git explica três ideias que tornam tudo mais simples:

  • Instantâneos, não diferenças. O Git "tira uma foto" de como todos os seus arquivos estão naquele momento e guarda uma referência a ela.
  • Quase tudo é local. Você tem a história inteira no seu disco, então a maioria das operações é quase instantânea.
  • Integridade. Tudo é verificado por um código de verificação (um hash SHA-1) antes de ser guardado.

Cada arquivo está em um de três estados: modificado (você mudou, mas ainda não registrou), preparado (staged: marcado para entrar no próximo commit) e confirmado (committed: guardado com segurança no banco de dados local). Eles correspondem a três áreas: a árvore de trabalho (a pasta onde você edita), a área de preparação (a lista do que entrará no próximo commit) e o diretório Git (onde ficam a história e os metadados).

Instalar e configurar

  1. Instale o Git, baixando a versão mais recente em git-scm.com.
  2. Diga quem você é. O Git usa seu nome e seu e-mail para identificar cada commit:
git config --global user.name "Seu Nome"
git config --global user.email "seu-email@exemplo.com"
git config --global user.name

A última linha confere o nome configurado. O GitHub explica que o nome do commit é separado do seu nome de usuário e que commits antigos mantêm o nome original.

Privacidade (da Redação): em repositórios públicos, trate o nome e o e-mail dos seus commits como informação pública. O GitHub oferece um endereço de e-mail "noreply" (sem resposta) para você usar no lugar do seu e-mail real: em Settings > Emails, ative Keep my email addresses private. Siga o guia oficial para ver o endereço exato. A página do GitHub não informa se o e-mail do commit é publicamente visível, então o jeito seguro é assumir que sim.

  1. Autenticação com o GitHub. O GitHub recomenda autenticar por HTTPS, com um assistente que guarda suas credenciais, ou por SSH, e também permite usar o GitHub CLI (gh auth login). A Redação não testou essa etapa; siga os guias oficiais que a página "Set up Git" indica.

Os comandos essenciais, com saídas reais

A Redação rodou a sequência abaixo com o Git 2.54, em um repositório de teste. As saídas são as reais.

Criar o repositório e fazer o primeiro commit

git init -b main meu-curriculo
cd meu-curriculo
git status -s

Saída do status, com os arquivos do projeto ainda sem acompanhamento (untracked):

?? tarefas.css
?? tarefas.html
?? tarefas.js

git add tarefas.html tarefas.css tarefas.js
git status -s
git commit -m "Adiciona lista de tarefas"
git log --oneline

A  tarefas.css
A  tarefas.html
A  tarefas.js
9e61219 Adiciona lista de tarefas

O que aconteceu: git add coloca o conteúdo na área de preparação (o Pro Git resume como "adicione exatamente este conteúdo ao próximo commit", e não "adicione este arquivo ao projeto"), e git commit guarda o instantâneo. O A na primeira coluna do status indica que o arquivo foi preparado. O código 9e61219 é o início do hash do commit.

Se você editar um arquivo depois de prepará-lo, precisa rodar git add de novo para preparar a versão mais recente. E git diff mostra o que mudou e ainda não foi preparado (git diff --staged mostra o que já foi preparado).

README e .gitignore

Crie um README.md (veja a seção sobre README, mais adiante) e um arquivo .gitignore com os padrões do que o Git não deve acompanhar:

.DS_Store
node_modules/

Regras do Pro Git: linhas em branco e linhas que começam com # são ignoradas; um / no fim indica um diretório; um ! no começo nega um padrão. No teste, havia um arquivo .DS_Store na pasta e ele não apareceu no git status, como esperado.

Regra de ouro (da Redação): nunca faça commit de senhas, chaves de API ou arquivos como .env. Coloque-os no .gitignore antes do primeiro commit: o que entra no histórico é difícil de apagar de verdade.

Branches: trabalhar sem estragar o que funciona

Uma branch é uma linha separada de trabalho. Segundo o GitHub, uma nova branch começa como cópia da main, e você experimenta sem mexer no código principal até decidir juntá-lo. O Pro Git usa git checkout -b; o git switch -c faz o mesmo nas versões novas do Git, e a Redação testou os dois.

git checkout -b filtro-prioridade
git commit -am "Estilo da prioridade"
git checkout main
git merge filtro-prioridade
git branch -d filtro-prioridade

Saída do merge:

Updating 8904a6c..4f52550
Fast-forward
 tarefas.css | 1 +
 1 file changed, 1 insertion(+)

O Pro Git explica o "avanço rápido" (fast-forward): se a main não teve commits novos desde que você criou a branch, o Git só move o ponteiro para frente. O branch -d apaga a branch já incorporada. Atenção: o commit -a prepara todos os arquivos já acompanhados e modificados, e o livro avisa que isso pode incluir mudanças que você não queria.

Conflito de merge: o susto que não é um susto

Um conflito acontece quando você mudou o mesmo trecho do mesmo arquivo de duas formas diferentes em branches diferentes. A Redação provocou um de propósito: mudou o título do README.md em duas branches.

Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

O git status -s mostrou UU README.md (os dois lados modificaram), e o arquivo ficou assim:

<<<<<<< HEAD
# Lista de tarefas em JavaScript
=======
# Minha lista de tarefas
>>>>>>> titulo-novo

Como resolver, conforme o Pro Git:

  1. Edite o arquivo deixando o conteúdo que você quer e apagando as linhas <<<<<<<, ======= e >>>>>>>.
  2. git add README.md, o que marca o conflito como resolvido.
  3. git commit para concluir o merge.

A história resultante é a da imagem desta matéria: duas linhas que se separam e se juntam em um commit de merge. O conflito não é erro seu: é o Git pedindo que um humano decida qual versão vale.

Enviar para o GitHub

Crie um repositório vazio no GitHub, copie o endereço dele e conecte:

git remote add origin ENDERECO-DO-REPOSITORIO
git push -u origin main

No teste, com um repositório remoto simulado em disco, a saída foi * [new branch] main -> main e branch 'main' set up to track 'origin/main'. Com o GitHub de verdade, você precisa estar autenticado (veja a seção de configuração).

Como escrever bons commits (da Redação)

  • Um assunto por commit. Se a mensagem precisa de "e", talvez sejam dois commits.
  • Mensagem no imperativo, curta e específica: "Adiciona filtro de tarefas pendentes", e não "mudanças" nem "ajustes".
  • Commit pequeno e frequente. É mais fácil de entender e de desfazer.
  • Não faça commit de código quebrado na main quando puder evitá-lo; use uma branch.
  • Releia o git status antes do commit. Veja o que está prestes a entrar.

Mensagens ruins: final, arrumei, asdf. Mensagens boas: Corrige id repetido ao remover tarefa, Adiciona README com instruções.

O fluxo do GitHub: branch, commit e pull request

Segundo o guia "Hello World" do GitHub, o fluxo pela interface web é:

  1. Crie um repositório, com um README.
  2. Crie uma branch (por exemplo, readme-edits) a partir da main.
  3. Faça e confirme mudanças na nova branch, com uma mensagem descritiva.
  4. Abra um pull request, uma proposta de juntar uma branch em outra, que mostra as diferenças para que outras pessoas revisem e discutam antes.
  5. Faça o merge e, se quiser, apague a branch.

Mesmo trabalhando sozinho, vale usar branch e pull request: você pratica o fluxo que as equipes usam e deixa um histórico legível.

README e portfólio

O GitHub diz que o README serve para "comunicar informações importantes sobre o seu projeto" e costuma ser o primeiro lugar que o visitante olha. Segundo a página, um bom README costuma dizer o que o projeto faz, por que é útil, como começar, onde pedir ajuda e quem o mantém. O GitHub o exibe automaticamente na página do repositório.

Modelo de README para a lista de tarefas (da Redação):

# Lista de tarefas

Pequeno app em JavaScript puro para adicionar, concluir, remover e filtrar tarefas.
Os dados ficam salvos no navegador (localStorage).

## Demonstração
https://seu-usuario.github.io/lista-de-tarefas/

## Como usar
Abra `tarefas.html` por um servidor local (por exemplo, `python3 -m http.server`).

## O que aprendi
DOM, eventos e armazenamento no navegador.

Um README de perfil: o GitHub informa que um README em um repositório público com o mesmo nome do seu usuário aparece no seu perfil. É um bom cartão de visita.

Portfólio, na prática (da Redação):

  • Destaque no seu perfil poucos projetos terminados e explicados, em vez de muitos pela metade.
  • Cada projeto: README, link para a demonstração (GitHub Pages, como no artigo 3) e uma captura de tela ou GIF.
  • Mostre a evolução: commits claros e frequentes contam mais do que um projeto enorme com um commit só.

Vídeos para estudar

Os quatro vídeos foram verificados quanto ao título, ao canal, à duração, à data e à possibilidade de incorporação. A Redação não os assistiu na íntegra nem verificou o que dizem.

Em português, com cerca de 46 minutos, publicado em 24 de janeiro de 2024. Minicurso sobre o funcionamento do Git. Nível: iniciante.
Vídeo: Código Fonte TV
Em português, com cerca de 37 minutos, publicado em 25 de agosto de 2023. Explica o que são Git e GitHub e como usá-los. A descrição divulga uma newsletter e um certificado pago. Nível: iniciante.
Vídeo: Fernanda Kipper
Em português, com cerca de 5 minutos, publicado em 19 de julho de 2023. Visão geral rápida. A descrição afirma que Git é requisito de 99% das vagas de tecnologia; é um número do criador, que a Redação não verificou. Nível: iniciante.
Vídeo: Igor Mucharski
Em inglês, com cerca de 1 hora e 8 minutos, publicado em 28 de maio de 2020. Curso introdutório e prático. Nível: iniciante.
Vídeo: freeCodeCamp.org

Exercícios práticos

  1. Seu primeiro repositório: crie uma pasta, rode git init, faça três commits com mensagens claras e confira com git log --oneline.
  2. Ignore algo: crie um arquivo .env de mentira, coloque-o no .gitignore e confirme que ele não aparece no git status.
  3. Branch e merge: crie uma branch, mude um arquivo, volte para a main e faça o merge.
  4. Provoque um conflito de propósito, resolva e leia o histórico com git log --oneline --graph.
  5. Pull request solitário: no GitHub, abra um pull request de uma branch sua para a main e faça o merge.
  6. Desfazer com calma: descubra, na documentação, a diferença entre git restore e git revert, e teste uma vez em um repositório de treino.

Mini-projeto: publique a lista de tarefas

Publique a lista de tarefas do artigo anterior no GitHub com:

  • Repositório organizado (tarefas.html, tarefas.css, tarefas.js, README.md, .gitignore).
  • README com o que o projeto faz, como usar e uma captura de tela ou GIF.
  • Link para a demonstração no GitHub Pages.
  • Commits claros e progressivos (pelo menos cinco).

Resultado esperado: um repositório que um recrutador consiga entender em dois minutos.

Erros comuns de iniciantes

  • Fazer commit de tudo de uma vez, com mensagem "final".
  • Esquecer o git add e achar que o commit guardou a mudança.
  • Fazer commit de senhas ou do .env.
  • Trabalhar direto na main quando uma branch seria mais segura.
  • Ter medo de conflito. Ele é normal e se resolve em três passos.
  • Usar git commit -a sem olhar o que está sendo incluído.
  • Não escrever README. Sem ele, ninguém entende seu projeto.
  • Copiar comando sem entender. Rode git status com frequência: ele diz onde você está.

Checklist de conclusão

  • Configurei meu nome e meu e-mail no Git, e escolhi o que fazer com a privacidade do e-mail.
  • Fiz commits com mensagens claras em um repositório meu.
  • Usei .gitignore e nunca fiz commit de segredos.
  • Criei uma branch, fiz merge e resolvi um conflito de treino.
  • Abri um pull request e fiz o merge no GitHub.
  • Escrevi um README para a lista de tarefas.
  • Publiquei o projeto e o link da demonstração funciona.

Próximo passo da trilha

Com o Git na mão, o próximo artigo ajuda você a sair dos tutoriais e criar um projeto seu, do começo ao fim, com o seu repositório como vitrine.

Perguntas frequentes

Qual a diferença entre Git e GitHub?

Segundo o GitHub, o Git é um sistema de controle de versão que roda no seu computador e rastreia mudanças. O GitHub é uma plataforma que hospeda repositórios Git na nuvem e acrescenta ferramentas de colaboração, como pull requests.

O que é um commit?

Segundo o GitHub, é um conjunto salvo de mudanças, com uma mensagem que explica o que mudou e por quê.

O que é uma branch?

É uma versão separada do repositório. Segundo o GitHub, uma nova branch começa como cópia da main, e você experimenta sem alterar o código principal até fazer o merge.

O que é um pull request?

Segundo o GitHub, é uma proposta de juntar uma branch em outra, que mostra as diferenças para que outras pessoas revisem e discutam antes.

O que é um conflito de merge e como resolver?

Acontece quando o mesmo trecho do mesmo arquivo foi mudado de formas diferentes em duas branches. Segundo o Pro Git, você edita o arquivo removendo os marcadores, roda git add no arquivo e conclui com git commit.

Preciso saber Git para conseguir emprego?

A Redação não encontrou fonte oficial que dê um número de vagas que exigem Git, e por isso não o cita. Em geral, saber usar controle de versão é considerado uma habilidade básica de quem programa, e um repositório bem organizado ajuda a mostrar seu trabalho. Esta é uma observação da Redação.

Como evitar subir senhas para o GitHub?

Coloque arquivos como .env no .gitignore antes do primeiro commit e nunca escreva chaves direto no código. Esta é uma recomendação da Redação.

O e-mail dos meus commits fica público?

A página do GitHub não informa isso. Em repositórios públicos, assuma que sim e considere usar o endereço de e-mail "noreply" que o GitHub oferece em Settings > Emails.

Fontes