Git sem decoreba: a colinha completa do vídeo

Você comentou GIT e aqui está a colinha prometida, só que do jeito que eu queria ter recebido quando comecei: cada comando do vídeo com o que ele faz, o que aparece na tela quando você roda e o que fazer quando dá errado. Se você nunca abriu um terminal, comece pelo meu guia GitHub do zero e volte pra cá depois. Se você só quer a colinha, ela é a primeira tabela aqui embaixo.

A colinha (pra quem tem pressa)

Comando	O que faz	Quando você usa
git init	Transforma a pasta num repositório Git	Uma vez, no começo do projeto
git status	Mostra o que mudou e em que área está	O tempo todo, antes de qualquer outro
git add arquivo	Leva a mudança pra área de staging	Antes de cada commit
git add .	Leva todas as mudanças da pasta pro staging	Quando tudo que mudou faz parte da mesma entrega
git commit -m "mensagem"	Tira a "foto" do que está no staging	Sempre que terminar uma etapa que faz sentido sozinha
git log --oneline	Lista o histórico, um commit por linha	Pra ver o que já foi feito
git diff	Mostra linha por linha o que mudou	Antes do git add, pra conferir
git switch -c nome	Cria uma branch e já entra nela	Ao começar uma funcionalidade nova
git switch main	Volta pra branch principal	Antes de juntar o trabalho
git merge nome	Junta a branch nome na branch em que você está	Quando a funcionalidade está pronta
git remote add origin URL	Liga sua pasta a um repositório no GitHub	Uma vez por projeto
git push	Envia seus commits pro GitHub	Depois de commitar
git pull	Baixa os commits novos do GitHub e junta nos seus	Antes de começar a trabalhar
git clone URL	Baixa um repositório inteiro, com o histórico	Pra pegar um projeto que já existe
git restore arquivo	Descarta a mudança que você ainda não commitou	Quando a edição ficou ruim
git revert HASH	Cria um commit novo que desfaz um antigo	Pra desfazer algo que já foi enviado
git reset	Move a branch pra trás	Só no que ainda não foi enviado, e com cuidado

O fluxo de todo dia cabe em uma linha:

editar  →  git add  →  git commit  →  git push

E em equipe, um git pull antes de tudo.

O mapa: uma mudança precisa subir quatro andares

Guarda este desenho. Todo comando do Git que você vai usar no dia a dia move alguma coisa entre esses andares.

 4º andar   REMOTO (GitHub)            cópia na internet, o time enxerga
               ▲            │
           git push      git pull
               │            ▼
 3º andar   REPOSITÓRIO (pasta .git)   histórico permanente na sua máquina
               ▲
           git commit
               │
 2º andar   STAGING                    o que vai entrar na próxima foto
               ▲
           git add
               │
 1º andar   PASTA DE TRABALHO          os arquivos que você está editando

O Ctrl+S do seu editor salva o arquivo no 1º andar. O Git só passa a guardar aquilo quando você sobe os andares na mão. Parece burocracia, mas é o que te dá controle sobre o que entra no histórico.

Parte 1: Git e GitHub não são a mesma coisa

Pensa numa câmera e num álbum online. A câmera tira as fotos e guarda no cartão de memória. O álbum online é um site onde você sobe as fotos pra outras pessoas verem. Dá pra ter a câmera sem o álbum, mas o álbum sem câmera não serve pra nada.

	Git	GitHub
O que é	Um programa de controle de versão	Um site que hospeda repositórios Git
Onde roda	Na sua máquina	Na internet
Precisa de internet	Não	Sim
Precisa de conta	Não	Sim, pra enviar código
Quem fez	Linus Torvalds e a comunidade do Linux, em 2005	Uma empresa, hoje da Microsoft
Dá pra trocar	Na prática, é o padrão	Sim: GitLab, Bitbucket e Codeberg fazem o mesmo papel

Controle de versão é o nome técnico pra uma ideia simples: guardar cada versão do seu projeto, saber quem mudou o quê e poder voltar pra qualquer ponto. É o fim da pasta com trabalho-final.docx, trabalho-final-2.docx e trabalho-final-agora-vai.docx.

A história por trás

