Este artículo es parte de nuestra serie “Advanced Git”. Asegúrate de sigue a Tower en Twitter o suscríbete al boletín de Tower para conocer los próximos artículos.
Una confirmación en Git puede ser una de dos cosas:
- Puede ser una variedad desordenada de cambios de todo tipo de temas: algunas líneas de código para una corrección de errores, un intento de reescribir un módulo antiguo y un par de archivos nuevos para una característica completamente nueva.
- O, con un poco de cuidado, puede ser algo que nos ayude a estar al tanto de las cosas. Puede ser un contenedor de cambios relacionados que pertenecen a un solo tema y, por lo tanto, nos facilita la comprensión de lo que sucedió.
En esta publicación, estamos hablando de lo que se necesita para producir el último tipo de compromiso o, en otras palabras: el compromiso “perfecto”.
Serie avanzada de Git:
- Parte 1: Creando el compromiso perfecto en Git (¡estás aquí!)
- Parte 2: Estrategias de ramificación en Git
- Parte 3: Mejor colaboración con solicitudes de extracción
- Parte 4: Fusionar conflictos
- Parte 5: Rebase vs. Fusionar
- Parte 6: Rebase interactiva
- Parte 7: Compromisos de selección de cerezas en Git
- Parte 8: Uso de Reflog para restaurar confirmaciones perdidas
Por que son importantes las confirmaciones limpias y granulares
¿Es realmente necesario redactar confirmaciones de una manera cuidadosa y reflexiva? ¿No podemos simplemente tratar a Git como un aburrido sistema de respaldo? Repasemos nuestro ejemplo anterior una vez más.
Si seguimos el primer camino, donde simplemente acumulamos cambios en confirmaciones cada vez que suceden, las confirmaciones pierden gran parte de su valor. La separación entre una confirmación y la siguiente se vuelve arbitraria: no parece haber ninguna razón por la que se hayan realizado cambios en una confirmación y no en la otra. Ver estos compromisos más tarde, por ejemplo, cuando sus colegas intentan darle sentido a lo que sucedió en esa revisión, es como revisar el “cajón de todo” que tiene cada hogar: hay todo aquí que no encuentra lugar en otro lugar, desde crayones hasta chinchetas y recibos de efectivo. ¡Es muy difícil encontrar algo en estos cajones!
Seguir el segundo camino, donde colocamos solo las cosas (léase: cambios) que pertenecen juntas en el mismo compromiso, requiere un poco más de planificación y disciplina. Pero al final, tú y tu equipo son recompensados con algo muy valioso: ¡un historial de compromisos limpio! Estas confirmaciones te ayudarán a comprender lo que sucedió. Ayudan a explicar los cambios complejos que se realizaron de una manera digerible.
¿Cómo hacemos para crear mejores confirmaciones?
Redactar mejores confirmaciones
Un concepto es fundamental para componer mejores confirmaciones en Git: la Área de ensayo.
El Área de ensayo se creó exactamente para este propósito: permitir a los desarrolladores seleccionar cambios, de una manera muy granular, que deberían ser parte de la próxima confirmación. Y, a diferencia de otros sistemas de control de versiones, Git te obliga a hacer uso de esta Área de prueba.
Desafortunadamente, sin embargo, todavía es fácil ignorar el efecto de limpieza del área de preparación: un simple git add . tomará todos nuestros cambios locales actuales y los marcará para la próxima confirmación.
Es cierto que, en ocasiones, este puede ser un enfoque muy útil y válido. Pero muchas veces, sería mejor detenernos un segundo y decidir si realmente todos nuestros cambios son sobre el mismo tema. O si dos o tres confirmaciones separadas podrían ser una opción mucho mejor.
En la mayoría de los casos, tiene mucho sentido mantener las confirmaciones más pequeñas que más grandes. Centrados en un tema individual (en lugar de dos, tres o cuatro), tienden a ser mucho más legibles.
El Área de ensayo nos permite elegir cuidadosamente cada cambio que debería incluirse en la siguiente confirmación:
$ git add file1.ext file2.extEsto solo marcará estos dos archivos para la próxima confirmación y dejará los otros cambios para una futura confirmación o ediciones posteriores.
Este simple acto de hacer una pausa y elegir deliberadamente lo que debería convertirse en el próximo compromiso es muy útil. Pero podemos ser incluso más precisos que eso. Porque a veces, incluso los cambios en un solo archivo pertenecen a múltiples temas.
Veamos un ejemplo de la vida real y observemos los cambios exactos en nuestro archivo “index.html”. Podemos usar el comando “git diff” o una GUI de escritorio Git como Tower:
Ahora, podemos agregar el -p opción a git add:
$ git add -p index.htmlLe estamos indicando a Git que revise este archivo en un nivel de “parche”: Git nos toma de la mano y nos guía a través de todos los cambios en este archivo. Y nos pregunta, para cada fragmento, si queremos agregarlo al Área de ensayo o no:
Escribiendo [Y] (para “sí”) para el primer fragmento y [N] (para “no”) para el segundo fragmento, podemos incluir la primera parte de nuestros cambios en este archivo en la próxima confirmación, pero dejar los otros cambios para más adelante o para más ediciones.
¿El resultado? Una confirmación más granular y precisa que se centra en un solo tema.
Probando tu código
Ya que estamos hablando de “el compromiso perfecto” aquí, no podemos ignorar el tema de las pruebas. La forma exacta en que “prueba” su código puede variar, pero la noción de que las pruebas son importantes no es nueva. De hecho, muchos equipos se niegan a considerar un fragmento de código completado si no se ha probado adecuadamente.
Si todavía está indeciso acerca de si debe probar su código o no, desacreditemos un par de mitos sobre las pruebas:
- “Las pruebas están sobrevaloradas”: El hecho es que las pruebas te ayudan a encontrar errores más rápidamente. Lo más importante es que lo ayudan a encontrarlos antes de que algo entre en producción, que es cuando los errores más duelen. ¡Y encontrar errores temprano es, sin exagerar, invaluable!
- “Las pruebas cuestan un tiempo valioso”: Después de un tiempo, descubrirá que las pruebas bien escritas le permiten escribir código más rápido. Pierde menos tiempo buscando errores y descubre que, más a menudo, una prueba bien estructurada también prepara su pensamiento para la implementación real.
- “Probar es complicado”: Si bien esto podría haber sido un argumento hace un par de años, ahora no es cierto. La mayoría de los lenguajes y marcos de programación profesionales vienen con un amplio soporte para configurar, escribir y administrar pruebas.
Con todo, es casi seguro que agregar pruebas a sus hábitos de desarrollo hará que su base de código sea más robusta. Y, al mismo tiempo, te ayudan a convertirte en un mejor programador.
Un valioso mensaje de compromiso
El control de versiones con Git no es una forma elegante de hacer una copia de seguridad de su código. Y, como ya hemos comentado, las confirmaciones no son un montón de cambios arbitrarios. Los compromisos existen para ayudarlo a usted y a sus compañeros de equipo a comprender lo que sucedió en un proyecto. Y un buen mensaje de compromiso es de gran ayuda para garantizar esto.
Pero, ¿qué hace que un mensaje de compromiso sea bueno?
- Una línea de asunto breve y concisa que resume los cambios.
- Un cuerpo de mensaje descriptivo que explica los hechos más importantes (y de la forma más concisa posible)
Comencemos con la línea de asunto: el objetivo es obtener un breve resumen de lo sucedido. La brevedad, por supuesto, es un término relativo; pero la regla general es (idealmente) mantener el tema por debajo de 50 caracteres. Por cierto, si te cuesta encontrar algo breve, ¡esto podría ser un indicador de que el compromiso aborda demasiados temas! Podría valer la pena echar otro vistazo y ver si tiene que dividirlo en varios, separados.
Si cierra el asunto con un salto de línea y una línea vacía adicional, Git entiende que el siguiente texto es el “cuerpo” del mensaje. Aquí tienes más espacio para describir lo que sucedió. Es útil tener en cuenta las siguientes preguntas, que su cuerpo de texto debe intentar responder:
- ¿Qué cambió en su proyecto con este compromiso?
- ¿Cuál fue el motivo de este cambio?
- ¿Hay algo especial a tener en cuenta? ¿Algo que alguien más deba saber sobre estos cambios?
Si tiene en cuenta estas preguntas al escribir el cuerpo del mensaje de confirmación, es muy probable que produzca una descripción útil de lo que sucedió. Y esto, en última instancia, beneficia a tus compañeros (y después de un tiempo: a ti) a la hora de intentar comprender este compromiso.
Además de las reglas que acabo de describir sobre el contenido de los mensajes de confirmación, muchos equipos también se preocupan por el formato: acordar los límites de caracteres, los cambios de línea suaves o rígidos, etc., todo ayuda a producir mejores confirmaciones dentro de un equipo.
Para que sea más fácil cumplir con estas reglas, recientemente agregamos algunas características a Tower, la GUI de escritorio de Git que creamos: ahora puede, por ejemplo, configurar el conteo de caracteres o los cambios de línea automáticos como desee.
Una gran base de código consta de grandes confirmaciones
Cualquier desarrollador admitirá que quiere una gran base de código. Pero solo hay una forma de lograr este noble objetivo: ¡produciendo consistentemente grandes compromisos! Espero haber podido demostrar que (a) vale la pena perseguir este objetivo y (b) no es tan difícil de lograr.
Si desea profundizar en las herramientas avanzadas de Git, no dude en consultar mi “Kit de Git avanzado” (gratuito): es una colección de videos cortos sobre temas como estrategias de ramificación, Rebase interactiva, Reflog, Submódulos y mucho más.
¡Diviértete creando increíbles confirmaciones!
Serie avanzada de Git:
- Parte 1: Creando el compromiso perfecto en Git (¡estás aquí!)
- Parte 2: Estrategias de ramificación en Git
- Parte 3: Mejor colaboración con solicitudes de extracción
- Parte 4: Fusionar conflictos
- Parte 5: Rebase vs. Fusionar
- Parte 6: Rebase interactiva
- Parte 7: Compromisos de selección de cerezas en Git
- Parte 8: Uso de Reflog para restaurar confirmaciones perdidas