Integración de Jira y GitHub: cómo vincular commits e incidencias en 2026

Vincular un commit con una incidencia permite comprender qué cambio de código está asociado al trabajo. Esta guía adapta el recorrido de Make del 15 de junio de 2026 y distingue el comentario informativo de una transición de estado: que exista un commit no significa que el trabajo esté desplegado.

Antes de empezar

Prepara un repositorio y una incidencia de prueba, permisos autorizados y una convención para las claves, como PROJ-123. Elige la cuenta de Make según las condiciones vigentes de la página oficial de precios. Puedes registrarte en Make mediante nuestro enlace de afiliado. Podemos recibir una comisión si te registras a través de este enlace, sin coste adicional para ti.

Revisa las conexiones en la documentación de GitHub y Jira Cloud Platform. Autoriza solo los recursos que necesita el flujo. Para repositorios privados, revisa también quién podrá ver los comentarios y los registros de ejecución; una conexión válida no es una garantía general de seguridad.

1. Observa los commits del repositorio

El recorrido de la fuente utiliza GitHub > Watch Commits. Selecciona repositorio y rama, y configura la programación apropiada para tu prueba. No lo describas como recepción instantánea de webhooks si has elegido un disparador periódico.

Comprueba la salida con un commit conocido y localiza mensaje, SHA y URL. Prueba en la misma rama que observa el escenario: crear el commit en otra rama no verifica este flujo.

2. Extrae las claves de Jira

Añade Text parser > Match pattern y aplica una expresión adaptada a tu convención. Por ejemplo:

\b([A-Z][A-Z0-9]+-\d+)\b

Activa la búsqueda global si un mensaje puede citar varias incidencias. La expresión es un ejemplo, no una definición universal de las claves Jira. Comprueba también mensajes sin clave y repeticiones de la misma clave dentro de un mensaje.

3. Verifica la incidencia y la deduplicación

Consulta Jira con Get an Issue usando la clave extraída. Comprueba que pertenece al proyecto autorizado antes de publicar.

Como diseño editorial, utiliza una clave compuesta por repositorio, SHA e incidencia para seguir el trabajo realizado. Consulta el registro antes de actuar y guarda el estado de cada efecto completado. No marques todo como terminado antes de que se haya escrito el comentario: un fallo posterior impediría recuperarlo.

Si puede haber ejecuciones simultáneas, evita que dos procesos hagan la misma escritura a la vez. Un almacén de datos consultado antes de escribir no constituye por sí solo una garantía de exclusión.

4. Publica un comentario informativo

Usa Add an Issue Comment y mapea el mensaje del commit, el autor, el SHA y su URL. Comprueba el formato que acepta el módulo; no copies una estructura de otra versión de la API sin validarla.

Incluye una referencia estable para reconocer el comentario al reconciliar una ejecución cuyo resultado se desconoce. Comprueba en Jira que el enlace apunta al commit correcto y que no contiene información que el proyecto no deba recibir.

5. Decide si debe cambiar el estado

Una ruta opcional puede proponer una transición cuando se cumpla una regla del equipo. Consulta List Current Available Transitions in an Issue y usa Update an Issue Status (Transition Issue) con una transición válida.

No cambies el estado solo porque aparezca la palabra «fixes» si vuestro proceso exige revisión o despliegue. Si la transición no es válida, conserva el contexto para revisión en vez de ocultar todos los errores.

6. Recupera errores sin duplicar efectos

Las instrucciones actuales están en Error handlers e Incomplete executions. Corrige permisos o datos inválidos; para fallos transitorios, configura la recuperación que corresponda al tipo de error. No supongas que un reintento repite únicamente la parte que te interesa.

Prueba un commit con una clave, otro con varias, uno sin clave y una repetición. Verifica comentario, enlace y estado final en Jira.

Extensiones y consumo

Para eventos de pull request, crea un flujo con el disparador correspondiente y define reglas distintas para abrir, cerrar y fusionar. Un Aggregator reúne datos; no convierte lógica en un subescenario reutilizable.

El consumo depende de los módulos y los bundles procesados, así como de las rutas ejecutadas. No se ofrece una cifra fija por commit: para precios y cuotas de Make, consulta la página oficial de precios y mide el consumo de tus pruebas. Si usas nuestro enlace de afiliado de Make, podemos recibir una comisión, sin coste adicional para ti.

Las comprobaciones propuestas son recomendaciones editoriales, no resultados de una ejecución realizada por este sitio.

Fuente principal

Artículo oficial de Make. Las referencias técnicas específicas se enlazan en los pasos correspondientes.