git - una - ¿cómo borrar ramas con contenido?




Git: fusionar solo los cambios realizados en la rama. (2)

No hay ningún peligro real en el uso de cherry-pick, especialmente si no planea fusionar la rama de release con el master .

En general, puede evitar problemas como estos al basar las correcciones de errores en las confirmaciones que se incluyen en todas las ramas en las que desea fusionar la corrección. En el desarrollo de git en sí mismo, esto se logra al fusionar todas las correcciones de errores en la rama maint (es decir, la serie estable actual que solo recibe correcciones) y luego combinarlas en el master periódicamente. De esa manera, la solución está en todas partes y las fusiones son sensatas.

  G---H             // Release Branch
 /
/
A---B---E---F---    // master
    \
     \
      C---D---     // bug fix branch

Basado en nuestras necesidades particulares para nuestro proyecto, es bastante común que ocurra el escenario anterior. Tenemos nuestra rama master / dev con algunos compromisos. Luego obtenemos un informe de error y comenzamos a solucionarlo en la rama del error (confirma C y D arriba). Mientras tanto, más compromisos ocurren en la rama de desarrollo. A continuación, se nos dice que debemos crear una versión para un cliente que no pueda incluir los cambios introducidos por los compromisos B, E y F anteriores, pero debe incluir la corrección de errores.

Así que nos desviamos del desarrollo antes de que se haya aplicado el cambio B, pero ¿cuál es la mejor manera de corregir el error en esta versión de la versión? Si realizo una fusión de la rama, incluirá el cambio que se realizó en B, que no deseo. Podría realizar una selección de las confirmaciones C y D, pero leí que la selección de cerezas no siempre es una buena idea basada en esta respuesta básicamente porque mi repo se vería así:

  G---H---C'---D'--- // Release Branch
 /
/
A---B---E---F---     // master
    \
     \
      C---D---       // bug fix branch

Así que C 'y D' aparecen como compromisos completamente nuevos con diferentes ID de sha-1 como C y D. ¿Es esto realmente algo malo? ¿A qué problemas puede conducir esto? ¿Hay una mejor manera de obtener los cambios de la rama de corrección de errores en la rama de lanzamiento?


Nota: como se explicó anteriormente, la selección de cerezas es aceptable aquí.
Sus principales inconvenientes son:

  • en caso de fusión, obtendrías un conflicto debido a confirmaciones duplicadas
    Consulte " Git cherry pick and datamodel integridad "
  • Ignorar dependencias funcionales.
    Consulte " Cómo fusionar un commit específico en git ".

En tu caso:

  • no hay necesidad de fusionarse de nuevo.
  • Si está seguro de que C y D no se basan en el código introducido en B , ... escojalos donde los necesite.




git-branch