O Git nasceu de uma briga. O kernel do Linux usava uma ferramenta paga chamada BitKeeper, que era liberada de graça pro projeto. Em 2005 essa gratuidade acabou, e Linus Torvalds, o criador do Linux, decidiu escrever a própria ferramenta. As metas eram velocidade, design simples, suporte forte a milhares de branches em paralelo e ser totalmente distribuído, ou seja, cada pessoa tem o histórico completo na própria máquina. É por isso que o Git funciona sem internet e por isso branch nele é tão barata.

Parte 2: antes do primeiro comando

Instalar

Baixe em git-scm.com. No Windows é um instalador comum, e pode ir de "Next" em tudo. No Mac, digitar git no Terminal já oferece a instalação. No Linux, vem no gerenciador de pacotes (sudo apt install git no Ubuntu).

Pra conferir, abra o terminal e rode:

git --version

Se aparecer algo como git version 2.43.0, está instalado. Qualquer versão a partir da 2.28 serve pra tudo que está nesta página.

Se apresentar pro Git

Todo commit leva o nome e o e-mail de quem fez. Você configura isso uma vez só por computador:

git config --global user.name "Seu Nome"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main

A terceira linha faz todo projeto novo começar com a branch chamada main, que é o nome que o GitHub usa. Sem ela, versões mais antigas do Git criam a branch como master e você perde tempo com nomes diferentes dos dois lados.

Dica: use no user.email o mesmo e-mail da sua conta do GitHub. É assim que o GitHub liga os commits ao seu perfil e pinta os quadradinhos verdes de contribuição.

Parte 3: git init, o começo de tudo

Entre na pasta do projeto pelo terminal e rode:

git init

Initialized empty Git repository in /projetos/meu-app/.git/

Esse comando cria uma pasta escondida chamada .git dentro do seu projeto. Todo o histórico mora lá dentro. Seus arquivos continuam exatamente onde estavam.

Três coisas que ninguém te conta:

• Você roda git init uma vez por projeto, nunca de novo.
• Se apagar a pasta .git, o histórico inteiro vai embora e sobram só os arquivos atuais.
• Nunca rode git init na sua pasta de usuário ou na Área de Trabalho inteira. O Git tentaria vigiar todos os seus arquivos.

As mensagens do Git aparecem em inglês na maioria das instalações. Vou mostrar a saída real e traduzir o que importa.

Parte 4: as três áreas

Essa é a parte que faz o resto fazer sentido. O Git não salva sozinho cada mudança. Uma mudança passa por três lugares:

Área	O que é	Analogia
Pasta de trabalho (working directory)	Os arquivos como estão agora no seu disco	A bagunça em cima da mesa
Staging (também chamada de index)	A lista do que vai entrar no próximo commit	Quem você chamou pra posar na foto
Repositório	O histórico de commits, dentro da pasta .git	O álbum, com as fotos já reveladas

O diagrama oficial do livro Pro Git. Da esquerda pra direita: pasta de trabalho, staging e a pasta .git. O git add leva pro meio ("Stage Fixes") e o git commit leva pra direita.

Por que existe o staging, se dava pra salvar tudo direto? Porque você raramente mexe numa coisa só. Imagina que você corrigiu um bug e, no mesmo embalo, começou uma tela nova que ainda está pela metade. Com o staging você manda só a correção pra foto e deixa a tela nova de fora. O histórico fica com um commit que faz uma coisa, e isso vale ouro na hora de procurar onde algo quebrou.

Parte 5: o ciclo básico, comando por comando

Vamos seguir o exemplo do vídeo. Você criou o arquivo app.js num projeto novo.

git status: onde eu estou?

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	app.js

nothing added to commit but untracked files present (use "git add" to track)

Traduzindo: você está na branch main, ainda não existe nenhum commit, e o app.js é um arquivo untracked, ou seja, o Git viu que ele existe mas ainda não está acompanhando. O próprio Git sugere o próximo comando entre parênteses. Ele faz isso quase sempre, então leia a saída.

O git status não muda nada, só mostra. Pode rodar quantas vezes quiser. Quem usa Git há dez anos ainda roda esse comando antes e depois de tudo.

Os estados que um arquivo pode ter:

O que aparece	Significa
Untracked files	Arquivo novo, o Git ainda não acompanha
Changes not staged for commit / modified em vermelho	Mudou, mas está só na pasta de trabalho
Changes to be committed em verde	Está no staging, pronto pra foto
nothing to commit, working tree clean	Tudo salvo no histórico, nada pendente

