Vinculación de Commits, PRs y Tickets

Un ID de ticket en el nombre de tu rama cuesta tres segundos escribirlo y ahorra horas de cambio de contexto después. La convención es simple:

feature/PROJ-123-add-password-reset
fix/PROJ-456-null-pointer-in-export
chore/PROJ-789-upgrade-node-20

El ID del ticket (PROJ-123) es el ancla. El slug después de él (add-password-reset) es para humanos que leen la salida de git branch. Juntos, crean una rama que es tanto buscable como escaneable.

El mismo principio aplica a los commits. Incluir el ID del ticket en el mensaje del commit — ya sea en la línea de asunto (fix(PROJ-456): handle null export payload) o en el cuerpo — te permite rastrear cualquier línea de código hasta el elemento de trabajo que lo motivó. git log --grep="PROJ-456" devuelve cada commit relacionado con ese ticket, a través de cada rama, instantáneamente.

Esta trazabilidad se vuelve crítica durante la respuesta a incidentes. Cuando un despliegue falla, necesitas responder "¿qué cambió?" rápido. Si las ramas y commits referencian IDs de ticket, el camino desde "este commit rompió producción" hasta "aquí está el ticket con el contexto completo" toma segundos. Sin ese enlace, estás leyendo diffs y adivinando la intención.

El PR es donde el código se encuentra con el ticket. Una descripción de PR que no referencia el ticket que implementa es una conexión perdida — el revisor ve qué cambió pero no por qué, y el ticket permanece en "en progreso" hasta que alguien lo mueve manualmente.

La mayoría de las plataformas soportan vinculación por palabra clave que automatiza esto:

Closes #123
Fixes PROJ-456
Resolves #789

GitHub, GitLab y Bitbucket reconocen estas palabras clave en las descripciones de PR y auto-enlazarán (y opcionalmente auto-cerrarán) el ticket referenciado cuando el PR se fusione. Linear y Jira soportan integración similar a través de nombres de rama o descripciones de PR. El costo es una línea en tu plantilla de PR. El beneficio es trazabilidad de extremo a extremo desde la solicitud hasta el despliegue.

Una buena plantilla de descripción de PR es mínima:

• Qué: resumen de una oración del cambio.
• Por qué: enlace al ticket (que tiene el contexto completo).
• Cómo probar: si los criterios de aceptación no son obvios desde el diff.

Los equipos que consistentemente enlazan PRs a tickets pueden responder "¿qué se desplegó esta semana?" consultando su rastreador en lugar de leer git log. El ticket se convierte en la única fuente de verdad para una pieza de trabajo — desde la solicitud a través de la implementación hasta el despliegue.

El auto-cierre es el último eslabón en la cadena de trazabilidad: cuando un PR se fusiona, el ticket referenciado se mueve a "hecho" sin que nadie toque el rastreador. Suena menor. En la práctica, elimina una categoría completa de ruido de tickets obsoletos.

Sin auto-cierre, los tickets permanecen en "en progreso" o "en revisión" mucho después de que el código se haya desplegado. El tablero se ve mal. Las métricas de sprint son inexactas. Los ingenieros pierden tiempo arrastrando manualmente tickets a la columna de hecho — lo cual olvidan hacer la mitad del tiempo, lo que significa que el tablero siempre está obsoleto.

Configurarlo depende de tu stack. GitHub auto-cierra tickets referenciados con Closes #123 en la descripción del PR por defecto — sin configuración necesaria. Jira requiere una integración de GitHub (o Bitbucket o GitLab) que mapee fusiones de PR a transiciones de flujo de trabajo. Linear lo maneja nativamente cuando los PRs referencian IDs de ticket en el nombre de la rama.

El patrón es el mismo en todas partes: referencia el ticket en el PR, deja que las herramientas manejen el cambio de estado. Una decisión al momento de crear el PR ahorra un paso manual en cada fusión y mantiene tu tablero honesto.