O que um histórico de commits já ensina

Um padrão escondido à vista

Leia o histórico recente deste projeto, deixando de fora os commits de merge, e um padrão aparece sem que ninguém precise explicá-lo. Este é o main em 2026-10-05, a partir de logo abaixo dos dois commits mais novos, que corrigiram um bug de área de transferência:

$ git log --oneline --no-merges -6 f936dc45
f936dc45 Finish style pass: Bundler: semantic versioning
ea85daba Style and facts: Bundler: semantic versioning, lessons 1-7
a68f6442 Finish style pass: Deployment: Kamal 2 basics
dee55bb9 Style and facts: Deployment: Kamal 2 basics, lessons 1-7
cd051b7f Finish style pass: Advanced Git: rebase & stash
0ba97d6b Style and facts: Advanced Git: rebase & stash, lessons 1-7

Cada curso da passada de conteúdo atual sai como o mesmo par de commits. Style and facts: <título do curso>, lessons 1-7 traz as aulas reescritas, e Finish style pass: <título do curso> acrescenta o relatório do curso. O par sobe como um único pull request a partir de uma branch chamada content/style-pass-<nível>-<número>, então na main ele chega como Merge pull request #N from .../content/style-pass-junior-N. Ninguém escreveu esse formato num arquivo de configuração, do jeito que o .rubocop.yml impõe um estilo de código. Ele surgiu porque quem escrevia esses commits repetia a mesma coisa de propósito, curso após curso. Mais para trás, o histórico mostra a convenção de uma passada anterior: 317 commits com o título Revise: <título do curso> (...), com os achados listados entre parênteses.

O que "Git workflow: commit" já ensinou

A aula "git commit: anatomia de um bom commit", de "Git workflow: commit", trata das regras que valem em qualquer lugar. São elas o modo imperativo ("Add index", e não "Added index"), uma linha de assunto curta e um corpo quando o "porquê" precisa de explicação. Essas regras valem em qualquer repositório. O que elas não dizem é o hábito deste repositório. Aqui, uma passada de conteúdo sai como um commit Style and facts: seguido de um commit Finish style pass:, cada um com o nome completo do curso. Isso não é uma regra universal. É uma convenção em que este projeto se acomodou, visível só lendo o histórico.

Por que essa diferença importa para um assistente de IA

Peça à maioria dos assistentes de código com IA para "escrever uma mensagem de commit" sem mais contexto. Eles recorrem a algo comum, como o Conventional Commits (feat: add X, fix: resolve Y). É um padrão razoável e muito usado. Também não é o que este projeto faz. Um assistente que escreva aqui um commit bem formado feat: add course content estaria certo em geral e errado para este repositório. Alguém do time lendo o git log notaria na hora. A correção não é uma IA mais esperta. É entregar à IA os últimos commits deste projeto antes de pedir o próximo, para ela seguir o que está aqui.

O que este curso cobre

1. Entregar à IA o diff em si, e não uma descrição de memória do que mudou.
2. Pedir à IA que siga a convenção de commits de um projeto em vez de um modelo genérico.
3. Escrever uma descrição de PR que vá além de "o que mudou" e chegue ao que quem revisa precisa.
4. Basear essa descrição no que o CI deste app confere, e não numa afirmação genérica de "os testes passam".
5. Aplicar a mesma disciplina, estado verdadeiro em vez de estado inventado, à documentação gerada.
6. Um diff levado do começo ao fim, da mensagem de commit à descrição do PR.

No fim, uma mensagem de commit ou descrição de PR escrita com IA deixa de ser um palpite e passa a se apoiar no que este repositório faz.