Os quatro estados de um arquivo, no diagrama do Pro Git: não rastreado (untracked), sem mudança (unmodified), modificado (modified) e no staging (staged). Depois do commit ele volta a ser "sem mudança" e o ciclo recomeça.

git add: escolher o que entra na foto

git add app.js

Não aparece nada na tela, e isso é normal. Rode git status de novo:

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   app.js

O arquivo subiu pro staging. As variações que você vai usar:

Comando	O que adiciona
git add app.js	Só esse arquivo
git add app.js style.css	Os arquivos listados
git add src/	Tudo que mudou dentro da pasta src
git add .	Tudo que mudou na pasta atual e nas subpastas

Dica: o git add copia o arquivo como ele está naquele instante. Se você editar o arquivo de novo depois do add, a edição nova fica de fora. O git status vai mostrar o mesmo arquivo duas vezes, uma em verde e uma em vermelho. É só rodar git add outra vez.

git commit: tirar a foto

git commit -m "adiciona página de login"

[main (root-commit) e78bafc] adiciona página de login
 1 file changed, 1 insertion(+)
 create mode 100644 app.js

Pronto, existe um commit. Lendo a saída: main é a branch, e78bafc é o identificador do commit, depois vem a sua mensagem e um resumo do que mudou.

Um commit é uma foto do projeto inteiro naquele momento, com autor, data, mensagem e um ponteiro pro commit anterior. Essa corrente de commits, um apontando pro outro, é o histórico.

Cada coluna é um commit, ou seja, uma foto de todos os arquivos (A, B e C). Arquivo que não mudou não é copiado de novo: o Git só aponta pra versão que já tinha, e é isso que as caixas tracejadas mostram.

O identificador (chamado de hash) é um código de 40 caracteres calculado a partir do conteúdo do commit. O Git mostra só os 7 primeiros porque quase sempre isso basta pra identificar um commit sem confusão. Você usa esse código pra apontar pra um commit específico em comandos como git revert.

O -m vem de message. Se você esquecer o -m, o Git abre um editor de texto no terminal esperando a mensagem. Se for o Vim e você travar lá dentro, digite :q! e aperte Enter pra sair sem salvar.

Como escrever uma boa mensagem de commit

A mensagem responde "o que este commit faz?". Daqui a seis meses você vai ler isso tentando lembrar por que mexeu ali.

Ruim	Boa
ajustes	corrige cálculo de frete para CEP do Norte
mudanças	adiciona botão de sair no menu
agora vai	remove chamada duplicada à API de login
asdf	atualiza texto da página inicial

Comece com um verbo, fale de uma coisa só e seja específico. Muitos times usam o padrão Conventional Commits, que coloca um tipo na frente: feat: adiciona login com Google, fix: corrige erro ao salvar perfil.

git diff: ver exatamente o que mudou

Antes de adicionar, dá pra conferir linha por linha:

git diff

--- a/app.js
+++ b/app.js
@@ -1 +1,2 @@
 console.log('oi')
+// login

Linha com + na frente foi adicionada. Linha com - foi removida. O git diff mostra o que ainda não foi pro staging. Pra ver o que já está no staging, use git diff --staged. Se a saída for longa, aperte q pra sair.

.gitignore: o que nunca deve entrar

Alguns arquivos não devem ir pro histórico: senhas, chaves de API, pastas enormes de dependências, arquivos gerados automaticamente. Crie um arquivo chamado .gitignore na raiz do projeto e liste o que o Git deve ignorar:

node_modules/
.env
*.log
dist/

Depois faça o commit do próprio .gitignore. O GitHub mantém uma coleção de modelos prontos por linguagem em github/gitignore.

Dica: se você commitar uma senha ou chave de API e enviar pro GitHub, apagar o arquivo no commit seguinte não resolve, porque ela continua no histórico. Considere a chave vazada e gere outra no serviço. Crie o .gitignore antes do primeiro commit e você nunca passa por isso.

Parte 6: git log, o histórico

git log

commit e098f1e7566caac94262212490674c9789cb5ca4
Author: Helio <[email protected]>
Date:   Wed Oct 7 07:59:11 2026 -0300

    adiciona gitignore

Cada bloco é um commit: hash completo, autor, data e mensagem, do mais novo pro mais antigo. Aperte q pra sair.

As versões que você vai usar de verdade:

Comando	O que mostra
git log --oneline	Um commit por linha, só hash curto e mensagem
git log --oneline --graph --all	O mesmo, com o desenho das branches
git log -5	Só os 5 últimos
git log app.js	Só os commits que mexeram nesse arquivo
git show e78bafc	Tudo que aquele commit mudou

