Prueba hacer cherry-pick de un PR de GitHub

• Ya van 4 meses desde que empezamos a usar un mono-repository dentro de la empresa
• Junto con el mono-repository, también estamos aplicando trunk-based development, una palabra clave que siempre viene de la mano con este enfoque
• Siguiendo la estrategia de trunk-based development, usamos un flujo en el que se hace commit a la rama main y luego se hace cherry-pick hacia la rama release
• Configuramos una GitHub Action basándonos en el contenido del blog técnico de LinkedIn, pero no puede resolver CONFLICT automáticamente. Cuando ocurre un CONFLICT, el usuario tiene que ejecutar por su cuenta el comando git cherry-pick en local
• Por eso hice directamente un plugin de gh para ayudar con este comando cherry-pick.

Uso

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• Con la opción -merge, se puede elegir si hacer cherry-pick del merge commit del PR o de los commits originales del PR
  • Si no se especifica o se usa la opción -merge=auto, inspecciona automáticamente la estrategia con la que se hizo merge del PR y la aplica
• Con la opción -push, si el cherry-pick se completa con éxito, también hace push automático al remoto

Comentarios finales

• Al desarrollar un programa que interactúa continuamente con procesos y estados externos, creé un repositorio de pruebas por separado para generar un dataset de pruebas
  • Me ayudó la experiencia previa de haber contribuido a los proyectos libgit2 y refined-github
• Varias cosas que estudié para mejorar la experiencia de uso del CLI
  • Me sirvió haber estudiado por mi cuenta cómo hacer algo como docker-cli
• Hacer un programa CLI requiere bastante más trabajo de lo que parece
  • Gestionar muchos valores de estado en una estructura de tipo pipeline
  • Ofrecer al usuario una interfaz de entrada intuitiva
  • Proveer validación de entrada lo más temprano posible
  • Restaurar el sistema del usuario a su estado original, etc.
  • Pensé que podría hacerlo en alrededor de un día, pero terminó tomando unos 5 días (aunque en paralelo también avancé en mejoras al workflow de GitHub Actions, igual tomó muchísimo más tiempo de lo esperado)

[qncnxnlrla]

Hola, ¿cómo manejan los casos en que necesitan hacer revert de un commit mergeado a la rama main(trunk)?

• Si hacen revert en la rama main, ¿también hacen cherry-pick a la rama release?
• ¿Agregan un commit de corrección sin usar revert?

Parece que, si se han acumulado muchos commits y aparecen conflictos, puede haber casos en los que sea difícil hacer cherry-pick. ¡Me gustaría saber si han tenido experiencia manejando casos así!

[a1eng0]

¡Hola! Gracias por dejar tu respuesta.

¿Cómo lo manejan cuando es necesario hacer revert de un commit que ya fue mergeado a la rama main (trunk)?

En el PR de revert que subimos a la rama main especificamos el cherry-pick. Como todo el historial de cherry-pick queda en el enlace del PR original, no hay ninguna dificultad para hacer el seguimiento. No hacemos ninguna verificación mecánica por separado jaja.

Cuando se han acumulado muchos commits y ocurre un conflicto, hay casos en los que hacer cherry-pick resulta difícil

En principio, si haces trunk-based development, cada PR es una unidad pequeña, así que los conflictos no ocurren con frecuencia. Si llega a haber un conflicto, entonces hay que escribir el código manualmente. Hacemos release con mucha frecuencia para evitar que el soporte a versiones demasiado antiguas se depreque rápido y que la estructura del código cambie demasiado.

[lamanus]

La verdad, no entiendo muy bien por qué sería necesaria esta estrategia...

[a1eng0]

Creo que te puede ayudar a entenderlo si lees el contenido presentado en release-from-trunk jaja