repositorio - git push tag

¿Es posible excluir compromisos específicos al hacer una fusión de git?

Question

Digamos que quiero fusionarme desde una rama de publicación a la rama principal y hay algunas confirmaciones en la rama de publicación que no quiero incluir en la rama principal. ¿Hay alguna manera de hacer la fusión para que una o más de esas confirmaciones no se fusionen?

Mi estrategia hasta ahora es hacer lo siguiente (en master):

git merge --no-commit release-branch
# Resolve conflicts and apply reverse patch of the commits that I don''t want included
git commit # Edit commit message so that it lists the commits that have been reverse-patched

¿Hay una mejor manera de hacer esto?

Answer 1

Cree una nueva bifurcación, vuelva a establecer la bifurcación de la bifurcación de forma interactiva y descarte las confirmaciones que no desea, y luego fusione eso.

No puede sacar los cambios de la mitad de una rama sin volver a generar los cambios, pero lo correcto ocurrirá cuando vea los mismos cambios en una fusión posterior (por ejemplo, de la selección selectiva y otras cosas).

Answer 2

Encontré una solución que funciona para mí en el libro de Pro Git .

Digamos que quiere excluir el archivo config.php .

En la rama A:

1. Cree un archivo llamado .gitattributes en el mismo directorio, con esta línea: config.php merge=ours . Esto le dice a git qué estrategia usar al fusionar el archivo. En este caso, siempre mantendrá su versión, es decir. la versión en la rama en la que se está fusionando.

2. Agregue el archivo .gitattributes y .gitattributes

En la rama B: repita los pasos 1-2

Intenta fusionar ahora. Su archivo no debe tocarse.

Answer 3

La razón por la que esto no se puede hacer directamente es que cada confirmación contiene enlaces a las confirmaciones principales (generalmente solo una, pero varias para las fusiones). De esta forma, si tiene una confirmación (por su suma SHA1), la historia completa también se corrige ya que los padres también contienen enlaces a sus padres, etc. Entonces, la única manera de dejar de lado los parches en la historia es escribir uno nuevo. git rebase -i en una rama recién creada es probablemente la forma más fácil de lograr eso.

Answer 4

Si solo quiere excluir algunas confirmaciones que están al final, puede comprometerse con un número de confirmación específico:

git checkout partlyMergedFrom
git whatchanged
--> find the commit hash up to where you want to merge
git checkout partlyMergedInto
git merge e40a0e384f58409fe3c864c655a8d252b6422bfc
git whatchanged
--> check that you really got all the changes you want to have

Answer 5

Si tiene una sucursal de soporte donde corrige errores y crea nuevas versiones. En Master tienes la próxima versión donde también creas nuevas versiones con frecuencia.

Cada vez que construyes una nueva versión, cambias la versión en algún archivo, comprometes ese nuevo archivo, creas una etiqueta y presionas. Ahora las fusiones de soporte a maestro siempre tendrán conflictos en el archivo que contiene la información de la versión.

Si el archivo que contiene la información de la versión solo contiene la información de la versión, puede ir con la respuesta de fcurella. Pero si también puede contener información fusionable (pom.xml, gradle.properties, MANIFEST.MF, ...), debe realizar alguna acción adicional.

Vamos a usar el siguiente ejemplo

      C---D*---E---F* support
     /
A---B---G---H*---I master

donde las confirmaciones con estrellas contienen solo cambios debidos a cambios de versión que deben ignorarse durante la fusión.

Para combinar el soporte en el maestro sin conflictos de fusión debido a las compilaciones de versión, puede hacer lo siguiente:

Múltiples combinaciones de fusión

git checkout master
git merge C
git merge D -s ours
git merge E
git merge F -s ours

Con el argumento -s ours decimos a git que solo grabe una fusión sin alterar el espacio de trabajo. Esto es comparable a la opción --record-only de svn .

Lo anterior dará como resultado el siguiente diseño

      -------------C---D*---E---F* support
     /              /   /    /   /
A---B---G---H*---I---J---K----L---M master

Una fusión se compromete usando cherry-pick

git checkout master
git merge support -s ours --no-commit
git cherry-pick C E --no-commit
git commit -m ''merged support into master''

primero estamos comenzando una fusión, pero solo registramos que estamos fusionando, sin alterar el espacio de trabajo y sin hacer la fusión. Luego, seleccionamos los commits para fusionarnos, nuevamente sin compromiso. Finalmente estamos comprometiendo la fusión.

Lo anterior dará como resultado el siguiente diseño

      C---D*---E---F* support
     /              /
A---B---G---H*---I---J master

Incluso se podría automatizar la recolección de cerezas.

git checkout master
git merge support -s ours --no-commit
for id in `git log support --reverse --not HEAD --format="%H [%an] %s" |
  grep -v "bump version" |
  sed "s//(/w*/)/s.*//1/g"`
do
  git cherry-pick --no-commit $id
done
git commit -m ''merged support into master''

Answer 6

También es posible modificar el archivo .git / info / attributes y mantenerlo dentro de la carpeta .git en lugar de agregar todos los archivos .gitattribute que requerirán agregarlos eventualmente al control de código fuente.

Answer 7

La pregunta principal es: ¿cómo quieres representar las confirmaciones que quieres omitir?

1. ocultarlos furtivamente (no es mi favorito)
2. omítalos explícitamente
3. explícitamente deshacerlos

Lamentablemente no. 2 es imposible de expresar en el gráfico de historia.

No. 1 es posible, pero nunca lo haría: una confirmación de fusión puede contener cambios. - Normalmente, una fusión confiere puntos al resultado de la fusión de dos ramas más: todas las cosas desarrolladas en esas ramas deben estar en el código después de la fusión (es decir, en el código al que apunta el compromiso de fusión). Y nada más debe estar en este compromiso.

Pero sorpresa, sorpresa, puede cambiar toda la base de códigos y representarla como una combinación. El efecto de una combinación es doble: fusiona el árbol de historial y debe unir dos bases de código. El primero lo hace con certeza (de lo contrario, nadie lo llama fusión), porque este último podría fallar, por ejemplo, cuando surgió un conflicto de fusión y se resolvió incorrectamente (entonces las bases del código no se fusionaron correctamente).

Algunas de las otras respuestas sugieren este escondite. Recomiendo la forma explícita: fusionar más revertir confirmaciones.