git log --oneline

d36d53a adiciona comentario
e78bafc adiciona página de login

Parte 7: branches, a linha do tempo paralela

Você quer criar uma funcionalidade nova sem arriscar o código que já funciona. Uma branch é uma linha de desenvolvimento separada. Pensa num "salvar como" que não duplica os arquivos e que depois sabe juntar tudo de volta.

Por dentro, uma branch é só uma etiqueta apontando pra um commit. Por isso criar branch no Git é instantâneo e não ocupa espaço, mesmo num projeto gigante.

No diagrama do Pro Git, master e testing são duas etiquetas no mesmo commit. O livro usa master, o nome antigo da branch principal. Leia como main.

git switch -c nova-feature

Switched to a new branch 'nova-feature'

O -c vem de create: cria a branch e já entra nela. A partir de agora, todo commit que você fizer vai pra nova-feature. A main fica parada, intacta.

main           A───B
                    \
nova-feature         C───D     ← seus commits novos entram aqui

Os comandos de branch:

Comando	O que faz
git branch	Lista as branches, com um * na que você está
git switch -c nome	Cria e entra
git switch nome	Entra numa branch que já existe
git switch -	Volta pra branch anterior
git branch -d nome	Apaga a branch (depois do merge)

Ao trocar de branch, os arquivos da sua pasta mudam na hora pra refletir aquela linha do tempo. Não se assuste se um arquivo "sumir": ele está guardado na outra branch.

Dica: em tutorial mais antigo você vai ver git checkout -b nome e git checkout nome. Fazem a mesma coisa. O git switch chegou na versão 2.23 do Git, em 2019, justamente porque o checkout fazia coisas demais e confundia todo mundo.

Parte 8: git merge e o temido conflito

A funcionalidade ficou pronta. Hora de juntar na principal. Primeiro você vai pra branch que vai receber as mudanças, depois chama o merge:

git switch main
git merge nova-feature

main           A───B───────M     ← M junta as duas histórias
                    \     /
nova-feature         C───D

O commit C6 é o commit de merge: ele tem dois pais, um de cada branch. No exemplo do livro a branch se chama iss53 e a principal, master.

Na maioria das vezes o Git resolve sozinho, porque as duas branches mexeram em arquivos ou trechos diferentes.

Quando dá conflito

O conflito acontece quando as duas branches mudaram a mesma linha do mesmo arquivo. O Git não tem como adivinhar qual versão você quer e te devolve a decisão:

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

Não quebrou nada. O Git parou no meio do merge e está esperando você. Ao abrir o app.js, você encontra isto:

<<<<<<< HEAD
console.log("oi da main")
=======
console.log("oi da feature")
>>>>>>> nova-feature
// login

Como ler os marcadores:

Trecho	Significa
Entre <<<<<<< HEAD e =======	A versão da branch em que você está (main)
Entre ======= e >>>>>>> nova-feature	A versão que está chegando
Fora dos marcadores	Sem conflito, o Git já resolveu

Resolvendo, passo a passo

1. Rode git status pra ver quais arquivos estão em conflito (aparecem como both modified).
2. Abra cada arquivo e decida como o trecho deve ficar: uma versão, a outra, ou uma mistura das duas.
3. Apague as três linhas de marcadores (<<<<<<<, =======, >>>>>>>). O arquivo tem que ficar como código normal.
4. Rode git add app.js pra avisar que aquele arquivo está resolvido.
5. Rode git commit -m "resolve conflito da saudação" pra concluir o merge.

Depois disso o histórico fica assim:

*   3cb3396 resolve conflito da saudacao
|\
| * 770d822 muda saudacao na feature
* | aa4ca0d muda saudacao na main
|/
* d36d53a adiciona comentario
* e78bafc adiciona página de login

Dica: se você se perdeu no meio do conflito, git merge --abort cancela o merge e deixa tudo como estava antes. Dá pra respirar e tentar de novo. E o VS Code mostra botões em cima de cada conflito ("Accept Current", "Accept Incoming", "Accept Both") que fazem o passo 2 e o 3 com um clique.

Parte 9: colocando o GitHub na história

Até aqui tudo aconteceu na sua máquina. O GitHub entra como o 4º andar: uma cópia do repositório na internet, que serve de backup e de ponto de encontro do time.

