Si quieres acelerar tu flujo de trabajo en GitHub sin perder tiempo en burocracia, automatizar GitHub Projects te permite vincular issues, pull requests y cambios de estado para que todo avance solo mientras tú te concentras en escribir código. Esta guía te muestra cómo hacerlo paso a paso, ideal para quienes gestionan proyectos de software en equipo.

¿Cómo vincular un proyecto a tu repositorio en GitHub?

Dentro de tu repositorio, la pestaña Projects aparece vacía hasta que enlazas uno. Antes de hacerlo, conviene renombrar el proyecto desde tu perfil para evitar nombres genéricos como project sin título.

• Ve a tu perfil y abre la sección de Projects.
• Selecciona el icono de editar y asigna un nombre, por ejemplo mi proyecto individual.
• Agrega una descripción y un README que explique las actividades principales.
• Guarda los cambios con el botón superior y regresa al repositorio.

De vuelta en el repositorio, usa la opción link a project y elige el nombre correcto. Cuando aparezca la palomita, tu proyecto queda vinculado y puedes empezar a sumar tareas.

¿Cómo creo y organizo actividades dentro del proyecto?

Desde el proyecto vinculado puedes capturar tareas como actualizar mi proyecto HTML, actualizar archivo CSS y actualizar archivo JavaScript. Cada una se mueve entre tres estados: todo, in progress y done. Esa columna es la base sobre la que después se construyen métricas y automatizaciones.

¿Para qué sirve GitHub Projects? Es un tablero integrado a tu repositorio que organiza issues y pull requests por estado, responsable y prioridad, para que veas el avance real del proyecto sin salir de GitHub.

¿Cómo medir el desempeño con la sección Insights?

En la esquina superior derecha del proyecto está insights, donde aparece una gráfica de status con cuántas actividades están pendientes, en progreso y terminadas. Esto te ayuda a ver el ritmo del equipo y a identificar a quienes se olvidan de mover sus tarjetas.

Y aquí viene lo interesante: en lugar de pedirle a tu equipo que actualice manualmente cada tarjeta, puedes dejar que GitHub lo haga por ti vía workflows.

¿Cómo configurar workflows automáticos en GitHub Projects?

Desde los tres puntos del proyecto entras a la categoría de workflows, donde GitHub lista las acciones que disparan cambios de estado automáticos [02:30].

• Item closed: cuando cierras un issue o pull request, la tarjeta pasa a done automáticamente.
• Code review approved: al aprobar un pull request, puedes mover la tarea a done sin tocar el tablero.
• Cada flujo se edita con el botón verde save para habilitarlo o cambiar el estado destino.

Con estos flujos activos, tu tablero se actualiza solo cada vez que cierras trabajo en el repositorio.

¿Cómo conectar un issue con un pull request usando closes?

La palabra clave para cerrar issues automáticamente es closes. El flujo completo se ve así:

1. En tu actividad del proyecto, selecciona los tres puntos y elige convert to issue, asociándolo al repositorio.
2. Crea una nueva rama, por ejemplo amin/17, desde la sección de branches.
3. Agrega tu archivo, como style.css, con un comentario inicial y haz commit en esa rama.
4. Abre el pull request y en la descripción escribe: Agregué el archivo CSS. Closes #17.

Al hacer esto, GitHub vincula el pull request con el issue y lo muestra en la sección development. Cuando el pull request se fusiona, el issue se cierra y la tarjeta del proyecto pasa de in progress a done sin intervención manual [05:40].

¿Qué hace la palabra closes en un pull request? Crea un enlace directo entre el pull request y un issue. Al fusionar el pull request, GitHub cierra automáticamente el issue referenciado con closes #número.

¿Qué pasa después de fusionar el pull request?

Una vez que tu compañero revisa y aprueba el pull request, GitHub lo fusiona, te ofrece eliminar la rama y muestra el issue como cerrado en development. Al volver a projects, la actividad ya aparece en done. Todo el ciclo, desde escribir código hasta actualizar el tablero, queda automatizado.

Vale la pena recordar que aunque aquí todo se hizo desde la web por fines didácticos, en un escenario real harás la creación de ramas, los commits y los pull requests desde la terminal o VS Code, que son las herramientas estándar del día a día.

¿Hasta dónde puedes expandir los workflows de GitHub?

Los workflows son apenas el primer escalón. Existen extensiones que disparan notificaciones cuando un pull request se cierra y avisan al equipo por:

• Slack, con mensajes en el canal del proyecto.
• Microsoft Teams, integrando alertas en tus chats de trabajo.
• Correo electrónico, para notificar a stakeholders externos.

Con estas integraciones, tu tablero deja de ser un registro pasivo y se convierte en el centro de comunicación del equipo. Cuéntame en los comentarios qué tarea repetitiva te gustaría automatizar primero en tu repositorio.