Git merge sin auto commit

404

¿Es posible hacer un git merge, pero sin un compromiso?

"man git merge" dice esto:

With --no-commit perform the merge but pretend the merge failed and do not autocommit,
to give the user a chance to inspect and further tweak the merge result before
committing.

Pero cuando trato de usar git mergecon los --no-commitque todavía auto-commit. Esto es lo que hice:

$> ~/git/testrepo$ git checkout master
Switched to branch 'master'

$> ~/git/testrepo$ git branch
* master
  v1.0

$> ~/git/testrepo$ git merge --no-commit v1.0
Updating c0c9fd2..18fa02c
Fast-forward
 file1 |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

$> ~/git/testrepo$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Un posterior git logrevela todos los commits de la rama v1.0 fusionados en master.

git

— selbie
fuente

618

Tenga en cuenta la salida al hacer la fusión, es decir Fast Forward

En tales situaciones, desea hacer:

git merge v1.0 --no-commit --no-ff

— manojlds
fuente

77

¿Qué pasa si hay un conflicto?

— Jürgen Paul

20

@PineappleUndertheSea Los reenvíos rápidos nunca causan conflictos. En caso de fusión "real" sin avance rápido, el --no-commitcambio es efectivo solo si no ocurre un conflicto, en caso de conflicto, git nunca se auto-confirmará.

— gronostaj

38

FYI: si desea fusionar los cambios y luego confirmar como si hubiera escrito manualmente todos los cambios que fusionó (en lugar de una fusión tradicional), debe ejecutar rm .git/MERGE_HEADdespués, lo que obligará a git a olvidar que se produjo la fusión.

— Jonn

77

FYI: Aquí hay una salida de muestra para una fusión exitosa:Automatic merge went well; stopped before committing as requested

— kevinarpe

66

Aparentemente git merge BRANCHENAME --no-commit --no-ffdejé mi espacio de trabajo en un estado git "FUSIÓN". No del todo seguro de lo que hace exactamente, pero un simple git stash savey git stash popciclo pareció volver todo a la normalidad; con solo los archivos modificados de la rama de destino en su lugar según lo previsto, y ya no tiene un estado MERGING.

— MoonLite

49

Estás malentendido el significado de la fusión aquí.

Esto --no-commitevita que ocurra el COMPROMISO DE FUSIÓN, y eso solo sucede cuando fusiona dos historias de rama divergentes; en su ejemplo, ese no es el caso, ya que Git indica que fue una fusión de "avance rápido" y luego Git solo aplica las confirmaciones ya presentes en la rama de forma secuencial.

— Samus_
fuente

12

Eso no (necesariamente) aclarará necesariamente la confusión; Creo que este es un momento (relativamente raro) en que los documentos son realmente claros: git help merge=> "Con --no-commitrealizar la fusión pero pretender que la fusión falló y no autocomprometirse, para darle al usuario la oportunidad de inspeccionar y ajustar aún más el resultado de la fusión antes de comprometerse. " La clave, por supuesto, es usarlo junto con--no-ff

— michael

66

... tal vez sería menos confuso romper con una terminología estricta y describirlo de esta manera: una "fusión de git" que hace un avance rápido no tiene una confirmación de fusión porque en realidad no hay una fusión. De hecho, esta es la situación ideal: los avances rápidos son una buena cosa, y no tener este "compromiso de fusión" adicional tiene sentido. Este es un buen comportamiento predeterminado y no debe deshabilitarse. (En el lenguaje apropiado, un avance rápido es un tipo de fusión, pero no es una "verdadera fusión".)

— Michael

44

es relativo a las políticas del proyecto, en algunos casos es útil tener / forzar esos "compromisos de fusión" adicionales incluso cuando es un ff porque necesita marcar la inclusión de la característica en la rama principal.

— Samus_

77

...qué. Muy bien, creo que git es prácticamente inalcanzable. Esta respuesta en particular me ha convencido de probar Mercurial.

— Brian Gordon

24

Si solo desea confirmar todos los cambios en una confirmación como si hubiera escrito usted mismo, --squash también lo hará

$ git merge --squash v1.0
$ git commit

— Adrian Li
fuente

1

¿Es este el mismo efecto quegit merge v1.0 --no-commit --no-ff

— Jpierson

2

No, efecto diferente. Squash crea un nuevo commit con un nuevo hash. Combina todos los commits en una rama en un commit para la fusión.

— Kavi Siegel

23

Prefiero de esta manera, así que no necesito recordar ningún parámetro raro.

git merge branch_name

Luego dirá que su rama está " #" adelante con los commits, ahora puede quitar estos commits y ponerlos en los cambios de trabajo con lo siguiente:

git reset @~#

Por ejemplo, si después de la fusión es 1 commit adelante, use:

git reset @~1

Nota: en Windows, se necesitan comillas. (Como Josh señaló en los comentarios) por ejemplo:

git reset "@~1"

— Bolita
fuente

44

En Windows, se necesitan citas:git reset "@~1"

— Josh

1

Cuando hay una confirmación solo en la rama, generalmente hago

git merge branch_name --ff

— Sithu
fuente