Todo el mundo sabe ejecutar git commit. Poca gente hace commits bien. Y la diferencia no se nota hoy: aparece dentro de seis meses, cuando ejecutas git blame sobre una línea con errores y encuentras el mensaje eterno: "ajustes finales". Git no es un backup. Es una herramienta de comunicación con el equipo, y el equipo también te incluye a ti en el futuro.
Un commit pequeño es un regalo para tu yo del futuro
Un buen commit hace una sola cosa. ¿Renombraste una función? Un commit. ¿Corregiste el bug de timeout? Otro commit. ¿Ajustaste la indentación? Preferiblemente, ni siquiera lo incluyas en el commit.
El problema de un commit gigante que mezcla refactor, corrección y formato no es estético. Es práctico: cuando ese bug vuelva a producción, querrás ejecutar git revert solo sobre la corrección, y no podrás hacerlo porque está pegada a otras 400 líneas modificadas.
Los commits atómicos hacen viable git bisect, permiten un git revert quirúrgico y mantienen el historial legible. Regla general: si para describir el commit necesitas usar una "y", probablemente sean dos commits.
Buen mensaje: imperativo en la primera línea y el porqué en el cuerpo
La primera línea debe ser un resumen corto —unos 50 caracteres— y estar en imperativo, como si completara la frase "si se aplica, este commit...": "Corrige el timeout en la subida de imágenes". No "corregido" ni "corrigiendo". El propio Git usa el imperativo en sus mensajes automáticos; sigue ese patrón.
Después, deja una línea en blanco y escribe el cuerpo. Y aquí está lo que separa un buen mensaje de uno inútil: el cuerpo explica por qué, no qué. El diff ya muestra qué cambió. Lo que no muestra es que cambiaste de biblioteca porque la anterior consumía demasiada memoria por encima de 2 MB. Eso es lo que alguien —quizás tú— necesitará saber más adelante.
Rama corta, PR pequeño, review rápido
Una rama que vive durante dos semanas se convierte en un festival de conflictos el día del merge. Cuanto más tiempo permanece alejada de main, más cambia el mundo debajo de ella.
Divide la tarea en partes. Cada rama debería durar horas o pocos días, no semanas. Lo mismo vale para el PR: uno de 200 líneas recibe una review de verdad, con alguien leyendo línea por línea. Uno de 2000 líneas recibe un "LGTM" y un emoji de cohete, porque nadie revisa 2000 líneas un sábado por la tarde. Un PR pequeño no es burocracia: es la única forma de que una review honesta ocurra.
Rebase o merge: depende de quién leerá el historial
Ambos integran cambios, pero cuentan historias diferentes. merge conserva lo que ocurrió realmente, con el commit de merge señalando dónde se unieron las ramas. rebase reescribe tu rama como si hubieras empezado desde el estado más reciente: un historial lineal y limpio, sin los "merge branch main into main" contaminando el log.
En la práctica, usa rebase para ordenar tu rama local antes de abrir el PR: actualizarla con main y aplastar los "fix typo" hasta convertirlos en un commit decente. Usa merge para llevar la rama revisada a main.
Y esta es la regla que no tiene excepciones: nunca hagas rebase de algo que ya se publicó y que otra persona podría haber descargado. Rebase reescribe los hashes; si el commit ya es público, acabas de crear dos historias divergentes y un git push --force que arruinará la mañana de alguien.
Un conflicto no es una pelea: resuélvelo con calma
Un conflicto asusta la primera vez porque Git arroja esos <<<<<<< en medio del archivo y parece que todo se rompió. No se rompió. Git solo está diciendo: "dos personas modificaron esta parte; tú decides".
Respira. git status muestra exactamente qué archivos necesitan atención. Abre uno a la vez. Entre los marcadores están las dos versiones: la tuya y la que llegó desde la otra rama. Lee ambas: el objetivo no es elegir un bando a la fuerza, sino entender qué quería hacer cada cambio y producir una versión que contemple los dos. Borra los marcadores, prueba, ejecuta git add y continúa. La prisa es la forma más fácil de sobrescribir el trabajo de alguien sin darte cuenta.
Lo que NUNCA entra en el repositorio
Una regla breve e innegociable: los secretos no se versionan. Nada de .env, claves de API, tokens ni credentials.json. Inclúyelos en .gitignore antes del primer commit, no después, porque para entonces ya será tarde. Un secreto que entró en el historial seguirá allí aunque borres el archivo en el commit siguiente; cualquiera con acceso al repositorio puede ejecutar git log y encontrarlo.
Más allá de los secretos, no versiones lo que se puede regenerar: node_modules, dist/, build/, .DS_Store y logs. Eso no es código: es ruido que aumenta el tamaño del repositorio y genera conflictos innecesarios.
Un buen uso de Git no consiste en memorizar comandos. Consiste en recordar que hay personas al otro lado leyendo lo que dejaste. Haz commits pequeños, explica el porqué y trata el .gitignore con el mismo cuidado que le das al código. Tu yo de dentro de seis meses te lo agradecerá —o te insultará—. La elección es tuya, un commit a la vez.
