Devolutions/IronRDP

Convenções de commit e PR

Trate o título do PR e o corpo inicial como a mensagem de commit exata que será aplicada no squash-and-merge.

Mensagem de commit

• Leia as instruções do repositório primeiro. Derive escopos com a skill commit-scope local do repositório. Se indisponível, use regras explícitas do repositório ou omita o escopo em vez de inventar um.
• Siga Commits Convencionais: <tipo>[escopo opcional][!]: <descrição>.
• Mire em 50 caracteres e descreva o comportamento resultante. Não remova escopos exigidos pelo repositório para atingir esse limite; quando eles tornam impossível, mantenha a descrição restante o mais concisa possível.
• Separe assunto, corpo e rodapés com linhas em branco.
• Para commits individuais, quebre as linhas do corpo em 72 caracteres. Explique por que a mudança era necessária, como ela resolve o problema e os efeitos colaterais materiais.
• Coloque a chave ou link de ticket existente em um rodapé, não no assunto: Issue: PROJECT-123. Siga o formato de rodapé específico do repositório quando houver uma issue. Quando não houver, omita o rodapé em vez de fabricar Issue: N/A.
• Adicione rodapés de Commits Convencionais aplicáveis e trailers Co-authored-by: Nome <email> para colaboradores.
• Escolha o tipo pela superfície afetada, não pelo fato de a mudança corrigir um defeito.
• Use ci para alterações de CI, workflow e automação, incluindo correções nessa automação.
• Use fix para bugs de produto ou runtime e mudanças que não são de funcionalidade em limites de API pública consumidos externamente.
• Use feat para funcionalidades, build para build ou dependências, chore para ferramentas ou configurações não relacionadas ao produto, docs para documentação apenas, style para edições não semânticas, refactor para reestruturação interna, test para testes e perf para desempenho.
• Marque mudanças de quebra com ! ou um rodapé BREAKING CHANGE sem alterar um tipo que de outra forma seria preciso.
• Mantenha todo commit de desenvolvimento não squashado coerente e convencional.

fix(storage): preservar índices colacionados

Normalizar colações expandidas pelo servidor antes de comparar definições de índice.

Issue: PROJECT-123

Pull request

• Defina o título exatamente como o assunto do commit squash pretendido.
• Defina o corpo inicial exatamente como o corpo e rodapés do commit squash pretendido. Exclua preâmbulos, listas de verificação e diários de implementação exclusivos do PR.
• Não quebre manualmente o corpo do PR; o GitHub lida com a quebra de exibição.
• Mantenha o histórico permanente conciso: registre motivação, comportamento material e efeitos colaterais.
• Coloque experimentos, alternativas, validações extensas e cronologia de implementação em comentários subsequentes.
• Publique um comentário subsequente com as linhas alteradas, dividido pelo menos em código de produção, testes e outros arquivos, para que um revisor veja onde está o peso da mudança antes de lê-la; como contar e apresentá-las é sua decisão, e atualize-o quando o diff mudar materialmente.
• Atualize o título e o corpo inicial conforme a implementação evolui.
• Antes de abrir, atualizar ou fazer merge, leia título + linha em branco + corpo como uma única mensagem de commit e corrija qualquer discrepância.