Flujo completo de merge requests en GitLab
Contenido del curso
Alexis Otaño
Alexis David Sánchez Niaupari
GUSTAVO GALVIS
Robert Vivar Vivanco
Jesús Rubén Esparza Soto
Marcelo Javier Pedernera
Javier Guerrero
Anibal Rojas
Profesor
Francisco García
ELEAZAR CURIEL MONJARAZ
Alberto Navarro Pérez
Wilmer Ariel Moina Rivera
Pablo Aquino
ELEAZAR CURIEL MONJARAZ
Arturo Escamilla García
Santiago Montoya Garcia
Edwin Garcia
Amilcar Benitez
Santiago Montoya Garcia
Daniel Alfredo García Serna
Anderson Barreto Briñez
Juan Stiven Muñoz Garcia
Carlos Javier Cepeda
Rodolfo G
Ariel Noguera
Rosa Mø
Erick Saravia
Gonzalo Amador Hernández
Julio Enrique López Marin
Company_admin
Aaron Santiago Loyo Zabala
Yoana Marrero Rodriguez
Cherry-Pick no es de gitlab si no que es de git, permite pasar un commit de cualquier rama y "pegarlo en otra", no necesariamente actual si no de cualquier momento de la historia.
Freddy dice que es una mala practica =/
Lo que diga Freddy va a misa. No es burla, lo digo neta jaja
Hoy en día ya no aparece el prefijo WIP:, ahora es Draft:
Cherry-Pick, es una mala practica, permite pasar un commit de cualquier rama y “pegarlo en otra”.
A pesar de ser mala práctica tiene sus usos muy específicos pero muy útiles, en general, si lo usas, algo estás haciendo mal.
En algunas situaciones al estar trabajando en diferentes ramas de nuestro proyecto, nos hemos encontrado con situaciones en donde solo queremos capturar un commit en específico de una rama y pasarla a la otra, ya que no queremos hacer un merge entre ambas ramas porque estarían pasando otros cambios que no deseamos. Para estos casos nos puede ayudar el comando “cherry-pick”
Muy interesante el concepto de "merge request". En mi flujo de trabajo para el repositorio, actualmente trabajo con git-flow:
Mi pregunta es: ¿en un ciclo devops tiene sentido usar git-flow?
Saludos!
Interesante pregunta. Creo que depende mucho de cómo estás pensando que se integraría en el flow. En principio no hay ningún motivo para que no lo haga. Saludos de regreso
Cherry-pick es un comando de git que nos apoya a pasar un commit especifico de una rama otra sin la necesidad de aplicar un merge.
Cuando actualizan el curso con la versión actual de gitLab?, este video fue de hace 3 años pasaditos hoy todo es diferente
Un ejemplo claro de cherry-pick
APLICAR UN COMMIT A OTRA RAMA CON GIT CHERRY-PICK
https://frontendlabs.io/3084--aplicar-un-commit-otra-rama-con-git-cherry-pick
Cherry-Pick es una mala practica, y si la aplicas debería ser para tu entorno local.
A mi no me aparece el tags de Pepeline
Es por que hiciste tu proyecto privado, tiene que ser publico para que puedas acceder a esta función.
Es por que ya cambiaron la configuracion, supuestamente viene por defecto activada, pero en mi proyecto aparecio Desactivada (es un proyecto publico) Para habilitarlo es si no ir a Settings; CI / CD ; Expand Auto DevOps y activas ‘Default to Auto DevOps pipeline’
A mi no me sale lo de pipelines.¿A que se debe?
A mi me pasa igual
Es por que ya cambiaron la configuracion, supuestamente viene por defecto activada, pero en mi proyecto aparecio Desactivada (es un proyecto publico) Para habilitarlo es si no ir a Settings; CI / CD ; Expand Auto DevOps y activas 'Default to Auto DevOps pipeline'
📚 Nombre de la clase
Flujo completo de Merge Requests en GitLab
🎯 Idea principal
El flujo de Merge Requests en GitLab define el proceso completo desde la creación de una rama hasta la integración del código en la rama principal. Incluye desarrollo, revisión, validación automática y aprobación antes del merge. Este flujo garantiza calidad, colaboración y control en cada cambio. El objetivo es establecer un proceso estándar para integrar código de forma segura.
⚡ Síntesis en 10 segundos
🔑 Puntos clave
🧠 Conceptos importantes
🧩 Modelo mental de la clase
Rama → Desarrollo → MR → CI/CD → Revisión → Aprobación → Merge
Idea clave: Cada cambio sigue un proceso controlado antes de llegar a producción.
🚀 Acciones inmediatas
💼 Aplicación profesional
Impacto real: procesos más seguros, ordenados y profesionales.
🔥 Hacks para la comunidad
📝 Reflexión estratégica
El flujo define la calidad del resultado. Un proceso bien diseñado evita errores antes de que ocurran.
Los equipos profesionales no improvisan cómo integrar código, lo estandarizan.
es posible hacer un merge-request a una rama que no sea main o master, en si a otra rama distinta??
Existe una manera de que al manejar los merge request se añada automáticamente al changelog los añadido ya sea con diferentes etiquetas ejemplo el draf: no sea draf: si no algo como fix/ or break/ or feature/ y se añade a esa parte del changelog. por cierto quisiera que alguien me de indicios de el manejo completo de esta parte se que gitlab tiene estas grandiosas herramientas
En este punto del curso, cuando abro el detalle del merge-request, no me aparecen los widget ya que no veo asociado un pipeline, alguien me pasa es codigo por favor.
Pasa que la versión que esta mostrando en pantalla es old. De todas formas es bastante similar(salvo algunos cambios de front y demas). Respecto al pipeline porque quiza no tengas .gitlab-ci.yml de configuracion.
no me aparece el comando "open in web IDE"
Yo normalmente uso gitflow, en mis repositorios, me parese interesante ese formato de crear los merge requests de acuerdo a los issues, principalmente por que creando las ramas manualmente siempre apunta a la rama principal. Mi duda es como configurar gitlab para que cree las ramas desde el issue segun el nombre que se le coloca en la configuracion por que en mi caso siempre lo sobreescribe, es decir ignora el nombre personalizado que le doy a la rama, y le coloca el nombre del issue.
Por ejemplo si yo creo un issue: "Issue 1", y creo el el merge request de este, pero le coloco a la rama un nombre como "feature/issue-1"
GitLab ignora el nombre que le di y la crea como: #-issue-1
Como se puede arreglar eso? se supone que si esta la opcion de colocar el nombre de la rama se deberia de poder hacer
Como algunos mencionan ya Cherry-pick es una Mala practica, yo lo he usado como ultimo recurso de emergencia, cuando mecesito un commit de un MR que aun no se ha terminado, pero necesito un cambio, pues solo hago un cherry pick. si lo haces demaciado, algo no va de la forma correcta
Cherry-pick es tomar un commit de una rama y aplicarlo a otra. Esto es muy útil cuando por error involuntario se hace commit sobre la rama equivocada, mediante el comendo cherry-pick se puede hacer el intercambio hacia la rama correcta.
Ya lo dijeron hace 4 años
Cherry pick es una funcionalidad que nos permite coger un commit de un branch y aplicarlo en otro branch.