Conectar um projeto local ao GitHub

1. No GitHub, clique em New repository, dê um nome e crie. Deixe desmarcadas as opções de adicionar README, .gitignore e licença, porque seu projeto já existe na sua máquina.
2. Copie a URL que o GitHub mostra, parecida com https://github.com/seu-usuario/meu-app.git.
3. No terminal, dentro da pasta do projeto:

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

Um remote é um apelido pra uma URL. origin é só o nome que todo mundo usa por costume pro remote principal. Pra conferir pra onde ele aponta:

git remote -v

origin	https://github.com/seu-usuario/meu-app.git (fetch)
origin	https://github.com/seu-usuario/meu-app.git (push)

git push: enviar

O git push sobe pro GitHub os commits que só existem na sua máquina. Só vai o que foi commitado: mudança parada na pasta de trabalho ou no staging não sobe.

Na primeira vez de cada branch, use git push -u origin main. O -u grava que a sua main local acompanha a main do origin. Dali em diante basta git push.

Se você rodar git push puro antes disso, o Git reclama e já te diz o comando certo:

fatal: The current branch main has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin main

--set-upstream é o nome completo do -u.

Login: a senha da conta não funciona aqui

O GitHub deixou de aceitar a senha da conta em operações do Git em 2021. No Windows, o instalador do Git já traz o Git Credential Manager: no primeiro git push ele abre o navegador, você faz login e ele guarda a autorização. Em qualquer sistema, outra saída é instalar a GitHub CLI e rodar gh auth login. Quem prefere SSH gera uma chave por computador e cadastra no GitHub. O passo a passo oficial está em Configurar o Git.

git pull: buscar

git pull

O git pull faz duas coisas em sequência: baixa os commits novos do remoto e junta na sua branch atual. Se alguém do time enviou trabalho, é assim que ele chega até você.

Por baixo, o pull é um git fetch (só baixa, não mexe nos seus arquivos) seguido de uma integração (merge, por padrão). Se quiser olhar antes de juntar, rode git fetch e depois git status: ele diz quantos commits você está atrás.

git clone: pegar um projeto que já existe

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

Cria uma pasta com o nome do projeto e traz tudo: arquivos, histórico completo e o remote origin já configurado. Depois de um clone você não precisa de git init nem de git remote add.

Situação	Comando
Projeto novo, começando na sua máquina	git init
Projeto que já existe no GitHub	git clone

Por que git pull antes de git push

Se alguém enviou commits enquanto você trabalhava, o GitHub recusa o seu push:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com/seu-usuario/meu-app.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally.

O remoto tem trabalho que você ainda não tem, e o Git se recusa a passar por cima do trabalho dos outros. A solução é git pull, resolver conflito se houver, e git push de novo.

Dica: se o git pull responder Need to specify how to reconcile divergent branches, o Git está perguntando como juntar duas histórias que andaram em paralelo. Rode git config --global pull.rebase false uma vez. Isso define o merge como padrão, e a pergunta não volta mais.

E o tal do pull request?

Pull request (PR) é um recurso do GitHub, não um comando do Git. Em vez de fazer o merge direto na main, você envia sua branch pro GitHub e abre um pedido: "quero juntar isso, alguém revisa?". O time comenta, pede ajustes, aprova, e o merge acontece pelo site. É assim que times e projetos open source trabalham.

git switch -c corrige-menu
# edita, git add, git commit
git push -u origin corrige-menu

Depois disso o GitHub mostra um botão Compare & pull request na página do repositório.

Parte 10: quebrei alguma coisa, e agora?

O Git tem várias formas de voltar atrás. A escolha depende de onde a mudança está.

Situação	Comando	Apaga trabalho?
Editei um arquivo e quero jogar a edição fora	git restore arquivo	Sim, a edição não commitada
Dei git add sem querer	git restore --staged arquivo	Não, só tira do staging
Errei a mensagem do último commit	git commit --amend -m "mensagem certa"	Não
Um commit antigo causou um bug e já foi enviado	git revert HASH	Não, cria um commit novo
Quero desfazer commits que ainda estão só na minha máquina	git reset	Depende do modo
Fiz besteira e não sei onde meu commit foi parar	git reflog	Não, ele te salva

git restore: descartar mudanças

git restore app.js

O arquivo volta a ser como estava no último commit. Cuidado: a edição descartada nunca foi commitada, então o Git não tem cópia dela. Não tem como recuperar.

