Práctica: Trunk-based development, commits convencionales y versiones

Lo que vas a aprender en este TP

• Trabajar con ramas cortas
• Automatizar una regla con un hook
• Versionar y deshacer

Introducción #

Lo que vas a aprender en esta sección

• Trabajar con ramas cortas
• Automatizar una regla con un hook
• Versionar y deshacer

Contexto. Tu equipo fusiona ramas largas una vez al mes y pasa días resolviendo conflictos. Implantas un flujo trunk-based con herramientas.

Requisitos previos: Git 2.30 o superior  ·  Duración estimada: 35 min

Un repositorio con un historial legible, dos versiones publicadas y una vuelta atrás.

Puesta en práctica #

Pasos guiados, con su corrección.

1. 1. Crear el repositorio

   ¿Por qué? main es la única rama duradera: siempre debe poder entregarse.

   Inicializa un repositorio con una pequeña aplicación y un primer commit en main.

2. 2. Imponer los commits convencionales

   ¿Por qué? Una regla comprobada automáticamente ya no depende de la memoria de cada uno.

   Escribe un hook commit-msg que rechace los mensajes que no sigan type(ámbito): descripción y pruébalo.

3. 3. Una rama corta y su fusión

   ¿Por qué? Una rama de pocas horas se fusiona sin conflictos y se revisa fácilmente.

   Crea feat/remise, añade una función de descuento en dos pequeños commits, actualiza la rama con rebase y fusiónala (squash) en main.

4. 4. Publicar versiones

   ¿Por qué? El versionado semántico indica a los usuarios qué arriesgan al actualizar.

   Etiqueta v1.0.0, añade una corrección convencional, deduce el número siguiente, etiquétalo y genera la lista de cambios entre las dos versiones.

5. 5. Deshacer sin reescribir el historial

   ¿Por qué? En una rama compartida se deshace con un nuevo commit: nadie pierde su trabajo.

   Introduce un commit erróneo, encuéntralo con git bisect y deshazlo con git revert.

Nivel de dificultad : ●●○○○ (2/5)