You don't have access to this class

Keep learning! Join and start boosting your career

Aprovecha el precio especial y haz tu profesión a prueba de IA

Antes: $249

Currency
$209
Suscríbete

Termina en:

2 Días
22 Hrs
49 Min
29 Seg

Creando ramas y pull request

13/20
Resources

How to manage branches and pull requests in Azure DevOps?

Entering the world of software development can sometimes seem like a monumental challenge, especially when it comes to efficiently managing your source code in collaborative environments. Azure DevOps presents itself as an ideal tool to ease these processes, allowing developers to handle branches and pull requests efficiently. In this guide, we will take you through the process of creating branches and managing pull requests directly in Azure DevOps, thus optimizing your workflow in collaborative projects.

How to create a branch in Azure DevOps?

Branching is a vital part of the development cycle, allowing developers to work in parallel without interfering with each other's work. In Azure DevOps, creating a branch within the portal is an intuitive process.

  1. Branches navigation: Go to the "Repos" section and select "Branches".
  2. Identifying the repository: Make sure you are in the correct repository.
  3. Branch Creation:
    • Select the base branch you want to start from (e.g. main or master).
    • Choose a clear and descriptive name for your new branch, avoiding spaces or special characters.
    • Optionally, associate the branch to a ProductBacklogItem, linking it to a specific ticket or task in the project for effective tracking.

Here's a basic example of what the workflow looks like using Azure DevOps:

git checkout -b NewBranch main

What are pull requests and how are they created?

A pull request is essentially a request to merge changes from one branch to another. This process not only ensures that new code complies with project standards, but also promotes peer review within the team.

  1. Access pull requests: Go to the "Repos" section and select "Pull Requests".
  2. Creating a new pull request:
    • Select the branch containing the changes(source branch) and the branch you want to merge those changes into(target branch).
    • Provide a clear title and detailed description for your pull request.
    • Assign reviewers from the team to make comments (a highly recommended practice in real projects to ensure code quality).
    • You can also tag the pull request or link it to an existing ticket.

The sample code for creating a pull request would look something like the following:

git push origin NewBranch# Create the pull request and specify the reviewer and additional details.

How are comments and approvals handled?

Managing comments is a crucial part of the pull request review process. Here is the procedure for interacting with comments:

  • Reviewer assignment: reviewers can leave specific comments on chunks of code that need to be improved.
  • Improvement annotations: If a reviewer suggests changes, the author of the pull request must reply and, if necessary, implement the necessary modifications.
  • Review statuses: A pull request can be approved, rejected, or placed in a hold status until all outstanding comments are resolved.

Test your understanding

We encourage you to practice creating a new pull request to merge the changes found in the master branch to the new branch you previously created, e.g. AzureBranch. This will allow you to put into practice the concepts learned and solidify your understanding of how Azure DevOps facilitates the continuous flow of integration and development.

Remember, properly managing your branches and pull requests is essential for effective software development - keep exploring and improving your Azure DevOps skills!

Contributions 20

Questions 5

Sort by:

Want to see more contributions, questions and answers from the community?

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

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.

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.

Lo normal es que otra persona diferente al que crea el PR sea la que lo apruebe, para garantizar revisión y calidad.

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

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"

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.

Para configurar pull requests como mandatorios en Azure Repos, debes establecer políticas de rama. Sigue estos pasos: 1. Ve al proyecto en Azure DevOps y selecciona "Repos". 2. Haz clic en "Branches" y localiza la rama que deseas proteger. 3. Haz clic en los tres puntos al lado de la rama y selecciona "Branch policies". 4. Activa la opción "Require a minimum number of reviewers" y establece cuántos revisores son necesarios. 5. 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
a mí si me dejó ![](https://static.platzi.com/media/user_upload/image-11e29967-1e8e-4eb0-9ec6-5d37bef842b5.jpg)

es oro puro estooo…

Una buena práctica es manejar una nomenclatura de la rama con el ticket y Azure la asociará automáticamente, también aplica para los commits.

En el menú aparece la opción de eliminar el brach de origen de los cambios

Se puede etiquetar a los miembros del equipo en le pull Request

Se presenta como una tabla con todas las ramas en filas y las columnas de autor, la columna "Behind/Ahead", "behind" indica que la rama actual tiene cambios anteriores sin fusionar, y "ahead" muestra que la rama actual tiene cambios posteriores que aún no están en la otra rama. Estos términos son útiles para entender la relación y la diferencia en los cambios entre dos ramas en un repositorio