Com --staged, o comando só tira o arquivo do staging e mantém a sua edição na pasta:

git restore --staged app.js

git revert: desfazer com um commit novo

git revert 48767ff

[main 83a0250] Revert "adiciona linha c com bug"
 1 file changed, 1 deletion(-)

O revert olha o que aquele commit fez e cria um commit novo fazendo o contrário. O commit com problema continua no histórico, e nada é apagado:

83a0250 Revert "adiciona linha c com bug"
48767ff adiciona linha c com bug
c6a2e69 adiciona linha b

Por isso ele é o jeito seguro de desfazer algo que já foi pro GitHub: ninguém do time perde nada, e fica registrado que aquilo foi desfeito.

git reset: mover a branch pra trás

O reset puxa a etiqueta da branch pra um commit anterior. Os commits que ficaram "na frente" saem do histórico da branch. O que acontece com as mudanças deles depende do modo:

Comando	O histórico volta	As mudanças ficam
git reset --soft HEAD~1	1 commit	No staging, prontas pra commitar de novo
git reset HEAD~1	1 commit	Na pasta de trabalho, fora do staging
git reset --hard HEAD~1	1 commit	Em lugar nenhum. São apagadas

HEAD é o commit em que você está agora. HEAD~1 é "um commit antes". HEAD~3 é "três antes".

Duas regras que evitam quase todo desastre:

• --hard apaga também as mudanças que você ainda não commitou. Rode git status antes.
• Não use reset em commits que você já enviou. Você reescreve a história na sua máquina, o GitHub continua com a antiga, e o próximo push é recusado. Pra commit já enviado, use git revert.

	revert	reset
Como desfaz	Commit novo com o inverso	Move a branch pra trás
Apaga histórico	Não	Sim, na branch
Seguro em commit já enviado	Sim	Não
Bom pra	Trabalho compartilhado	Arrumar a casa antes de enviar

git reflog: a rede de segurança

O Git anota todo lugar por onde a sua branch passou, inclusive depois de um reset --hard:

git reflog

5ec2ba0 HEAD@{0}: reset: moving to HEAD~1
c6a2e69 HEAD@{1}: reset: moving to HEAD~1
48767ff HEAD@{2}: reset: moving to HEAD~1

Achou o ponto em que estava tudo certo? Volta pra ele:

git reset --hard c6a2e69

Commit feito é muito difícil de perder de verdade. O que se perde é o que nunca foi commitado. Por isso o conselho mais útil desta página é: commite cedo e commite sempre.

git stash: guardar pra depois

Você está no meio de uma mudança, ainda não quer commitar, e precisa trocar de branch agora. O stash guarda tudo numa gaveta e limpa a pasta:

git stash        # guarda
git stash pop    # devolve

Parte 11: o fluxo do dia a dia

Sozinho

git status
git add .
git commit -m "descreve o que você fez"
git push

Em equipe

git switch main
git pull                          # 1. começa atualizado
git switch -c minha-tarefa        # 2. branch pra cada tarefa
# ... edita os arquivos ...
git add .
git commit -m "descreve o que você fez"
git push -u origin minha-tarefa   # 3. envia a branch
# 4. abre o pull request no GitHub

O Git tem centenas de comandos, e no fundo quase todos servem pra mesma coisa: construir um histórico limpo de como o seu código mudou. Com os desta página você cobre o dia a dia de um dev.

Parte 12: treino de 10 minutos

Ler não fixa. Abra o terminal e rode na ordem, lendo o que aparece depois de cada linha. É o roteiro do vídeo inteiro, e nada disso toca na internet.

mkdir treino-git
cd treino-git
git init
git branch -M main        # garante que a branch se chama main

echo "primeira linha" > notas.txt
git status
git add notas.txt
git status
git commit -m "cria arquivo de notas"

echo "segunda linha" >> notas.txt
git diff
git add .
git commit -m "adiciona segunda linha"
git log --oneline

git switch -c experimento
echo "linha do experimento" >> notas.txt
git add .
git commit -m "testa uma ideia"

git switch main
git merge experimento
git log --oneline --graph

echo "bagunça" >> notas.txt
git restore notas.txt
git status

No Windows, rode o treino no Git Bash, que vem junto com o instalador do Git. No Prompt de Comando e no PowerShell o echo grava o arquivo de um jeito diferente e a saída não bate com a daqui.

