/commit-message

Commit Message

Gera mensagens de commit apropriadas a partir de mudanças staged (git diff --staged). Não executa comandos git, apenas gera mensagens e copia para a área de transferência.

Uso

/commit-message [opções]

Opções

--format <formato> : Especifica formato da mensagem (conventional, gitmoji, angular)
--lang <idioma> : Força especificação do idioma da mensagem (en, pt)
--breaking : Detecção e descrição de Breaking Change

Exemplos Básicos

# Gerar mensagem a partir de mudanças staged (detecção automática de idioma)
# O candidato principal é automaticamente copiado para a área de transferência
/commit-message

# Forçar especificação de idioma
/commit-message --lang pt
/commit-message --lang en

# Detectar Breaking Change
/commit-message --breaking

Pré-requisitos

Importante: Este comando analisa apenas mudanças staged. É necessário fazer staging das mudanças com git add previamente.

# Se não houver staging, será exibido um aviso
$ /commit-message
Não há mudanças staged. Execute git add primeiro.

Função Automática de Área de Transferência

O candidato principal gerado é automaticamente copiado para a área de transferência no formato completo git commit -m "mensagem". Pode ser colado diretamente no terminal para execução.

Atenção na implementação:

Ao passar comando de commit para pbcopy, execute em processo separado da saída da mensagem
Use printf em vez de echo para evitar quebra de linha no final

Detecção Automática de Convenções do Projeto

Importante: Se existirem convenções específicas do projeto, elas têm prioridade.

1. Verificação de Configuração CommitLint

Detecção automática a partir dos seguintes arquivos:

commitlint.config.js
commitlint.config.mjs
commitlint.config.cjs
commitlint.config.ts
.commitlintrc.js
.commitlintrc.json
.commitlintrc.yml
.commitlintrc.yaml
Seção commitlint do package.json

# Busca por arquivos de configuração
find . -name "commitlint.config.*" -o -name ".commitlintrc.*" | head -1

2. Detecção de Tipos Customizados

Exemplo de tipos específicos do projeto:

// commitlint.config.mjs
export default {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "type-enum": [
      2,
      "always",
      [
        "feat",
        "fix",
        "docs",
        "style",
        "refactor",
        "test",
        "chore",
        "wip", // em andamento
        "hotfix", // correção urgente
        "release", // release
        "deps", // atualização de dependências
        "config", // mudança de configuração
      ],
    ],
  },
};

3. Detecção de Configuração de Idioma

// Quando o projeto usa mensagens em japonês
export default {
  rules: {
    "subject-case": [0], // Desabilitado para suporte ao japonês
    "subject-max-length": [2, "always", 72], // Ajuste de limite de caracteres para japonês
  },
};

4. Análise de Histórico de Commits Existentes

# Aprendizado de padrões de uso a partir de commits recentes
git log --oneline -50 --pretty=format:"%s"

# Estatísticas de tipos utilizados
git log --oneline -100 --pretty=format:"%s" | \
grep -oE '^[a-z]+(\([^)]+\))?' | \
sort | uniq -c | sort -nr

Detecção Automática de Idioma

Alternância automática entre japonês/inglês baseada nas seguintes condições:

Verificação de configuração de idioma nas configurações CommitLint
Julgamento automático através de análise do git log
Configurações de idioma de arquivos do projeto
Análise de comentários e strings dentro de arquivos modificados

O padrão é inglês. Quando identificado como projeto japonês, gera em japonês.

Formato da Mensagem

Conventional Commits (padrão)

<type>: <description>

Importante: Sempre gera mensagem de commit de 1 linha. Não gera mensagens de múltiplas linhas.

Nota: Se existirem convenções específicas do projeto, elas têm prioridade.

Tipos Padrão

Tipos obrigatórios:

feat: Nova funcionalidade (adição de funcionalidade visível ao usuário)
fix: Correção de bug

Tipos opcionais:

