¿Cómo gestionar ramas y pull requests en Azure DevOps?
Adentrarse en el mundo del desarrollo de software puede parecer a veces un desafío monumental, especialmente cuando se trata de gestionar eficientemente tu código fuente en entornos de colaboración. Azure DevOps se presenta como una herramienta idónea para facilitar estos procesos, permitiendo a los desarrolladores manejar ramas y pull requests con eficacia. En esta guía, te llevaremos a través del proceso de creación de ramas y gestión de pull requests directamente en Azure DevOps, optimizando así tu flujo de trabajo en proyectos colaborativos.
¿Cómo crear una rama en Azure DevOps?
Las ramas son una parte vital del ciclo de desarrollo, permitiendo a los desarrolladores trabajar en paralelo sin interferir con el trabajo de otros. En Azure DevOps, crear una rama dentro del portal es un proceso intuitivo.
Navegación a Branches: Dirígete a la sección de "Repos" y selecciona "Branches".
Identificación del repositorio: Asegúrate de estar en el repositorio correcto.
Creación de la rama:
Selecciona la rama base de la que deseas partir (por ejemplo, main o master).
Elige un nombre claro y descriptivo para tu nueva rama, evitando espacios o caracteres especiales.
Opcionalmente, asocia la rama a un ProductBacklogItem, vinculándola a un ticket o tarea específica del proyecto para realizar un seguimiento eficaz.
Aquí te dejamos un ejemplo básico de cómo se ve el flujo de trabajo utilizando Azure DevOps:
git checkout -b NuevaRama main
¿Qué son los pull requests y cómo se crean?
Un pull request es esencialmente una solicitud para fusionar cambios de una rama a otra. Este proceso no solo asegura que el código nuevo cumpla con los estándares del proyecto, sino que también promueve la revisión por pares dentro del equipo.
Acceso a pull requests: Ve a la sección de "Repos" y selecciona "Pull Requests".
Creación de un nuevo pull request:
Selecciona la rama que contiene los cambios (source branch) y la rama en la que quieres fusionar esos cambios (target branch).
Proporciona un título claro y una descripción detallada para tu pull request.
Asigna revisores del equipo para realizar comentarios (una práctica altamente recomendada en proyectos reales para asegurar la calidad del código).
Puedes también etiquetar al pull request o relacionarlo con un ticket existente.
El código de ejemplo para crear un pull request sería similar al siguiente:
git push origin NuevaRama
# Crea el pull request y especifica el reviewer y detalles adicionales.
¿Cómo se gestionan los comentarios y aprobaciones?
La gestión de los comentarios es una parte crucial del proceso de revisión de pull requests. Aquí está el procedimiento para interactuar con los comentarios:
Asignación de revisores: Los revisores pueden dejar comentarios específicos sobre trozos de código que deben mejorarse.
Anotaciones de mejora: Si un revisor sugiere cambios, el autor del pull request debe contestar y, en su caso, implementar las modificaciones necesarias.
Estados de revisión: Un pull request puede ser aprobado, rechazado o puesto en estado de espera hasta que se resuelvan todas las observaciones pendientes.
Prueba de tu comprensión
Te animamos a practicar creando un nuevo pull request para combinar los cambios que se encuentran en la rama master hacia la nueva rama que creaste previamente, por ejemplo, AzureBranch. Esto te permitirá poner en práctica los conceptos aprendidos y afianzar tu comprensión de cómo Azure DevOps facilita el continuo flujo de integración y desarrollo.
Recuerda, gestionar adecuadamente tus ramas y pull requests es esencial para un desarrollo de software eficaz. ¡Sigue explorando y mejorando tus habilidades en Azure DevOps!
Pull Request: Son una petición en la que nosotros queremos combinar código que nosotros tenemos dentro de una rama particular, la rama tmb se denomina branch
A tener en cuenta : La rama no se denomina Branch.
Branch en Inglés equivale a Rama en Español.
Así es, lo mismo pasa con GitHub
Es curioso, porque en GitLab esta petición tiene el nombre de merge request, esto tiene sentido, ya que estamos solicitando que nuestro código haga merge con otro.
En GitHub lo llamaron pull request seguramente al verlo desde la otra perspectiva; una donde yo como dueño de un repositorio tengo a otra persona que me está mandando sus cambios y pidiendo que haga pull de sus cambios en mi código.
A mi también me confundia al inicio. De hecho, preferiría que se llamara merge.
++Pull Requests++: La traducción directa sería algo así como “Petición de Validación”.
Básicamente un pull request es una petición para integrar nuestras propuestas o cambios de código a un proyecto.
Los pull request permiten no solo llevar de forma más ordenada las tareas en la etapa del desarrollo, sino también crear propuestas o cambios que puedan ser integrados posteriormente a dicho proyecto.
Una buena práctica de ramas es no hacer PR directos a master, los desarrolladores debemos trabajar con una estructura logica que puede variar pero lo más (basico) común es:
Master
-Release
- Develop
- Features
- Hotfix
Features y Hotfix son las ramas de un desarrollador, los PR se hacen desde estas ramas hacia develop, los cuales deben ser revisados por un code reviewer.
Gracias por el aporte
Excelente observación, muy importante tener clara la estrategia debranching
Lo normal es que otra persona diferente al que crea el PR sea la que lo apruebe, para garantizar revisión y calidad.
Claro, de lo contrario no tendría sentido
Los pull requests son la forma de contribuir a un proyecto grupal o de código abierto. Por ejemplo, un usuario llamado Harry realiza un fork de un repositorio de ThanoshanMV y le efectúa algunos cambios
Así es !
El flujo "desarrollo" a "staging" y luego a "producción" con ramas asegura que los cambios se prueben primero en un entorno seguro antes de llegar a los usuarios finales. Evita errores costosos al permitir pruebas en "staging" antes de implementar en "producción"
¿esto de los pullrequest se puede usar para proyectos que no tengan nada que ver son software? por ejemplo crear una ramificación del proyecto y documentar que tanto se modifico?
Una vez descargado y clonado el repositorio a mi pc, debo ejecutar el comando "npm install" para instalara dependencias?
si correcto y npm start para iniciarlo
En AzureRepos, cuando hago git pull en la terminal, incluye las branches (creadas en AzureRepos), pero si hago pull desde vsCode, no me trae las branches que he creado en AzureRepos. Para traer las branches creadas en AzureRepos, debo hacer fetch, y luego checkout.
Es esto normal?
Cual seria la correcta forma de traer una branch remota en Azure?
En AzureRepos, para traer una branch remota, se debe hacer 'git fetch' seguido de 'git checkout' seguido del nombre de la branch remota que se desea traer.
Asociación importante entre el branch y el ticket no permitirá saber en que pendientes estamos trabajando
Si queremos crear una rama nueva, nos pregunta a partir de que rama creara la bifurcación y si esta rama tiene que ver con algún Work(Ticket) que tengamos sea Epic o Issues tambien pueden ser varios tickets a la vez
No olvidemos que los Pull Request nos ayudan a validar y revisar los cambios en codigo, cuando se esta trabajando con un grupo de personas, este paso es escencial, ya que si hay algo mal podemos revertir el escenario.
una consulta, se hizo merge entre customHooks y master, sin embargo se actualizó master respecto a todas las ramas, acaso las ramas no son independientes?
una consulta, el proyecto tenía 10 ramas y se hizo un merge entre master y customHooks, entiendo q se actualice master respecto a los cambios de customHooks pero al parecer se actualizó master respecto a los cambios de todas las ramas, es así? y porque?
Para configurar pull requests como mandatorios en Azure Repos, debes establecer políticas de rama. Sigue estos pasos:
Ve al proyecto en Azure DevOps y selecciona "Repos".
Haz clic en "Branches" y localiza la rama que deseas proteger.
Haz clic en los tres puntos al lado de la rama y selecciona "Branch policies".
Activa la opción "Require a minimum number of reviewers" y establece cuántos revisores son necesarios.
Guarda los cambios.
De esta manera, cualquier cambio entre ramas requerirá un pull request y la aprobación de los revisores definidos.
Si desde Azure-Repos clonas el proyecto hacia VSCode no te baja todas las ramas sino solo la rama master
lo siento tremendamente similar a trabajar con gitlab
El curso de platzi de git y GitHub es muy bueno para dominar los conceptos relacionados con el control de versiones de código