Automatizar el flujo de trabajo dentro de GitHub Projects permite ahorrar tiempo, eliminar pasos manuales y mantener actualizado el estado de cada tarea sin depender de la memoria del equipo. Cuando vinculas repositorios, issues y pull requests de forma inteligente, el proyecto se gestiona prácticamente solo mientras tú te concentras en lo que más importa: escribir código.
¿Cómo vincular un repositorio con un proyecto en GitHub?
El primer paso es conectar tu repositorio con un proyecto existente. Dentro de tu repositorio, encontrarás la categoría de Projects [01:01]. Al acceder, verás que no hay ningún proyecto vinculado. Para solucionarlo, selecciona la opción "Enlaza un proyecto" y elige el proyecto correspondiente.
Antes de vincular, es buena práctica darle un nombre descriptivo al proyecto. Desde tu perfil, accede a la sección de proyectos, selecciona el ícono de editar y asigna un nombre claro como "Mi proyecto individual" [01:22]. También puedes agregar una descripción y un readme que explique las actividades principales. No olvides presionar "Guardar cambios" antes de continuar.
Una vez nombrado correctamente, regresa al repositorio, enlaza el proyecto y verás la palomita de confirmación [02:12]. A partir de ese momento, puedes vincular actividades y gestionarlas desde el tablero del proyecto.
¿Qué son los Insights y cómo miden el avance del equipo?
Con las tareas organizadas en distintos estatus — pendientes, en progreso y hechas — puedes acceder a la sección de Insights [03:12], ubicada en la parte superior derecha del proyecto. Esta herramienta genera una gráfica de estatus que muestra cuántas actividades se encuentran en cada fase.
La gráfica resulta muy útil para:
- Medir la eficacia del equipo en tiempo real.
- Identificar quién olvida actualizar el estatus de sus tareas.
- Tomar decisiones basadas en datos concretos sobre el progreso.
Sin embargo, depender de que cada persona actualice manualmente el estado genera inconsistencias. Aquí es donde entran los workflows automatizados.
¿Cómo configurar workflows para automatizar el cambio de estatus?
Dentro de tu proyecto, selecciona los tres puntos y accede a la categoría de Workflows [03:42]. Aquí encontrarás flujos predefinidos que responden a eventos específicos.
¿Qué ocurre cuando se cierra un issue o pull request?
El flujo de item cerrado cambia automáticamente el estatus de la actividad a "hecho" cuando un issue o un pull request se cierra [03:55]. Puedes editar este comportamiento para que, en lugar de marcarlo como hecho, lo mantenga en progreso o cualquier otro estado que necesites.
¿Cómo funciona el flujo de code review aprobado?
El flujo de code review aprobado representa la antesala de fusionar un pull request [04:28]. Cuando alguien aprueba la revisión de código, el estatus de la tarea puede cambiar automáticamente a "hecho". Solo necesitas editar el flujo, seleccionar el estatus deseado y guardar.
¿Cómo verificar la automatización con un flujo completo?
Para probar que todo funciona, convierte una actividad del proyecto en un issue seleccionando los tres puntos sobre la tarea y eligiendo "Conviértelo en un issue" [05:03]. Asocia el issue al repositorio correspondiente.
Después, crea una nueva rama desde la sección de ramas del repositorio [05:30]. Realiza los cambios necesarios — por ejemplo, agregar un archivo style.css — y haz commit verificando que estás en la rama correcta.
Al crear el pull request, escribe en la descripción la palabra clave closes seguida del símbolo # y el número del issue [06:21]. Esta palabra mágica vincula directamente el pull request con el issue, y cuando el pull request se fusione, el issue se cerrará automáticamente.
markdown
closes #17
Una vez que el pull request es aprobado y fusionado [07:00], ocurren tres cosas de forma automática:
- El pull request se marca como cerrado.
- El issue asociado también se cierra.
- La actividad en el proyecto pasa de in progress a done.
Todo sin intervención manual.
¿Qué más se puede automatizar con workflows?
Los workflows de GitHub Projects son solo el punto de partida. Existen extensiones que permiten enviar notificaciones cuando un pull request se cierra, ya sea a Slack, Microsoft Teams o por correo electrónico [07:56]. De esta forma, todo el equipo se entera de que una actividad fue completada sin necesidad de revisar el tablero constantemente.
También es importante recordar que, aunque en un entorno de aprendizaje resulta práctico hacer todo desde la interfaz web de GitHub, en un escenario real la gestión de ramas y cambios se realiza desde la terminal o desde VSCode [07:35].
¿Ya has automatizado algún flujo en tus proyectos de GitHub? Comparte tu experiencia y cuéntanos qué workflows te han resultado más útiles.
