El 14 de septiembre de 2017, publicamos una versión revisada de nuestra Política de privacidad. Tu uso continuado de video2brain.com significa que aceptas este documento revisado, por lo que te recomendamos que dediques unos minutos a leerlo y comprenderlo.

GitLab esencial

Merge requests en GitLab

Prueba ahora LinkedIn Learning sin cargo y sin compromiso.

Prueba gratis Mostrar modalidades de suscripción
Cuando tienes colaboraciones en el proyecto, no tienes por qué permitir que todos modifiquen directamente el código, sino que puedes usar el sistema de merge requests. Puedes recibir proposiciones de modificación de código y, en función de tu criterio, comentarlas, modificarlas, aceptarlas o rechazarlas.

Transcripción

Normalmente, en los proyectos de programación en los que hay colaboradores no se realizan todos los cambios directamente sobre la rama principal, si no sobre ramas secundarias correspondientes a alguna nueva funcionalidad y luego se fusionan sobre la rama Máster. No solo por facilidad de gestión sino porque también es posible que haya colaboradores que no queremos que tengan acceso directo a realizar cambios en nuestra rama Máster. Para ello, normalmente, lo que se hace es darles permiso para crear ramas, branches, en un proyecto de software. Crearlas con los contenidos de los cambios que ellos quieren fusionar y después nosotros como administradores podemos aceptar esos cambios. Normalmente será directamente el programador que ha creado esta rama y ha agregado esta funcionalidad el que creará lo que se llama un Merge Request. Suponiendo que soy yo un programador que colabora con este proyecto y que tengo determinados cambios en la rama Cliente 1 que quiero fusionar en la rama principal, en Máster, que vemos que está dos commits más adelante, que tiene dos commits de diferencia con la rama Máster, podría hacer dos cosas. La primera compararlo para asegurarme de que esta es la rama que yo quiero fusionar con la Máster. Vemos que estamos comparando la rama Máster con la rama Cliente 1, que tiene dos commits de diferencia. Y aquí abajo están las diferencias, una es el fichero de imagen que hemos subido y otra es el fichero de texto con todas las lineas adicionales en verde. Dado que esta es la branch que queremos fusionar, lo que hacemos es pulsar en el botón Create Merge Request que lo que hace es crear una petición de fusión de ramas. El título normalmente nos lo auto completa con el nombre de la rama que queremos fusionar. Podemos agregarle algún código si tuvieramos algún número de incidencia que se corresponde con este Merge Request y debajo una explicación o una descripción sobre a qué corresponde esta fusión de código que estamos haciendo. Debajo podemos asignárselo directamente a un administrador si sabemos quien es reponsable de recibir los Merge Request. Yo me la voy a asignar a mí mismo, que soy el administrador de este repositorio. Podríamos incluso asignarlo a un Milestone o a una versión objetivo de nuestro software. Crear alguna etiqueta, pues para decir si es un bug o es una funcionalidad o algún problema. Revisamos que la rama origen y la rama objetivo son en efecto las que queremos fusionar. Y tenemos una opción final que sería eliminar esta rama cuando se ha aceptado la petición de fusión. Esto es, si las ramas que estamos creando son solo para poner nuestros cambios y después fusionarnos con la principal, una vez hemos fusionado esas dos ramas, la rama secundaria que habíamos creado no nos interesa, podemos borrarla. Entonces podemos decirle a Gitlab que la borre directamente en cuanto acepte nuestros cambios. De momento nosotros la vamos a dejar aquí. Aquí lo que haríamos sería hacer una petición al administrador para que acepte nuestra rama. Y yo, como administrador que soy, ahora tengo una notificación de que tengo un trabajo pendiente. Si yo pincho, vemos que tengo una Merge Request pendiente que precisamente me la he asignado yo mismo. Si pinchamos en ella vemos que tenemos un hilo de conversación debajo. Podemos votarla positivo o negativo o ponerles algún emoji concreto y comentar con el desarrollador si hay problemas. en esta rama o si hay algo que no entendemos. El desarrollador que nos ha mandado los cambios u otros desarrolladores del proyecto que tienen permisos, en el mismo podrían realizar comentarios sobre la Merge Request para debatir o comentar cuales son los problemas o las dudas que tienen. Y terminado el debate podemos hacer dos cosas Una es cerrar el Merge Request, que esto quiere decir, que no nos vale; que no lo aceptamos, que no aceptamos los cambios de este código. Este Merge Request todavía se puede comentar, alguien podría darnos un dato adiccional que nos hiciera aceptarlo, con lo cual podemos volver a abrirlo y cuando estamos seguros de que queremos aceptar los cambios del código, podemos hacer la aceptación del Merge Request. Nosotros como administradores podríamos hacer lo mismo, hacer un click en esta opción para que cuando aceptemos este Merge Request se borre la rama secundaria de la que estamos aceptando los cambios. Ya tenemos este Merge Request como aceptado. Vemos que ha cambiado a azul, como que es Merged, que se ha fusionado con nuestra rama principal. Y si venimos a la actividad de nuestro repositorio vemos que Álvaro González, que soy yo, ha fusionado a la rama Máster otra rama con un Merge Request. La rama Cliente 1 a la rama Máster. Y si volvemos al proyecto, a los ficheros, vemos que ya tenemos el logo y los ficheros md que habíamos creado. Las branches, como no hemos borrado la otra, aún la seguimos teniendo aquí. Si nos fijamos, ahora, Cliente 2, que es otra rama secundaria que teníamos, tiene más diferencias con Máster que antes porque hemos cogido los cambios de cliente 1 y los hemos fusionado con Máster. Este es básicamente el flujo de trabajo que tenemos para funcionar con rama. Para crear las Merge Request, para recibir las peticiones y para aceptarlas o denegarlas si aceptamos o no los cambios que recibimos.

GitLab esencial

Aprende a instalar y administrar GitLab, bien en tu propio servidor o en un servicio web gratuito o de pago, y cómo crear un perfil y generar tu primer proyecto en GitLab.

3:14 horas (47 Videos)
Actualmente no hay comentarios.
 
Fecha de publicación:27/10/2016

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.