Esta guía no fue escrita ni revisada por inteligencia artifical, por favor, tomarse el tiempo de leer.
Cuando sea aplicable (siempre debe ser aplicable), usar solo el número del ticket de Jira y la categoría correspondiente, ejemplo de categorías:
bugfix/ - branch que arregla un bug en el código.docs/ - mejora o creación de documentación.feature/ - agregar un feature nuevo o se está trabajando en uno.tool/ - agregar alguna herramienta de desarrollo.release/ - reservado para releases.task/ - se está haciendo algúna tarea de rútina.Ejemplo de nombres de ramas:
feature/GE-78bugfix/GE-67Los commits también deben contener el número del ticket, esto puede parecer redundante pero ayuda a identificar más rápidamente a que ticket pertenece el commit, los commits deben tener significado y estar bien escritos.
Esta guía es muy interesante para aprender a escribir commits de calidad https://cbea.ms/git-commit/
Ejemplos:
GE-78: Agregar autenticación de 2 factoresGE-99: Agregar template del homepageLos nombres de las tablas deben ser (siempre que se pueda), en singular.
usuarios no, usuario si.
roles no, rol si
Los nombres de las columnas deben ser descriptivos y significativos, si se trata de una PRIMARY_KEY, por favor no utilizar solo el nombre "id", el nombre de la PRIMARY_KEY siempre debe ser, nombre-de-tabla + "id", por ejemplo:
usuario_idrol_idDemostración rápida:
-- Ejemplo si es usa solo nombre "id" como PRIMARY_KEY (dificil de entender)
select
r.id,
u.id,
u.nombre
from rol r
join rol_usuario ru on ru.rol_id = r.id
join usuario u on u.id = r.usuario_id
where u.nombre = 'Mario Bros';
-- Ejemplo si se usa nombre-de-tabla + "id" como PRIMARY_KEY
select
r.rol_id,
u.usuario_id,
u.nombre
from rol r
join rol_usuario ru on ru.rol_id = r.rol_id
join usuario u on u.usuario_id = r.usuario_id
where u.nombre = 'Mario Bros';
Las IAs deben considerarse herramientas de apoyo, uno siempre debe entender lo que está haciendo, cada commit es una representación de uno mismo, por eso, antes de hacer un commit, verificar y entender el código sugerido.
No es necesario llenar el código de comentarios, el buen código debe poder entenderse sin necesidad de leer comentarios, y si se usa comentarios, que sean para explicar el porque de las cosas.
Antes de buscar culpables, buscar soluciones, las personas siempre nos equivocamos, por eso siempre debe existir procesos que detecten errores en el sistema.
Una buena contribución de código se debe camuflar con el código que ya existe.
Si se encuentra algo que no está bien hecho, arreglarlo antes de que sea un problema, es mejor ser proactivo que reactivo.
Pedir ayuda siempre que se necesite.