Devolutions/IronRDP

Convenciones de commits y PR

Trata el título y el cuerpo inicial del PR como el mensaje de commit exacto que se aplicará al hacer squash-merge.

Mensaje de commit

• Lee primero las instrucciones del repositorio. Deriva los ámbitos con la habilidad local del repositorio commit-scope. Si no está disponible, usa reglas explícitas del repositorio u omite el ámbito en lugar de inventarlo.
• Sigue Conventional Commits: <tipo>[ámbito opcional][!]: <descripción>.
• Apunta a 50 caracteres y describe el comportamiento resultante. No elimines ámbitos requeridos por el repositorio para alcanzar ese objetivo; cuando sea imposible, mantén la descripción restante lo más concisa posible.
• Separa el asunto, el cuerpo y los pies de página con líneas en blanco.
• Para commits independientes, ajusta las líneas del cuerpo a 72 caracteres. Explica por qué se necesitó el cambio, cómo lo resuelve y los efectos secundarios materiales.
• Coloca una clave o enlace de ticket existente en un pie de página, no en el asunto: Problema: PROYECTO-123. Sigue el formato de pie de página específico del repositorio cuando exista un issue. Cuando no exista ninguno, omite el pie de página en lugar de inventar Problema: N/A.
• Añade los pies de página aplicables de Conventional Commits y las líneas Coautor: Nombre <email> para colaboradores.
• Elige el tipo según la superficie afectada, no según si el cambio corrige un defecto.
• Usa ci para cambios en CI, flujos de trabajo y automatización, incluyendo correcciones a esa automatización.
• Usa fix para errores del producto o de tiempo de ejecución y cambios que no sean características en límites de API pública consumida externamente.
• Usa feat para características, build para compilación o dependencias, chore para herramientas o configuraciones no relacionadas con el producto, docs solo para documentación, style para ediciones no semánticas, refactor para reestructuración interna, test para pruebas y perf para rendimiento.
• Marca cambios disruptivos con ! o un pie de página BREAKING CHANGE sin cambiar un tipo que por lo demás sea preciso.
• Mantén cada commit de desarrollo no squasheado coherente y convencional.

fix(almacenamiento): preservar índices cotejados

Normalizar las colaciones expandidas por el servidor antes de comparar definiciones de índices.

Problema: PROYECTO-123

Pull request

• Establece el título como el asunto exacto del commit squash previsto.
• Establece el cuerpo inicial como el cuerpo y pies de página exactos del commit squash previsto. Excluye preámbulos, listas de verificación y diarios de implementación propios del PR.
• No ajustes manualmente el cuerpo del PR; GitHub maneja el ajuste de visualización.
• Mantén el historial permanente conciso: registra la motivación, el comportamiento material y los efectos secundarios.
• Coloca experimentos, alternativas, validación extensa y cronología de implementación en comentarios posteriores.
• Publica un comentario posterior con las líneas modificadas, divididas al menos en código de producción, pruebas y otros archivos, para que un revisor vea dónde está el peso del cambio antes de leerlo; cómo contarlas y presentarlas es decisión tuya, y actualízalo cuando el diff cambie materialmente.
• Actualiza el título y el cuerpo inicial a medida que evoluciona la implementación.
• Antes de abrir, actualizar o fusionar, lee título + línea en blanco + cuerpo como un solo mensaje de commit y corrige cualquier discrepancia.