Trabajamos como sigue en nuestro equipo:

tenemos solo unmaster Rama en nuestro repositorio de GitHub, no es estable; piensa que todos los días son empujados allí; para versiones estables usamos etiquetas (para desarrollo, usamos bifurcaciones privadas en GitHub)lanzamos una nueva versión secundaria cada 3 semanas, que contiene correcciones de errores y nuevas características (por ejemplo, 1.2.4, 1.2.5, 1.2.6 ...)también tenemos que mantener cada versión antigua menor por un tiempo limitado (algunos meses), por lo que cuando alguien usa 1.2.4, mientras que la versión más reciente es 1.2.7, y encuentran un error, pueden solicitarnos que corrijamos el error. En la rama que usan. Entonces lanzamos unversión de parche, 1.2.4A.Los parches son bastante excepcionales. Por lo general, no hacemos más de 1-2 parches para la versión secundaria. Para la mayoría de los lanzamientos no hacemos parches.

La pregunta es, ¿cuál es la mejor estrategia para corregir el error en el maestro y la antigua rama al mismo tiempo?

Puedo pensar en las dos estrategias principales:

Arreglar el error enmaster, luego la salidav1.2.4, entoncesselección de cereza la confirmación apropiada (suponga que la corrección de errores es una confirmación que siempre se cumple) y etiquete la confirmación resultante comov1.2.4A.

Revisav1.2.4, corregir el error y cometer, etiquetar el cometer comov1.2.4A, y para incorporarlo amasterhacer ununir.

Estoy más a favor de la primera versión (pick-cherry), pero me gustaría escuchar los comentarios del otro sobre los pros y los contras.

Por supuesto, las cosas pueden complicarse cuando los compromisos en el medio introducen algunos cambios importantes que pueden resultar en el hecho de que uno no puede crear un compromiso que funcionará tanto en la versión 1.2.4 como en la principal. (por ejemplo, cuando un nombre de función cambió o cosas más complicadas). Pero la situación más común es que la solución se puede portar sin problemas.

Ventajas de la cosecha de cerezas del maestro:

Creo que la historia es más "comestible" con la selección de cerezas. Considera esto:

| <- bugfix done on master
|
|
| <- v1.2.7
...
|
|
|
|
|
|
|
|
|
|  - <- v.1.2.4A (cherry-picked from master)
| / 
| <- v1.2.4

vs esto:

| <- bugfix merged to master
|\ 
| \
|  |
|  |   <- v1.2.7
...
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  - <- v.1.2.4A (direct bugfix)
| / 
| <- v1.2.4

Piensa en tener docenas de compromisos en el medio. Considere tener varios parches aplicados de esta manera en paralelo. La mitad de la pantalla estará contaminada.

Digamos que solucioné un problema env1.2.4, pero en unos días alguien me pide un parchev1.2.3. Cherry-pick es la forma más sensata de hacerlo.

¿Hay ventajas de fusionar en nuestro caso que pasé por alto? Puedo entender que preserva la conexión entre los dos compromisos mejor que la selección de cerebros, pero mantenemos una documentación de los lanzamientos y todo esto también se rastrea allí.