No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Compra acceso a todo Platzi por 1 a帽o

Antes: $249

Currency
$209/a帽o

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscr铆bete

Termina en:

16D
7H
22M
42S

Creando ramas y pull request

13/20
Recursos

Aportes 15

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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.

En la siguiente clase se viene lo chido!

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.

Pull Requests: La traducci贸n directa ser铆a algo as铆 como 鈥淧etici贸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.

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.

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 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

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

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"