Saltar al contenido
Versión de trabajo · cuentas de prueba
Yin — Young Innovators Network · Academy (inicio)Academy

Módulo 5 · Proyecto Yingets

5.3 Commits que cuentan una historia

Qué aprenderás: cómo escribir mensajes de commit útiles, qué tamaño de cambio conviene y qué no subir nunca.

Un historial de commits es el diario de tu proyecto. Quien lo lee quiere saber qué hiciste, cuándo y por qué. Eso se consigue con tres hábitos.

1 · Mensajes que dicen algo. Una línea corta (unos 50–70 caracteres) que empieza con un verbo y explica el cambio:

Mensaje flojoMensaje claro
«cambios»«Añade la tabla comparativa de alternativas»
«arreglo»«Corrige la fecha de la tercera entrevista»
«sigo trabajando»«Reescribe el README con el problema y el usuario»
«version final final 2»«Añade capturas del prototipo y su descripción»

Si lo necesitas, puedes añadir un cuerpo más largo explicando el porqué. Algunos equipos usan prefijos como docs: o fix: (el convenio se llama Conventional Commits); es opcional. Lo importante es que sea claro y constante.

2 · Cambios con sentido. Un commit = una idea. «Añade entrevistas 4 y 5» y «Corrige el README» van en dos commits, no en uno. Ni uno por cada coma ni uno enorme por semana.

3 · Constancia. Haz commits mientras trabajas, no al final. Mejor cinco en cinco días distintos que cinco en la misma hora. Tienes que tener al menos cinco, pero lo importante no es el número: es que cuenten cómo avanzó tu proyecto.

Lo que nunca se sube:

No subasPor qué
Claves, contraseñas y tokensCualquiera puede usarlos; hay programas que rastrean repositorios en busca de claves
Datos personales (tuyos o de otras personas)Quedan visibles y no se pueden retirar del todo
Notas de entrevistas con nombresQuienes participaron no han aceptado publicarse
Contenido ajeno sin permisoRespeta licencias y derechos
Archivos enormes o ficheros temporalesEnsucian el repositorio

Si subes un secreto por error. Borrarlo en un commit posterior no lo elimina del historial. Haz esto: revoca esa clave de inmediato (en el servicio que la emitió), crea una nueva, guárdala fuera del repositorio y, si hace falta, pide ayuda para limpiar el historial.

El archivo .gitignore. Es un archivo de texto donde listas lo que Git debe ignorar (por ejemplo, archivos con claves o carpetas de datos privados). GitHub puede crearlo al empezar el repositorio.

Y la IA, aquí. Puede ayudarte a redactar mensajes a partir de lo que cambiaste, pero tú decides qué se cuenta, y el mensaje debe describir lo que de verdad ocurrió, no lo que suene mejor.

Ideas clave:

  • Un commit claro dice qué hiciste, empieza con un verbo y cambia una cosa.
  • Haz commits mientras trabajas: el historial es parte de la prueba.
  • Nada de claves, datos personales ni contenido ajeno en el repositorio; si se cuela una clave, revócala.

Error común: «fabricar» cinco commits seguidos para cumplir el mínimo. El historial enseña fechas y contenido: no engaña a quien lo mira, y tú pierdes la oportunidad de contar tu proceso.