Ignorar los cambios de versión durante las fusiones

Exposition

Esta es una situación en la que me encuentro mucho. Lo primero que hace nuestro equipo en las sucursales de lanzamiento es soltar el sufijo -SNAPSHOT de la versión. Hacemos cambios de última hora según sea necesario, a veces esto incluye realizar cambios grandes. He hecho un mismo logging de git a continuación que muestra esto. (Al final de la pregunta, se muestra un logging más detallado en caso de que ayude a explicar mejor).

 * ea88c23 (release/1.0.0) Fix an embarrasing bug * 5fe35e1 Drop SNAPSHOT in prep for release | * 34433c6 (HEAD -> master) Add important features | * fe41d3b Bump version to 1.1.0-SNAPSHOT |/ * 8dcfc4f Add greet feature * 0337c4c Bump version to 1.0.0-SNAPSHOT * 775277d Inital commit 

Esencialmente, lo que sucede es

  1. Proyecto va a lo largo
  2. Se corta una twig de lanzamiento
  3. En paralelo…
    • La versión ha cambiado en la twig de versiones
    • La versión ha cambiado en la twig de desarrollo activo
  4. Paralelo continuó …
    • Se corrigió un error en la twig de publicación
    • Se agrega una característica en la twig de desarrollo activo

Pregunta

Ahora, ¿cómo puedo hacer que esos cambios de la twig de publicación ( release/1.0.0 ) se reintegren a la twig de desarrollo activa ( master ) limpiamente? Tengo un par de soluciones posibles a continuación, ninguna es terriblemente favorable.

Enfoque ingenuo

 git checkout master git merge release/1.0.0 # Fix conflicts manually 

Tenga en count que este ejemplo se simplifica con un pequeño número de confirmaciones y que la versión solo se encuentra en un solo file, pero en realidad podría haber muchos cambios y muchos files con la versión; debido a esto, el enfoque ingenuo de simplemente fusionar release/1.0.0 en master y arreglar los conflictos debido al cambio de versiones es mucho más difícil y molesto.

Un enfoque un tanto less ingenuo

 git checkout master git merge release/1.0.0 git checkout --ours */pom.xml 

Si todo lo que está cambiando en los files POM es la versión, está bien, pero esto es peligroso porque podría haber otros cambios en los files pom que no sean versiones. Por supuesto, puedes hacer git diff antes de que git checkout --ours */pom.xml esté seguro, pero esto sigue siendo molesto.

Cosecha de la cereza

No entiendo completamente cómo elegir, pero entiendo lo que hace. Un profesional de este enfoque sería que es fácil ignorar el compromiso que no siempre quieres, pero una estafa es que terminas con un montón de compromisos extra, que no es necesariamente malo, pero parece malo.

Tal vez este es el mejor enfoque y estoy nerviosa por nada. Simplemente parece que habrá ocasiones en las que encuentres un problema con una única confirmación (por la razón que sea) y persigues dónde está afectando las cosas, pero si fue escogido (o de una selección) entonces podrías perderte algunos lugares


Registro más completo

 * ea88c23 (release/1.0.0) Fix an embarrasing bug | diff --git a/file b/file | index e98206a..8ab686e 100644 | --- a/file | +++ b/file | @@ -1 +1 @@ | -Hell, World! | +Hello, World! * 5fe35e1 Drop SNAPSHOT in prep for release | diff --git a/pom.xml b/pom.xml | index f755149..3eefcb9 100644 | --- a/pom.xml | +++ b/pom.xml | @@ -1 +1 @@ | -1.0.0-SNAPSHOT | +1.0.0 | * 34433c6 (HEAD -> master) Add important features | | diff --git a/file2 b/file2 | | new file mode 100644 | | index 0000000..e6afbe7 | | --- /dev/null | | +++ b/file2 | | @@ -0,0 +1 @@ | | +Import features | * fe41d3b Bump version to 1.1.0-SNAPSHOT |/ | diff --git a/pom.xml b/pom.xml | index f755149..5902d52 100644 | --- a/pom.xml | +++ b/pom.xml | @@ -1 +1 @@ | -1.0.0-SNAPSHOT | +1.1.0-SNAPSHOT * 8dcfc4f Add greet feature | diff --git a/file b/file | new file mode 100644 | index 0000000..e98206a | --- /dev/null | +++ b/file | @@ -0,0 +1 @@ | +Hell, World! * 0337c4c Bump version to 1.0.0-SNAPSHOT | diff --git a/pom.xml b/pom.xml | new file mode 100644 | index 0000000..f755149 | --- /dev/null | +++ b/pom.xml | @@ -0,0 +1 @@ | +1.0.0-SNAPSHOT * 775277d Inital commit diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..176a458 --- /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +* text=auto diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e69de29 

Parece que esto sucede mucho, encontré una solución a esto mientras escribía mi pregunta.

Desde el fragment de logging 5fe35e1 está el compromiso que no queremos en el master , es el que nos causará problemas.

 * ea88c23 (release/1.0.0) Fix an embarrasing bug * 5fe35e1 Drop SNAPSHOT in prep for release | * 34433c6 (HEAD -> master) Add important features | * fe41d3b Bump version to 1.1.0-SNAPSHOT |/ * 8dcfc4f Add greet feature * 0337c4c Bump version to 1.0.0-SNAPSHOT * 775277d Inital commit 

¡Deshagámoslo!

 git checkout release/1.0.0 git checkout -b port-to-1.1.0 git revert 5fe35e1 # Now port-to-1.1.0 has all the changes we want and none of the ones we don't git checkout master git merge port-to-1.1.0 

Todavía puede tener conflictos, pero no tendrá ninguno de golpear la versión. Este enfoque se puede usar para "deshacerse" de cualquier compromiso que no desee. Su logging ahora será como a continuación. Recuerde, revertir no elimina el compromiso en sí mismo, simplemente deshace todos los cambios que introdujo el compromiso simple. Puede ver a continuación que 5fe35e1 todavía está allí.

 * 6683b44 (HEAD -> master) Merge branch 'port-to-1.1.0' |\ | * 81e9bf5 (port-to-1.1.0) Revert "Drop SNAPSHOT in prep for release" | * ea88c23 (release/1.0.0) Fix an embarrasing bug | * 5fe35e1 Drop SNAPSHOT in prep for release * | 34433c6 Add important features * | fe41d3b Bump version to 1.1.0-SNAPSHOT |/ * 8dcfc4f Add greet feature * 0337c4c Bump version to 1.0.0-SNAPSHOT * 775277d Inital commit