git - and - merge commits in pull request

Git branch--merged/--no-fusionada y--squash option

Question

git branch --merged no parece jugar muy bien con --squash.

Si haces una git merge normal, entonces git branch --merged te dice qué ramas se han fusionado. Sin embargo, este no es el caso si se usa la opción --squash, aunque el árbol resultante sea el mismo.

Dudo que sea un defecto de Git y me gustaría saber si me falta algo, o si he entendido mal algo.

En resumen: quiero usar --squash, pero también quiero que git me diga si la rama que aplasté en otra ha sido - fusionada.

Answer 1

No puedes llegar allí desde aquí (como dijo el compañero que da indicaciones). Más precisamente, no tiene sentido.

El problema es que git merge --squash realidad no hace una fusión. Supongamos que el historial de su sucursal se ve así, por ejemplo (con ramas topic y devel ):

          H ⬅ I ⬅ J     <-- topic
        ⬋
⬅ F ⬅ G
        ⬉
          K ⬅ L         <-- devel

Si revisas el topic devel y fusión, obtienes una nueva combinación de compromiso M que contiene el resultado de la fusión, y M tiene dos padres:

          H ⬅ I ⬅ J     <-- topic
        ⬋         ⬆
⬅ F ⬅ G           ⬆
        ⬉         ⬆
          K ⬅ L ⬅ M     <-- devel

Pero si usas git merge --squash topic , obtienes un nuevo commit (vamos a etiquetarlo como S para squash):

          H ⬅ I ⬅ J     <-- topic
        ⬋
⬅ F ⬅ G
        ⬉
          K ⬅ L ⬅ S     <-- devel

donde (como ya lo anotó) los contenidos (el árbol) de commit S hace que todos los archivos salgan igual que en commit M Pero no hay back-link (flecha principal) de S a topic . No se trata de una combinación, simplemente está eliminando todos los cambios del topic , aplastándolos en un solo cambio y agregando eso como un compromiso completamente independiente.

Ahora, la otra cosa sobre git merge --squash es que no hace el commit final. Así que podrías crear los archivos .git que git usaría en una fusión "normal", y hacer una confirmación que tenga los dos padres que obtendrías en una fusión "real". Y entonces obtendrías ... exactamente lo que obtienes si ejecutas git merge topic , un commit (lo etiqueta S o M , no importa) que tiene el mismo árbol otra vez, pero ahora tiene dos flechas padre, apuntando a L y J , al igual que M

De hecho, ejecutar git merge --squash es casi exactamente lo mismo que ejecutar git merge --no-commit , excepto por los archivos de rastreo que quedan cuando se realiza la fusión ( git commit usa algunos de estos para configurar los padres). La versión de squash no escribe en .git/MERGE , .git/MERGE_HEAD , y .git/MERGE_MODE . (Crea .git/MERGE_MSG , lo mismo que git merge --no-commit , y también crea .git/SQUASH_MSG .)

Entonces, básicamente, usted tiene su opción: una combinación real (dos o más padres en el compromiso final), o un squash (los mismos mecanismos de combinación de árbol, pero solo uno de los padres en el compromiso final). Y, como git branch --merged funciona mirando las "flechas padre" de cada confirmación almacenada en el repositorio, solo una combinación real es realmente una fusión, por lo que solo una fusión real puede ser descubierta más tarde por git branch .