Crear ramas y pull requests en Azure DevOps es el paso que te permite mover código entre entornos de forma controlada, desde una funcionalidad nueva hasta producción. Aquí aprendes cómo hacerlo directamente desde el portal, sin depender de la línea de comandos, y por qué este flujo es clave para mantener tu repositorio ordenado.

Esta guía te sirve si trabajas con equipos de desarrollo que aplican cultura DevOps y necesitas un control real sobre quién revisa, aprueba y mezcla el código.

¿Qué es un pull request y por qué importa en el ciclo de desarrollo?

Un pull request es una petición para combinar el código de una rama hacia otra. Es el mecanismo que te permite que una funcionalidad pase de tu rama de trabajo a develop, luego a staging y finalmente a producción, donde el usuario final ve los cambios.

¿Qué es un pull request? Es una solicitud para mezclar el código de una rama hacia otra. Permite revisión, comentarios y aprobación antes de unir los cambios.

El flujo típico se ve así:

• Creas una rama para una funcionalidad o un bugfix.
• Subes tus cambios a esa rama.
• Abres un pull request hacia la rama destino.
• Un revisor aprueba o pide cambios.
• Se completa el merge y el código avanza al siguiente entorno.

Este ciclo es el que da trazabilidad a cada línea de código que llega a producción.

¿Cómo creo una rama en Azure DevOps desde el portal?

Dentro de tu repositorio, navega a la sección Repos y luego a Branches. Ahí ves todas las ramas existentes, quién las creó y la fecha de su último commit. En el ejemplo del curso de React Hooks, cada clase tiene su propia rama con el demo correspondiente.

Para crear una nueva rama:

1. Define la rama base, por ejemplo master.
2. Asigna un nombre identificable, como Azure-Branch, sin espacios ni caracteres especiales.
3. Asocia la rama a un product backlog item para vincularla con un ticket existente.
4. Da clic en Create.

Al asociar la rama a un ticket, como el del pipeline, cualquier cambio que hagas queda ligado a esa tarea. Esto facilita el seguimiento entre el código implementado y los requisitos del proyecto.

Un detalle importante: cuando creas una rama desde master, ambas comparten el mismo último commit. En el demo, tanto master como Azure-Branch apuntaban al commit A5BE13, lo que confirma que están sincronizadas en ese punto de la historia.

¿Cómo creo un pull request paso a paso?

Ve a la sección Pull Requests dentro de Repos. Ahí ves los pull requests activos, completados y abandonados. Los abandonados son los que se descartaron y nunca llegaron a mezclarse.

Para crear uno nuevo:

• Selecciona la rama origen, por ejemplo custom-hooks, que tiene los cambios más recientes.
• Selecciona la rama destino, como master.
• Escribe un título claro, como "Moviendo últimos cambios a master".
• Agrega una descripción que explique qué incluye el cambio.
• Asigna reviewers, las personas que van a revisar el código.
• Vincula el pull request a un work item si quieres que el ticket se actualice automáticamente al completar el merge.

¿Qué es un required reviewer? Es un revisor obligatorio. Hasta que esa persona apruebe el pull request, no puedes mezclar el código con la rama destino.

En entornos reales, asignar required reviewers es buena práctica. Suele ser un senior o un technical lead quien valida que la implementación cumpla con los estándares del proyecto.

¿Qué hago si aparecen conflictos en el pull request?

Azure DevOps muestra de inmediato si existen conflictos entre las ramas. Cuando no hay conflictos, puedes avanzar con la revisión. Cuando los hay, debes resolverlos antes de completar el merge.

Durante la revisión, cada reviewer tiene varias acciones disponibles:

• Approve: aprueba los cambios.
• Reject: rechaza el pull request.
• Wait for author: indica que hay observaciones que el autor debe resolver antes de continuar.

En el demo, el usuario Platzi DevOps aprobó el pull request y quedó registrado en el historial de cambios junto con la fecha y la acción tomada.

¿Qué opciones tengo al completar el merge?

Al dar Complete, Azure DevOps te ofrece dos decisiones clave antes de mezclar:

• Eliminar la rama origen después del merge: útil si no necesitas conservar la rama de la funcionalidad. En el demo se mantuvo activa para preservar el historial.
• Completar los work items asociados: si lo activas, los tickets vinculados se mueven automáticamente a done o committed. En el demo se dejó desactivado porque el ticket se moverá más adelante, cuando se implemente la integración continua.

Una vez confirmas, Azure DevOps ejecuta el merge y muestra el estado Completed. A partir de ese momento, la rama destino contiene los cambios de la rama origen.

¿Qué hago si mi usuario no tiene permisos para crear pull requests?

Si al crear un pull request te aparece un mensaje como "el usuario no tiene permisos", es porque el rol asignado no incluye acciones sobre repositorios o integración continua. La solución es revisar los permisos del proyecto y ajustar el rol, o quitar al usuario como reviewer si solo necesitas avanzar con el demo.

Como reto, crea un pull request que mezcle los cambios de master hacia la rama Azure-Branch que creaste. Cuéntame en los comentarios qué nombre le pusiste a tu pull request y si decidiste eliminar la rama origen después del merge.