Creando ramas y pull request

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.

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

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

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.

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

Asociación importante entre el branch y el ticket no permitirá saber en que pendientes estamos trabajando

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

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"