git init e git commit: seu primeiro repositório do zero

git init cria o repositório; git add seleciona o conteúdo; git commit grava uma versão com autor, data, mensagem e ligação ao commit anterior. Essa sequência curta é o núcleo do trabalho diário. O cuidado está em escolher um conjunto coerente, não em colocar tudo no histórico de uma vez.

O laboratório usa a Livraria Horizonte e uma pasta gerada por mktemp. A branch foi declarada para tornar a saída previsível:

LAB=$(mktemp -d /tmp/grupo-git-loja.XXXXXX)
git init -b main "$LAB/loja"

O init cria metadados, não arquivos de projeto

Depois do comando, a pasta visível ainda está vazia. ls -la revela .git, mas o Git não cria README, aplicação ou licença por você. A opção -b main define a primeira branch. Se sua configuração já define init.defaultBranch, git init loja produz o mesmo nome.

ls -la "$LAB/loja"

Pense em .git como o arquivo interno da livraria: os livros expostos ficam na working tree, enquanto fichas, referências e versões ficam no arquivo. A comparação não significa que você deve editar essas fichas manualmente. Os comandos são a interface segura.

Untracked, staged e committed são estados diferentes

Com README.md e catalogo.txt criados, a forma curta do status mostrou:

git status --short

Os arquivos estão na working tree e ainda são desconhecidos. git add copia a ideia do conteúdo atual para o índice, também chamado stage. Ele não salva para sempre: você ainda pode editar o arquivo depois e terá uma versão preparada e outra na bancada.

git add README.md catalogo.txt
git status --short

A letra na primeira coluna indica alteração preparada. Essa seleção explícita permite separar, por exemplo, a documentação pronta de uma experiência ainda quebrada.

Faça um commit que responda por que a mudança existe

A mensagem docs: inicia catálogo é curta, mas descreve intenção. Evite “alterações”, “coisas” e “teste”: elas não ajudam a localizar uma decisão seis meses depois.

git commit -m "docs: inicia catálogo"

root-commit diz que essa é a raiz. 9ba9c22 é a abreviação do hash real. As quatro inserções contam linhas adicionadas, não palavras. 100644 é o modo de arquivo regular não executável.

Stage existe para você montar uma versão coerente

No segundo passo, catalogo.txt e politica.txt mudaram, mas apenas o catálogo entrou na seleção. Isso é deliberado: a política ainda não estava revisada.

git add catalogo.txt
git diff --cached --stat

git diff sem opção compara working tree e stage. Com --cached, compara stage e último commit. Antes de cada commit, leia essa diferença. O hábito evita incluir logs, senhas e alterações de outra tarefa.

git commit -m "feat: adiciona Refatoração ao catálogo"

O segundo commit não é raiz. Ele aponta para o primeiro, formando uma cadeia. Depois, a documentação recebeu uma instrução e virou o terceiro registro:

git add README.md
git commit -m "docs: explica onde consultar livros"

git add ponto é conveniente e exige revisão

git add . prepara alterações abaixo da pasta atual. Em um projeto pequeno, parece o caminho mais rápido. Em um projeto real, pode misturar um .env, um build e notas pessoais. Prefira nomes explícitos enquanto aprende; quando usar o ponto, confira o stage.

git add .
git status --short
git diff --cached --stat

O resultado não torna git add . ruim. Ele mostra o contrato: tudo que não foi ignorado abaixo da pasta atual pode entrar. O .gitignore reduz o risco, mas não substitui a leitura do diff.

Há outro detalhe útil: o stage guarda o conteúdo preparado, não apenas o nome do arquivo. Se você executar git add catalogo.txt e depois editar o catálogo de novo, git status --short mostra MM. A primeira letra representa a versão que já está no stage; a segunda, a alteração mais recente que ficou na working tree. O próximo commit recebe somente a versão preparada. Rode git add outra vez se as duas mudanças pertencem à mesma decisão, ou mantenha a segunda fora se ela ainda precisa de trabalho. Essa separação é o motivo prático para o índice existir. Ela deixa você construir um commit revisável mesmo quando a pasta contém várias ideias em andamento.

O erro comum ainda informa o próximo passo

Se você cria notas.txt e tenta commitar sem preparar, o Git não inventa sua intenção:

git commit -m "docs: adiciona notas"

Leia o final: há arquivo não rastreado, mas nada preparado. A correção é revisar notas.txt, decidir se ele pertence ao projeto e então executar git add notas.txt. Se for anotação pessoal, ignore ou mova para fora; não adicione apenas para silenciar o erro.

Três commits precisam contar uma história

A prova final é o log compacto:

git --no-pager log --oneline --decorate -3

Você consegue explicar o resultado sem abrir os arquivos: primeiro nasceu o catálogo, depois entrou um livro, por fim a documentação apontou o caminho. Esse é o critério de um bom conjunto de commits. Não existe número mágico de linhas; existe uma decisão coerente, revisável e reversível.

Sua missão é repetir o laboratório com um cardápio, agenda ou inventário. Prepare apenas um arquivo por vez, leia git diff --cached e produza três commits cujas mensagens formem uma narrativa. Termine quando git status e git log confirmarem working tree limpa e histórico compreensível. O guia da trilha Git mostra onde branches e remoto entram depois.