{"id":36214,"date":"2023-11-24T09:00:18","date_gmt":"2023-11-24T08:00:18","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=36214"},"modified":"2023-11-29T12:34:31","modified_gmt":"2023-11-29T11:34:31","slug":"conventional-commits-como-estandarizar-el-proceso-de-creacion-de-commits-mediante-reglas-comunes","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/conventional-commits-como-estandarizar-el-proceso-de-creacion-de-commits-mediante-reglas-comunes\/","title":{"rendered":"Conventional Commits. C\u00f3mo estandarizar el proceso de creaci\u00f3n"},"content":{"rendered":"

A medida que una empresa o departamento incrementa su tama\u00f1o, crecen tambi\u00e9n los retos y dificultades t\u00e9cnicas<\/strong> a las que es necesario enfrentarse. Estos retos suceden, principalmente, por el incremento de personas y por el aumento de la complejidad en los proyectos que se manejan. Mis compa\u00f1eros del \u00e1rea CMS de hiberus Digital<\/a>, Adri\u00e1n Mar\u00edn y Alejandro Arnau lo saben muy bien y lo explicaron perfectamente en una charla llamada \u2018Transformaci\u00f3n \u00c1gil a Escala: Liderando +150 Expertos en Drupal en Proyectos Globales\u2019<\/strong> que impartieron durante la pasada DrupalCamp Spain que se celebr\u00f3 en Sevilla del 20 al 23 de septiembre.<\/p>\n

En este art\u00edculo quiero contaros c\u00f3mo hemos resuelto uno de esos retos y c\u00f3mo esta soluci\u00f3n se ha aplicado a otras \u00e1reas de hiberus Digital para estandarizar el proceso de creaci\u00f3n de commits en un repositorio Git<\/strong>.<\/p>\n

Cuando hace unos a\u00f1os nuestra \u00e1rea era mucho m\u00e1s peque\u00f1a de lo que es hoy en d\u00eda y los equipos que trabajaban en un proyecto eran m\u00e1s reducidos, era f\u00e1cil mantener la uniformidad en la creaci\u00f3n de commits<\/strong> y conseguir que todos los desarrolladores del \u00e1rea siguieran unas reglas comunes<\/strong> a la hora de escribir los mensajes de estos commits.<\/p>\n

A medida que el equipo fue creciendo y se fueron incorporando m\u00e1s desarrolladores nos encontramos con una situaci\u00f3n en la que, debido al n\u00famero de proyectos simult\u00e1neos y a la complejidad creciente de los mismos, mantener estas reglas comunes se hac\u00eda muy complicado, obligando a los l\u00edderes t\u00e9cnicos del \u00e1rea a un esfuerzo extra para controlar el tono, el estilo y la relevancia de los mensajes. Esta situaci\u00f3n nos oblig\u00f3 a buscar una soluci\u00f3n para solucionarla. Despu\u00e9s de revisar y evaluar varias alternativas decidimos apostar por el uso de Conventional Commits<\/strong>.<\/p>\n

\u00bfQu\u00e9 es Conventional Commits?<\/h2>\n

Tal como indica su p\u00e1gina oficial, Conventional Commits es una especificaci\u00f3n para dar significado a los mensajes de commits<\/strong> haci\u00e9ndolos comprensibles tanto para las m\u00e1quinas como para las personas<\/strong>. Proporciona un conjunto sencillo de reglas para crear un historial de commits expl\u00edcito, lo que hace m\u00e1s f\u00e1cil poder escribir herramientas automatizadas.<\/p>\n

Dicha especificaci\u00f3n o convenci\u00f3n define una serie de reglas para escribir los mensajes de commit que consiguen mejorar la legibilidad del hist\u00f3rico del repositorio y posibilitan tener herramientas que automaticen procesos basados en el historial de commits<\/strong>.<\/p>\n

Est\u00e1 basada e inspirada en las Commit Message Guidelines del proyecto Angular.<\/p>\n

Al poder describir en los mensajes de los commits las funcionalidades, arreglos y cambios de ruptura hechos, esta convenci\u00f3n encaja a la perfecci\u00f3n con Semantic Versioning o Semver.<\/p>\n

Se trata de la convenci\u00f3n m\u00e1s extendida para establecer un versionado a librer\u00edas, paquetes o dependencias, estableciendo tres bloques separados:<\/p>\n

    \n
  • MAJOR<\/strong>: n\u00famero de versi\u00f3n que se incrementa cuando se rompe la compatibilidad de versiones anteriores.<\/li>\n
  • MINOR<\/strong>: n\u00famero de versi\u00f3n que se incrementa cuando se a\u00f1ade funcionalidad y esta es compatible en la versi\u00f3n MAJOR actual.<\/li>\n
  • PATCH<\/strong>: n\u00famero de versi\u00f3n que se incrementa cuando se arreglan errores en la versi\u00f3n MAJOR.MINOR actual.<\/li>\n<\/ul>\n

    Estructura<\/h2>\n

    Seg\u00fan esta especificaci\u00f3n, un mensaje de commit debe estructurarse de la siguiente forma:<\/p>\n

    \"\"<\/p>\n

      \n
    • tipo<\/strong>: tipo de commit, refiri\u00e9ndose a su contenido.<\/li>\n
    • \u00e1mbito<\/strong>: opcional, sirve para dar informaci\u00f3n contextual. Ej.: nombre del m\u00f3dulo o paquete<\/li>\n
    • descripci\u00f3n<\/strong>: el asunto del commit<\/li>\n
    • cuerpo<\/strong>: opcional, deber\u00eda aportar m\u00e1s informaci\u00f3n que la descripci\u00f3n<\/li>\n
    • nota al pie<\/strong>: opcional, se usa para indicar meta informaci\u00f3n sobre el commit<\/li>\n<\/ul>\n

      Tipo<\/h3>\n

      Indica el tipo de commit<\/strong>, refiri\u00e9ndose a su contenido.<\/p>\n

      La especificaci\u00f3n ofrece una gu\u00eda para los tipos, aunque puede modificarse y\/o adaptarse a las necesidades de cada equipo o empresa.<\/p>\n

      Existen diferentes listas de tipos recomendados, la que m\u00e1s nos gusta es la siguiente:<\/p>\n

        \n
      • build<\/strong>: cambios relacionados con la construcci\u00f3n o compilaci\u00f3n, por ejemplo, cuando se a\u00f1aden herramientas externas.<\/li>\n
      • chore<\/strong>: un cambio en el c\u00f3digo que un usuario externo no ver\u00e1, por ejemplo, un cambio en el archivo .gitignore<\/li>\n
      • feat<\/strong>: una caracter\u00edstica nueva<\/li>\n
      • fix<\/strong>: una correcci\u00f3n de errores<\/li>\n
      • docs<\/strong>: cambios relacionados con la documentaci\u00f3n<\/li>\n
      • refactor<\/strong>: un cambio que no corrige un error ni a\u00f1ade una caracter\u00edstica, por ejemplo, cuando se renombra una variable o funci\u00f3n.<\/li>\n
      • perf<\/strong>: c\u00f3digo que mejora el rendimiento<\/li>\n
      • style<\/strong>: un c\u00f3digo relacionado con el estilo<\/li>\n
      • test<\/strong>: a\u00f1adir un nuevo test o hacer cambios en un test existente<\/li>\n<\/ul>\n

        \u00c1mbito<\/h3>\n

        El campo \u00e1mbito es opcional y sirve para dar informaci\u00f3n contextual como por ejemplo indicar el nombre del m\u00f3dulo o paquete al que afecta el commit.<\/p>\n

        Puede ser complicado determinar si se tiene que usar o no, pero en caso de usarse tiene que ir entre par\u00e9ntesis.<\/p>\n

        Un listado de posibles \u00e1mbitos es:<\/p>\n

          \n
        • theme<\/li>\n
        • init<\/li>\n
        • runner<\/li>\n
        • watcher<\/li>\n
        • config<\/li>\n
        • web-server<\/li>\n
        • proxy<\/li>\n<\/ul>\n

          Descripci\u00f3n<\/h3>\n

          Se trata del asunto del commit, debe cumplir las siguientes reglas:<\/p>\n

            \n
          • Debemos usar el imperativo en ingl\u00e9s o el infinitivo en espa\u00f1ol<\/li>\n
          • La primera letra siempre ir\u00e1 en min\u00fascula<\/li>\n
          • No tenemos que escribir un punto al final<\/li>\n
          • El tama\u00f1o no deber\u00eda exceder los 50 caracteres<\/li>\n<\/ul>\n

            Cuerpo<\/h3>\n

            Es opcional y solo se deber\u00eda a\u00f1adir si aporta m\u00e1s informaci\u00f3n que la descripci\u00f3n.<\/p>\n

            Las reglas para crear la descripci\u00f3n son:<\/p>\n

              \n
            • Empieza despu\u00e9s de una l\u00ednea en blanco.<\/li>\n
            • Se usa el imperativo\/infinitivo, al igual que en la descripci\u00f3n<\/li>\n
            • Debe tener una anchura m\u00e1xima de 72 caracteres, aunque se pueden tener m\u00faltiples l\u00edneas.<\/li>\n
            • Solamente debe contener explicaciones de \u201c\u00bfQu\u00e9?\u201d (what) y \u201c\u00bfPor Qu\u00e9?\u201d (why), nunca de \u00bfC\u00f3mo? (How). Esta explicaci\u00f3n del \u201c\u00bfC\u00f3mo?\u201d se deber\u00eda hacer en la documentaci\u00f3n, si es necesario.<\/li>\n<\/ul>\n

              Nota al pie<\/h3>\n

              Es opcional y se usa para indicar meta informaci\u00f3n sobre el commit.<\/p>\n

              Las reglas para la escritura de las notas al pie son:<\/p>\n

                \n
              • Empieza despu\u00e9s de una l\u00ednea en blanco.<\/li>\n
              • Deber\u00eda usarse en las siguientes situaciones\n
                  \n
                • Para indicar cambios que rompan la compatibilidad de la versi\u00f3n actual<\/li>\n
                • Para mostrar uno o varios pull-request relacionados<\/li>\n
                • Para mostrar los revisores del commit<\/li>\n<\/ul>\n<\/li>\n
                • Si se incluyen varios de estos temas, cada uno de ellos en una l\u00ednea independiente<\/li>\n<\/ul>\n

                  Algunos ejemplos del uso de esta especificaci\u00f3n en nuestros proyectos<\/p>\n

                  \"\"<\/p>\n

                  \"\"<\/p>\n

                  \"\"<\/p>\n

                  Pr\u00f3ximos pasos<\/h2>\n

                  Con esta especificaci\u00f3n implementada en varias de nuestras \u00e1reas de manera satisfactoria, en hiberus nos planteamos cu\u00e1les ser\u00edan los siguientes pasos para mejorar la calidad de nuestros proyectos usando git como base de nuestros repositorios de c\u00f3digo.<\/p>\n

                  Adicionalmente al uso de la especificaci\u00f3n de Conventional Commits<\/strong>, el uso de Merge Request con Gitlab<\/strong> nos ayuda a realizar revisiones por pares en aquellos proyectos en los que es necesario.<\/p>\n

                  De la misma forma, tenemos implementado un sistema de generaci\u00f3n de documentaci\u00f3n en formato MKDocs, usando un contenedor dentro del proyecto, de manera que dicha documentaci\u00f3n se almacena dentro del propio repositorio y est\u00e1 disponible para cualquier desarrollador en el momento en que se clona el proyecto.<\/p>\n

                  En pr\u00f3ximos post comentaremos c\u00f3mo automatizar la generaci\u00f3n de changelogs, tags y releases<\/strong> dentro de los proyectos mediante diferentes herramientas como Semantic release y Commitizen. Ambas herramientas funcionan de manera similar y nos permitir\u00e1n ir un paso m\u00e1s all\u00e1 en la automatizaci\u00f3n de los procesos internos de desarrollo.<\/p>\n

                  En el \u00e1rea digital de hiberus estamos encantados de acompa\u00f1arte en la estrategia de tu negocio. Si tienes dudas, cons\u00faltanos y conoce nuestros servicios. \u00a1Te ayudaremos a relanzar y aumentar los resultados de tu negocio!<\/strong><\/p>\n

                  \n
                  \n
                  \n
                  \n

                  \u00bfQuieres m\u00e1s informaci\u00f3n sobre nuestros servicios de agencia digital y tecnolog\u00eda para ecommerce?<\/p>\n

                  Contacta con nuestro equipo de hiberus digital<\/p>\n <\/div>\n

                  \n \n
                  \n

                  <\/p>

                    <\/ul><\/div>\n
                    \n
                    \n<\/fieldset>\n
                    \n\t
                    \n\t\t
                    \n\t\t\t

                    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

                    \n\t\t\t

                    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

                    \n\t\t
                    \n\t\t\t

                    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

                    \n\t\t\t

                    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

                    \n\t\t
                    \n\t\t\t

                    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

                    \n\t\t
                    \n\t\t\t