Quando terminar, pode apagar a pasta treino-git. Quer forçar um conflito de propósito? Mude a mesma linha do notas.txt na main e numa branch, faça commit nas duas e rode o merge.

Mensagens de erro que assustam (e o que elas querem dizer)

Mensagem	O que aconteceu	Como resolver
fatal: not a git repository	Você está numa pasta sem .git	Entre na pasta certa com cd, ou rode git init
Author identity unknown / Please tell me who you are	Faltou configurar nome e e-mail	Os dois git config --global da Parte 2
nothing to commit, working tree clean	Não há nada novo pra salvar	Não é erro. Está tudo commitado
nothing added to commit but untracked files present	Você esqueceu o git add	git add . e depois o commit
error: src refspec main does not match any	Tentou enviar uma branch que não existe, ou ainda sem commit	Faça o primeiro commit e confira o nome com git branch
fatal: remote origin already exists	O remote já estava configurado	Confira com git remote -v
! [rejected] ... (fetch first)	O GitHub tem commits que você não tem	git pull e depois git push
CONFLICT (content): Merge conflict in ...	Duas versões da mesma linha	O passo a passo da Parte 8
Your local changes would be overwritten	Tem mudança não commitada no caminho	Commite ou use git stash antes
detached HEAD	Você entrou num commit antigo, fora de qualquer branch	git switch main pra voltar
Authentication failed	Login recusado	Veja "Login" na Parte 9

Pra ir mais fundo

Livros e documentação

• Pro Git, em português: o livro oficial, gratuito, de Scott Chacon e Ben Straub. Os capítulos 2 e 3 cobrem tudo desta página com mais profundidade.
• O que é Git?: o trecho do Pro Git que explica as três áreas e por que o Git guarda fotos e não diferenças.
• Desfazendo coisas: o capítulo sobre voltar atrás, pra ler antes de precisar.
• Referência de comandos: o manual oficial de cada comando, com todas as opções.
• Guia de início rápido para repositórios: a documentação do GitHub, em português, pra criar seu primeiro repositório.
• Sobre pull requests: como funciona a revisão de código no GitHub.

Os diagramas desta página são do livro Pro Git, de Scott Chacon e Ben Straub, publicado sob a licença Creative Commons BY-NC-SA 3.0.

Pra praticar

• Learn Git Branching: um jogo no navegador em que você digita comandos e vê as branches se moverem. O melhor jeito de entender merge e reset.
• Folha de dicas de Git do GitHub: a colinha oficial em português, boa pra imprimir.

Pra quando der ruim

• Dangit, Git!?!: receitas curtas pra situações do tipo "commitei na branch errada", em português.

No Cofre

• GitHub do zero: como baixar e rodar os projetos que eu mostro, mesmo sem programar.
• Truques de URL do GitHub: atalhos escondidos na barra de endereço.
• Aprendendo Git: o livro que eu indico pra quem quer entender o Git por dentro.

Glossário rápido

Termo	Em português claro
Repositório (repo)	A pasta do projeto com todo o histórico dentro
Commit	Uma foto do projeto num momento, com autor, data e mensagem
Hash	O código único que identifica cada commit
Staging (index)	A lista do que vai entrar no próximo commit
Branch	Uma linha de desenvolvimento paralela
main	O nome padrão da branch principal
HEAD	O ponto do histórico em que você está agora
Merge	Juntar duas branches
Conflito	Duas branches mudaram a mesma linha e o Git pede sua decisão
Remote	Uma cópia do repositório em outro lugar, como o GitHub
origin	O apelido padrão do remote principal
Upstream	A branch remota que a sua branch local acompanha
Clone	Baixar um repositório inteiro, com histórico
Push / Pull	Enviar seus commits / buscar os commits dos outros
Fetch	Baixar os commits sem juntar nos seus
Pull request (PR)	Pedido no GitHub pra juntar uma branch, com revisão
Fork	Uma cópia de um repositório de outra pessoa na sua conta do GitHub
.gitignore	Arquivo com a lista do que o Git deve ignorar
Stash	Gaveta temporária pra mudanças não commitadas
Untracked	Arquivo novo que o Git ainda não acompanha

Salva esta página nos favoritos: é na hora do primeiro conflito de verdade que ela faz diferença. Tem mais guias como este no Cofre, e todo dia sai vídeo novo de tecnologia no @heliofilhou.