Git Master

Use esta habilidade quando o usuário pedir para operar no histórico do Git ou responder a uma pergunta sobre o histórico do Git. Seja exato, conservador e baseado em evidências. Leia o estado do repositório antes de inferir qualquer coisa.

Modo de Portão

Classifique a solicitação primeiro:

• COMMIT: preparar e confirmar alterações locais.
• REBASE: rebasear, juntar (squash), corrigir (fixup), auto-juntar (autosquash), reordenar, dividir ou reescrever o histórico do branch de outra forma.
• HISTORY: responder quando, onde, quem, por que ou qual commit mudou algo.
• STATUS: inspecionar o estado do branch, diff ou árvore de trabalho sem alterá-lo.

Não confirme, rebaseie, envie (push), force envie (force-push), reverta (reset), desfaça o stash (stash-pop) ou delete nada, a menos que o usuário tenha solicitado explicitamente essa operação. Se a solicitação for apenas investigativa, relate as descobertas e pare.

Verdade Fundamental

Colete fatos independentes em paralelo quando as ferramentas permitirem:

git status --short
git diff --stat
git diff --staged --stat
git branch --show-current
git log -30 --oneline
git log -30 --pretty=format:%s
git rev-parse --abbrev-ref @{upstream}
git merge-base HEAD origin/main
git merge-base HEAD origin/master

A ausência de upstream ou a ausência de main/master é normal. Recorra ao melhor branch disponível ou relate o fato ausente. Nunca trate uma consulta falha como prova.

Anexos de Evidência do Corpo do PR

Quando o corpo de um PR precisar de capturas de tela ou PNGs de terminal, use a referência do repositório em docs/reference/github-attachment-upload.md. O caminho de hospedagem permitido são os anexos de usuário do GitHub do fluxo de anexos web autenticado; nunca confirme imagens temporárias, nunca use GitHub Releases para evidências de PR e nunca use hosts de imagem externos. Não registre cookies do navegador, tokens CSRF, campos de formulário S3 ou cabeçalhos de upload.

Modo de Confirmação (Commit)

Confirme apenas as alterações solicitadas pelo usuário. Preserve o trabalho sujo não relacionado.

1. Detecte o estilo da mensagem do histórico recente. Use o padrão local dominante, idioma e capitalização. Não use Conventional Commits por padrão, a menos que o repositório os utilize.
2. Inspecione o diff completo, não apenas os nomes dos arquivos. Separe as edições não relacionadas do usuário do commit solicitado.
3. Construa grupos atômicos por comportamento, módulo e reversibilidade. Mantenha a implementação e seus testes diretos juntos.
4. Prefira múltiplos commits para preocupações não relacionadas. Um único commit é aceitável apenas quando os arquivos alterados formam um comportamento indivisível ou quando o usuário solicita explicitamente um commit.
5. Prepare (stage) por caminho ou hunk para que cada commit contenha apenas seu grupo atômico.
6. Antes de cada commit, verifique git diff --staged --stat e diff preparado suficiente para provar que o grupo está correto.
7. Confirme com o estilo detectado. Após cada commit, verifique git log -1 --oneline.

Regras de agrupamento:

• Separe diferentes funcionalidades, módulos, artefatos gerados, configurações, documentação e alterações apenas de teste, a menos que sejam inseparáveis.
• Mantenha arquivos gerados com a alteração de origem que os produziu quando omiti-los deixaria o repositório inconsistente.
• Nunca oculte alterações com falha ou não relacionadas dentro de um commit amplo.

Relatório final: liste os hashes dos commits, mensagens e quaisquer arquivos restantes não confirmados.

Modo Rebase

A reescrita do histórico é uma operação de impacto compartilhado.

• Nunca rebaseie ou reescreva main, master, dev, branches de lançamento ou um branch protegido, a menos que o usuário tenha nomeado explicitamente essa operação exata.
• Se os commits já podem ter sido enviados (pushed), pergunte antes de forçar o envio (force-push). Use --force-with-lease, nunca --force simples.
• Se a árvore de trabalho estiver suja, preserve-a intencionalmente antes de rebasear. Não desfaça o stash (stash-pop) sobre conflitos sem verificar o que mudou.
• Para correções (fixups), prefira git commit --fixup=<hash> seguido por GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base>.
• Para conflitos, leia os arquivos conflitantes e resolva por intenção. Não escolha nosso/deles cegamente.
• Se um rebase der errado, use git rebase --abort primeiro. Use reflog apenas após explicar o caminho de recuperação.

Após a reescrita, execute os testes relevantes ou pelo menos a verificação de fumaça mais barata do projeto, e então mostre o log do novo branch da base até o HEAD.

Modo Histórico

Escolha a ferramenta Git pela pergunta:

• git log -S "text": quando a contagem de uma string exata mudou.
• git log -G "regex": quando diffs tocaram linhas que correspondem a um padrão.
• git blame -L start,end -- file: quem mudou linhas específicas por último.
• git log --follow -- file: histórico através de renomeações para um arquivo.
• git show <hash>: inspecione o commit que parece relevante.
• git bisect: encontre o primeiro commit com falha quando houver um comando determinístico de sucesso/falha e limites conhecidos de bom/ruim.

…