7 Reglas para Escribir Buenos Mensajes de Commit como Programador: 1. Usa verbo imperativo: Escribe tus commits como acciones (Add, Fix, Remove). Ejemplo: “Add new feature”. 2. Sin puntos finales: Los mensajes de commit no necesitan punto final ni suspensivos. ¡Que sean claros y directos! 3. Máximo 50 caracteres: Mantén tus mensajes cortos y concisos. Si necesitas más, considera separar los commits. 4. Añade contexto: Usa el cuerpo del commit para información adicional cuando sea necesario. 5. Commits semánticos: Agrega prefijos como feat:, fix:, docs: para dar más sentido a tus commits. 6. Usa utilidades: Herramientas como Husky o Commitlint pueden ayudarte a mantener un historial limpio y consistente. 7. Explica el qué no el cómo. ¿Qué se añade? ¿Qué se arregla? No expliques ahí cómo lo estás haciendo. ¡Escribe commits claros y tu futuro yo te lo agradecerá!
Yo ocupo mi poderosísimo :emoji: [feat,fix,docs,...etc]: message ¿Por qué es tan verboso el commit? para más placer. 🗿y porqué está bomnito ver el emoji según gitmoji.dev 🥺🥺
Using imperative verbs in commit messages, enclosed in [brackets], enhances clarity and consistency. Examples: [ADD] new feature, [FIX] bug in login, [UPDATE] styles. It aligns with Git’s conventions and improves team collaboration. Try verbs like [CREATE], [OPTIMIZE], [TEST], or [DEPLOY] for a more descriptive commit history Miguel Ángel Durán García
Usar GitHub Copilot o Cursor y dejar que en base a los cambios escriba el mensaje apropiado
¡Muy buena guía! Quisiera añadir un par de puntos que también pueden ser útiles: ✅ Referencias a tickets o issues: Si trabajas en un proyecto colaborativo o bajo metodologías ágiles, incluir identificadores de tickets (por ejemplo, #123 o JIRA-456) en los commits ayuda a rastrear el propósito y contexto del cambio. ✅ Evitar mensajes genéricos: Mensajes como "fixed bug" o "update" son demasiado vagos. Siempre detalla qué fue arreglado o actualizado, aunque sea brevemente. ✅ Un cambio por commit: Mantén cada commit enfocado en un único propósito. Esto no solo facilita la revisión, sino también el revertir cambios si es necesario. ¡Implementar estos hábitos puede marcar una gran diferencia para equipos de desarrollo y para tu yo del futuro! 💻
git add . git commit -m "asdasd" git push origin -f main para variar, hacer force como los machos 😎
Todavía recuerdo, no un commit, pero sí el comentario en la cabecera de un método que decía "agregué un parámetro", el mensaje más descriptivo que leí en mi historia de programador.
A mi me gusta y me he guiado por https://www.conventionalcommits.org/en/v1.0.0/
Para más información recomiendo ver https://www.conventionalcommits.org/es/v1.0.0/
Miguel Ángel Durán García consulta, cuando pones "escribe tus commits como acciones" y das ejemplos, los pones como acciones a realizar no realizadas, teniendo en cuenta que cuando uno realiza un commit esta hablando de algo que ya hizo, no deberían ser acciones realizadas ya? Espero haber expresado bien mi duda, desde ya muchas gracias por tu tiempo, por lo que haces y muchos saludos!
Senior Software Engineer
2 semanasTambien podrian implementar abreviaturas como FT: Feature ,FX: Fix RF: Refactor , DC: Docs, TS: Test . [TICKET-123] FT: Add user login [TICKET-456] FX: Fix validation error [TICKET-789] RF: Optimize queries [TICKET-101] DC: Update README with installation steps [TICKET-202] TS: Add unit tests for login service