smart-git-automation

O que eu faço

• Detecta e agrupa mudanças relacionadas de forma inteligente
• Gera automaticamente nomes de branch descritivos a partir das mudanças
• Fluxo de trabalho simplificado: escanear → criar branch → commitar → enviar → PR com menos prompts

Quando usar

Use isso quando quiser um fluxo de trabalho Git mais rápido e inteligente que agrupa mudanças logicamente e reduz a sobrecarga de confirmação manual.

Etapas do Fluxo de Trabalho

1. Detecção e Agrupamento Inteligente

Executa em paralelo:

• git status - verifica o que mudou
• git diff --stat - vê o resumo da modificação de arquivos
• git diff --name-only - lista apenas os arquivos alterados
• git diff --staged --stat - vê o que já está preparado (staged)

Analisa as mudanças para agrupá-las logicamente:

• Arquivos no mesmo módulo/diretório → provavelmente relacionados
• Arquivos que foram modificados juntos em edições recentes → provavelmente relacionados
• Novos arquivos que se complementam → provavelmente relacionados

Apresenta as mudanças agrupadas em um formato claro, por exemplo:

📁 Group 1: UI Components
  - src/components/Button.tsx (modified)
  - src/components/Button.test.tsx (modified)

📁 Group 2: API Layer
  - src/api/client.ts (new)
  - src/api/types.ts (modified)

2. Geração Automática de Nome de Branch

Gera o nome do branch a partir do padrão de mudança dominante:

• Usa o formato: <type>/<short-description>
• Tipos: feature, fix, refactor, docs, test, chore
• Deriva a descrição do arquivo/funcionalidade alterado mais significativo
• Converte para kebab-case, máximo de 50 caracteres
• Exemplos:
  • feature/add-user-auth (de arquivos relacionados à autenticação)
  • fix/login-validation (de mudanças de validação)
  • refactor/api-cleanup (de refatoração de API)

Mostra o nome do branch proposto e pede confirmação de uma palavra (ou digite uma alternativa).

3. Branch e Commit Simplificados

• Se não estiver no branch principal (main/master): verifica se o branch atual corresponde ao nome proposto
  • Se sim: permanece nele
  • Se não: pergunta se deseja mudar ou criar um novo
• Cria o branch apenas após validar o nome do branch, depois usa git checkout -b "$branch_name"
• Prepara (stages) apenas caminhos de arquivo explícitos: git add -- path/to/file ...
  • Se os caminhos dos arquivos forem gerados, mantenha-os delimitados por NUL (git diff -z --name-only) e passe-os como argumentos de pathspec.
  • Nunca concatene nomes de arquivos não confiáveis em um comando shell e nunca execute o texto do placeholder literalmente.
• Gera automaticamente a mensagem de commit a partir das mudanças:
  • Primeira linha: <type>: <short description> (máximo de 72 caracteres)
  • Corpo: mudanças de arquivos agrupadas com descrições breves
• Commita com a mensagem gerada, mostra uma prévia primeiro
• Pede confirmação de uma palavra para prosseguir

4. Push e PR Opcional

• Após o commit, pergunta: "Enviar para o remoto? (sim/não/abortar)"
• Se sim: git push -u origin <branch-name>
• Em seguida, pergunta: "Criar PR? (sim/não)"
• Se sim:
  • Verifica o remoto: git remote -v
  • Se for um fork: usa o remoto do fork (por exemplo, mskadu/repo-name)
  • Gera automaticamente a descrição do PR a partir das mensagens de commit
  • Usa gh pr create com:
    • Título do nome do branch
    • Corpo: resumo das mudanças + detalhamento dos arquivos + notas de acompanhamento

Regras Principais

• Agrupa arquivos relacionados automaticamente, mas permite que o usuário ajuste
• Gera nomes de branch a partir das mudanças reais, não pede ao usuário para nomeá-los
• Reduz confirmações: pede respostas de uma palavra ou pontos de confirmação únicos
• Nunca comita segredos, credenciais ou binários grandes
• Verifica se o repositório GitHub existe antes da criação do PR
• Pula a etapa do PR se o usuário disser "não" em qualquer ponto
• Se o branch já existir com mudanças, oferece para emendar ou adicionar um novo commit

Limitações

• Não ignora regras de mantenedores específicas do repositório, políticas de branch ou portões de revisão obrigatórios.
• Confirma explicitamente ações destrutivas ou de publicação; esta habilidade deve simplificar o fluxo Git rotineiro, não remover a responsabilidade.