Crie o repositório e monte commits pelo stage

Nesta aula você transforma uma pasta comum em repositório e produz três commits que contam uma história. O resultado não é apenas um log com três linhas: você consegue explicar qual versão estava na bancada, qual foi selecionada e qual entrou no histórico.

Crie um laboratório descartável. Assim, errar não ameaça um projeto real:

LAB=$(mktemp -d /tmp/curso-git.XXXXXX)
git init -b main "$LAB/catalogo"
cd "$LAB/catalogo"

git init cria .git e não cria arquivos de aplicação. Pense em três áreas. A working tree é a bancada onde você edita. O stage é a seleção exata do próximo retrato. O repositório é o arquivo de commits. O stage não move um arquivo fisicamente; ele registra o conteúdo escolhido no índice.

Crie README.md, catalogo.txt e notas.txt com seu editor. O status curto deve marcar os três com ??, ainda não rastreados:

git status --short

Prepare somente README e catálogo. Deixar notas de fora é a decisão didática que prova por que o stage existe:

git add README.md catalogo.txt
git status --short
git diff --cached --stat

As letras A aparecem na coluna do stage. notas.txt continua com ??. git diff --cached compara a seleção ao último commit; como ainda não existe commit, mostra tudo que será a raiz.

Configure nome e e-mail local de exercício se necessário e grave:

git config user.name "Aluno Git"
git config user.email "aluno@example.test"
git commit -m "docs: inicia catálogo"

Leia a resposta: root-commit, hash curto, quantidade de arquivos e linhas. Não copie o hash de outra pessoa; ele depende de conteúdo e metadados. Faça uma segunda mudança apenas no catálogo, revise o patch e use a mensagem feat: adiciona primeiro livro. Na terceira, melhore as instruções do README.

O erro mais comum é executar commit com apenas arquivos untracked. A mensagem termina com nothing added to commit but untracked files present. Ela não diz que Git quebrou. Diz que nada chegou ao stage. Decida se o arquivo pertence ao projeto antes de executar add. Não adicione tudo apenas para remover o aviso.

Outra situação importante é MM: você preparou um arquivo e depois editou novamente. A primeira letra representa o stage; a segunda, working tree. O commit leva a versão preparada. Rode add de novo somente se a edição recente pertence à mesma decisão.

Ao final, confira:

git status --short
git --no-pager log --oneline -3

Status limpo significa que toda mudança rastreada está representada ou foi descartada conscientemente. Não significa que o código funciona; testes ainda são necessários. O log precisa permitir reconstruir intenção sem abrir cada arquivo.

Use o laboratório de prompt como ensaio. Ele não executa Git nem envia texto a uma API; apenas ajuda a verificar se sua sequência declara contexto, regras e resultado. Depois execute os comandos no terminal real. A aula termina quando você consegue prever o status antes de rodá-lo e explicar por que git add . é uma conveniência que exige revisão.