build: Mudanças no sistema de build ou dependências externas
chore: Outras mudanças (que não afetam o release)
ci: Mudanças em arquivos de configuração ou scripts de CI
docs: Mudanças apenas na documentação
style: Mudanças que não afetam o significado do código (espaços, formatação, ponto e vírgula, etc.)
refactor: Mudanças no código que não envolvem correção de bug ou adição de funcionalidade
perf: Melhoria de performance
test: Adição ou correção de testes

Exemplo de Saída (Projeto em Inglês)

$ /commit-message

📝 Sugestão de mensagem de commit
━━━━━━━━━━━━━━━━━━━━━━━━━

✨ Candidato principal:
feat: implement JWT-based authentication system

📋 Alternativas:
1. feat: add user authentication with JWT tokens
2. fix: resolve token validation error in auth middleware
3. refactor: extract auth logic into separate module

✅ `git commit -m "feat: implement JWT-based authentication system"` copiado para a área de transferência

Exemplo de implementação (versão corrigida):

# Copiar comando de commit para área de transferência primeiro (sem quebra de linha)
printf 'git commit -m "%s"' "$COMMIT_MESSAGE" | pbcopy

# Depois exibir mensagem
cat << EOF
📝 Sugestão de mensagem de commit
━━━━━━━━━━━━━━━━━━━━━━━━━

✨ Candidato principal:
$COMMIT_MESSAGE

📋 Alternativas:
1. ...
2. ...
3. ...

✅ \`git commit -m "$COMMIT_MESSAGE"\` copiado para a área de transferência
EOF

Exemplo de Saída (Projeto em Japonês)

$ /commit-message

📝 Sugestão de mensagem de commit
━━━━━━━━━━━━━━━━━━━━━━━━━

✨ Candidato principal:
feat: implementar sistema de autenticação JWT

📋 Alternativas:
1. feat: adicionar autenticação de usuário com token JWT
2. fix: resolver erro de validação de token no middleware de autenticação
3. docs: separar lógica de autenticação em módulo independente

✅ `git commit -m "feat: implementar sistema de autenticação JWT"` copiado para a área de transferência

Visão Geral da Operação

Análise: Analisar conteúdo de git diff --staged
Geração: Gerar mensagem de commit apropriada
Cópia: Copiar candidato principal automaticamente para a área de transferência

Nota: Este comando não executa git add ou git commit. Apenas gera mensagem de commit e copia para a área de transferência.

Funcionalidades Inteligentes

1. Classificação Automática do Conteúdo das Mudanças (apenas arquivos staged)

Adição de novo arquivo → feat
Padrão de correção de erro → fix
Apenas arquivos de teste → test
Mudança de arquivo de configuração → chore
Atualização de README/docs → docs

2. Detecção Automática de Convenções do Projeto

Arquivo .gitmessage
Convenções dentro de CONTRIBUTING.md
Padrões de histórico de commits anteriores

3. Detalhes da Detecção de Idioma (apenas mudanças staged)

# Critérios de julgamento (ordem de prioridade)
1. Julgar idioma a partir do conteúdo de git diff --staged
2. Análise de comentários de arquivos staged
3. Análise de idioma de git log --oneline -20
4. Configuração de idioma principal do projeto

4. Detalhes da Análise de Staging

Informações usadas para análise (apenas leitura):

git diff --staged --name-only - Lista de arquivos modificados
git diff --staged - Conteúdo real das mudanças
git status --porcelain - Status dos arquivos

Quando Breaking Change é Detectado

Se houver mudanças disruptivas na API:

Inglês:

feat!: change user API response format

BREAKING CHANGE: user response now includes additional metadata

feat(api)!: change authentication flow

Exemplo de Breaking Change:

feat!: alterar formato de resposta da API de usuários

BREAKING CHANGE: A resposta agora inclui metadados adicionais

feat(api)!: modificar fluxo de autenticação

Melhores Práticas

Adaptar ao projeto: Seguir o idioma dos commits existentes
Concisão: Clara em até 50 caracteres
Consistência: Não misturar (se inglês, unificar em inglês)
OSS: Para open source, recomenda-se inglês
Rigor de 1 linha: Sempre fazer mensagem de commit de 1 linha (se necessária explicação detalhada, complementar no PR)

Padrões Comuns