git-merge: en línea en la nube

PROGRAMA:

NOMBRE

git-merge: une dos o más historias de desarrollo juntas

SINOPSIS

git unir [-n] [--stat] [--no-commit] [--squash] [- [no-] editar]
[-s ] [-X ] [-S[ ]]
[- [no-] volver a actualizar automáticamente] [-m ] [ ...]
git unir CABEZA ...
git unir --abortar

DESCRIPCIÓN

Incorpora cambios de las confirmaciones nombradas (desde el momento en que sus historias divergieron de
la rama actual) en la rama actual. Este comando es utilizado por git recogida a
incorporar cambios de otro repositorio y se puede utilizar a mano para fusionar cambios de
una rama a otra.

Suponga que existe el siguiente historial y que la rama actual es "maestra":

Tema A --- B --- C
/
D --- E --- F --- G maestro

Luego, "git merge topic" reproducirá los cambios realizados en la rama del tema ya que divergió
desde el maestro (es decir, E) hasta su compromiso actual (C) en la parte superior del maestro, y registre el resultado
en una nueva confirmación junto con los nombres de las dos confirmaciones principales y un mensaje de registro del
usuario describiendo los cambios.

Tema A --- B --- C
/ \
D --- E --- F --- G --- H maestro

La segunda sintaxis ( CABEZA ...) se apoya por razones históricas. No utilice
desde la línea de comandos o en nuevos scripts. Es lo mismo que git merge -m
....

La tercera sintaxis ("git merge --abort") solo se puede ejecutar después de que la combinación haya dado como resultado
conflictos. git unir --abortar abortará el proceso de fusión e intentará reconstruir el
estado previo a la fusión. Sin embargo, si hubo cambios no confirmados cuando comenzó la fusión (y
especialmente si esos cambios se modificaron aún más después de que se inició la fusión), git unir
--abortar en algunos casos no podrá reconstruir los cambios originales (previos a la fusión).
Por lo tanto:

advertencia: Corriendo git unir con cambios no triviales no comprometidos se desaconseja: mientras
posible, puede dejarlo en un estado del que es difícil retroceder en el caso de una
conflicto.

OPCIONES

--comprometer, --no-comprometer
Realice la fusión y confirme el resultado. Esta opción se puede utilizar para anular
--no comprometerse.

Con --no-commit realiza la fusión pero finge que la fusión falló y no autocommit,
para dar al usuario la oportunidad de inspeccionar y modificar aún más el resultado de la combinación antes
comprometerse.

--editar, -e, --no-editar
Invoque un editor antes de realizar una combinación mecánica exitosa para editar aún más el
mensaje de fusión generado automáticamente, para que el usuario pueda explicar y justificar la fusión. los
La opción --no-edit se puede usar para aceptar el mensaje generado automáticamente (generalmente
desanimado). La opción --edit (o -e) sigue siendo útil si está dando un borrador
mensaje con la opción -m desde la línea de comando y desea editarlo en el editor.

Los scripts más antiguos pueden depender del comportamiento histórico de no permitir que el usuario edite
el mensaje de registro de combinación. Verán un editor abierto cuando ejecuten git merge. Para hacer
es más fácil ajustar dichos scripts al comportamiento actualizado, la variable de entorno
GIT_MERGE_AUTOEDIT se puede establecer en no al comienzo de ellos.

--ff
Cuando la combinación se resuelve como un avance rápido, solo actualice el puntero de rama, sin
creando un compromiso de fusión. Este es el comportamiento predeterminado.

--no-ff
Cree una confirmación de combinación incluso cuando la combinación se resuelva como un avance rápido. Este es el
comportamiento predeterminado al fusionar una etiqueta anotada (y posiblemente firmada).

--ff-solo
Negarse a fusionarse y salir con un estado distinto de cero a menos que el HEAD actual ya esté
actualizado o la combinación se puede resolver como un avance rápido.

--log [= ], --no-log
Además de los nombres de las sucursales, complete el mensaje de registro con descripciones de una línea de
a lo sumo confirmaciones reales que se están fusionando. Ver también git-fmt-merge-mensaje(1).

Con --no-log no enumere descripciones de una línea de las confirmaciones reales que se fusionan.

--stat, -n, --no-stat
Muestra un diffstat al final de la combinación. El diffstat también está controlado por el
opción de configuración merge.stat.

Con -n o --no-stat no muestra un diffstat al final de la combinación.

- squash, - no squash
Genere el árbol de trabajo y el estado del índice como si hubiera ocurrido una fusión real (excepto por el
fusionar información), pero en realidad no realice una confirmación, mueva el HEAD o registre
$ GIT_DIR / MERGE_HEAD (para hacer que el siguiente comando de confirmación de git cree una confirmación de fusión).
Esto le permite crear una única confirmación sobre la rama actual cuyo efecto es
lo mismo que fusionar otra rama (o más en el caso de un pulpo).

Con --no-squash realice la fusión y confirme el resultado. Esta opción se puede utilizar para
anular - aplastar.

-s , --strategy =
Utilice la estrategia de fusión dada; se puede suministrar más de una vez para especificarlos en el
orden en que deben ser juzgados. Si no hay una opción -s, se incluye una lista de estrategias
usado en su lugargit fusionar-recursivo al fusionar una sola cabeza, git fusión-pulpo
de lo contrario).

-X , --strategy-option =
Pase la opción específica de la estrategia de fusión a la estrategia de fusión.

--verificar-firmas, --no-verificar-firmas
Verifique que las confirmaciones que se están fusionando tengan firmas GPG buenas y confiables y cancele
la fusión en caso de que no lo hagan.

--resumen, --no-resumen
Sinónimos para --stat y --no-stat; estos están obsoletos y se eliminarán en el
futuro.

-q, - silencioso
Opere silenciosamente. Implica: no hay progreso.

-v, --detallado
Sea prolijo.

--progreso, --no-progreso
Activa o desactiva el progreso de forma explícita. Si no se especifica ninguno, se muestra el progreso si
El error estándar está conectado a un terminal. Tenga en cuenta que no todas las estrategias de fusión pueden
apoyar la presentación de informes de progreso.

-S[ ], --gpg-sign [= ]
GPG-firma la confirmación de fusión resultante. El argumento keyid es opcional y por defecto es
la identidad del autor; si se especifica, debe pegarse a la opción sin un espacio.

-metro
Configure el mensaje de confirmación que se utilizará para la confirmación de fusión (en caso de que se cree una).

Si se especifica --log, un breve registro de las confirmaciones que se fusionan se agregará al
mensaje especificado.

El git fmt-merge-mensaje El comando se puede usar para dar un buen valor predeterminado para automatizado git
unir invocaciones. El mensaje automatizado puede incluir la descripción de la rama.

- [no-] volver a actualizar automáticamente
Permita que el mecanismo de repetición actualice el índice con el resultado del conflicto automático
resolución si es posible.

--abortar
Abortar el proceso de resolución de conflictos actual e intentar reconstruir la fusión previa
estado.

Si hubo cambios en el árbol de trabajo no confirmados cuando comenzó la fusión, git unir
--abortar en algunos casos no podrá reconstruir estos cambios. Por lo tanto es
recomendado para siempre confirmar o esconder sus cambios antes de ejecutar git unir.

git unir --abortar es equivalente a git reajustar --unir cuando MERGE_HEAD está presente.

...
Se compromete, generalmente otros jefes de sucursal, a fusionarse en nuestra sucursal. Especificando más de
un compromiso creará una fusión con más de dos padres (cariñosamente llamado
Fusión de pulpo).

Si no se proporciona ningún compromiso desde la línea de comando, combine las ramas de seguimiento remoto que
la rama actual está configurada para usarse como su flujo ascendente. Ver también la configuración
sección de esta página de manual.

Cuando se especifica FETCH_HEAD (y ninguna otra confirmación), las ramas registradas en el
El archivo .git / FETCH_HEAD mediante la invocación anterior de git fetch para fusionar se fusionan con
la rama actual.

PRE-FUSIÓN CHEQUES

Antes de aplicar cambios externos, debe poner su propio trabajo en buena forma y comprometido
localmente, por lo que no será golpeado si hay conflictos. Ver también git-alijo(1). git
recogida y git unir se detendrá sin hacer nada cuando los cambios locales no confirmados se superpongan
con archivos que git recogida /git unir puede que necesite actualizar.

Para evitar registrar cambios no relacionados en la confirmación de fusión, git recogida y git unir También se
abortar si hay algún cambio registrado en el índice relativo a la confirmación HEAD. (Uno
La excepción es cuando las entradas de índice modificadas están en el estado que resultaría de la
fusionar ya.)

Si todas las confirmaciones nombradas ya son ancestros de HEAD, git unir saldrá temprano con el
mensaje "Ya actualizado".

AVANCE RÁPIDO UNIR

A menudo, el jefe de rama actual es un antepasado de la confirmación con nombre. Este es el mas común
caso especialmente cuando se invoca desde git recogida : está rastreando un repositorio ascendente,
no ha realizado cambios locales, y ahora desea actualizar a una revisión ascendente más reciente.
En este caso, no se necesita una nueva confirmación para almacenar el historial combinado; en cambio, la CABEZA
(junto con el índice) se actualiza para apuntar a la confirmación nombrada, sin crear un extra
fusionar compromiso.

Este comportamiento se puede suprimir con la opción --no-ff.

VERDADERO UNIR

Excepto en una combinación de avance rápido (ver arriba), las ramas que se van a combinar deben estar vinculadas
juntos mediante un compromiso de fusión que tiene a ambos como padres.

Se confirma una versión fusionada que concilia los cambios de todas las ramas que se fusionarán, y
su HEAD, índice y árbol de trabajo se actualizan en él. Es posible tener modificaciones
en el árbol de trabajo siempre que no se superpongan; la actualización los conservará.

Cuando no es obvio cómo conciliar los cambios, ocurre lo siguiente:

1. El puntero HEAD permanece igual.

2. La referencia MERGE_HEAD está configurada para apuntar a la otra cabeza de rama.

3. Las rutas que se fusionaron limpiamente se actualizan tanto en el archivo de índice como en su árbol de trabajo.

4. Para rutas en conflicto, el archivo de índice registra hasta tres versiones: la etapa 1 almacena el
versión del ancestro común, etapa 2 de HEAD y etapa 3 de MERGE_HEAD (usted
puede inspeccionar las etapas con git ls-files -u). Los archivos del árbol de trabajo contienen el
resultado del programa de "fusión"; es decir, resultados de combinación de 3 vías con marcadores de conflicto familiares
<<< === >>>.

5. No se realizan otros cambios. En particular, las modificaciones locales que tenía antes
la fusión iniciada permanecerá igual y las entradas de índice para ellos permanecerán como estaban,
es decir, CABEZAL coincidente.

Si intentó una fusión que resultó en conflictos complejos y desea comenzar de nuevo, puede
recuperar con git merge --abort.

FUSIÓN ETIQUETA

Al fusionar una etiqueta anotada (y posiblemente firmada), Git siempre crea una confirmación de fusión
incluso si es posible una combinación de avance rápido, y la plantilla de mensaje de confirmación está preparada con
el mensaje de etiqueta. Además, si la etiqueta está firmada, la verificación de la firma se informa como un
comentario en la plantilla de mensaje. Ver también git-etiqueta(1).

Cuando solo desea integrarse con el trabajo que conduce al compromiso que resulta ser
etiquetado, por ejemplo, sincronizando con un punto de liberación ascendente, es posible que no desee hacer un
compromiso de fusión innecesario.

En tal caso, puede "desenvolver" la etiqueta usted mismo antes de alimentarla para git merge, o pasar
--ff-only cuando no tiene ningún trabajo por su cuenta. p.ej

origen de git fetch
git merge v1.2.3 ^ 0
git merge --ff-solo v1.2.3

BLOGS CONFLICTOS somos PRESENTADO

Durante una fusión, los archivos del árbol de trabajo se actualizan para reflejar el resultado de la fusión.
Entre los cambios realizados en la versión del antepasado común, los que no se superponen (es decir,
cambió un área del archivo mientras que el otro lado dejó esa área intacta, o viceversa)
se incorporan literalmente al resultado final. Cuando ambos lados hicieron cambios al mismo
área, sin embargo, Git no puede elegir al azar un lado sobre el otro, y le pide que resuelva
dejar lo que ambos lados hicieron en esa área.

Por defecto, Git usa el mismo estilo que el usado por el programa "merge" de RCS
suite para presentar un trozo tan conflictivo, como este:

Aquí hay líneas que no han cambiado del común
antepasado, o bien resuelto porque solo un bando cambió.
<<<<<<< tuyo: sample.txt
La resolución de conflictos es difícil;
vamos de compras.
=======
Git facilita la resolución de conflictos.
>>>>>>> de ellos: sample.txt
Y aquí hay otra línea que está limpiamente resuelta o sin modificaciones.

El área donde ocurrieron un par de cambios conflictivos está marcada con marcadores <<<<<<<,
======= y >>>>>>>. La parte antes de ======= es típicamente tu lado, y la parte
después es típicamente de su lado.

El formato predeterminado no muestra lo que dijo el original en el área en conflicto. usted
No puedo decir cuántas líneas se eliminan y reemplazan con el comentario de Barbie de su lado. los
Lo único que puedes decir es que tu lado quiere decir que es difícil y que prefieres ir
ir de compras, mientras que el otro lado quiere afirmar que es fácil.

Se puede utilizar un estilo alternativo estableciendo la configuración "merge.conflictStyle"
variable a "diff3". En el estilo "diff3", el conflicto anterior puede verse así:

Aquí hay líneas que no han cambiado del común
antepasado, o bien resuelto porque solo un bando cambió.
<<<<<<< tuyo: sample.txt
La resolución de conflictos es difícil;
vamos de compras.
|||||||
La resolución de conflictos es difícil.
=======
Git facilita la resolución de conflictos.
>>>>>>> de ellos: sample.txt
Y aquí hay otra línea que está limpiamente resuelta o sin modificaciones.

Además de los marcadores <<<<<<<, ======= y >>>>>>>, utiliza otro ||||||| marcador
que es seguido por el texto original. Puede decir que el original acaba de declarar un hecho,
y su lado simplemente cedió a esa declaración y se rindió, mientras que el otro lado trató de
tener una actitud más positiva. A veces puede encontrar una mejor resolución si
viendo el original.

BLOGS A RESOLVER CONFLICTOS

Después de ver un conflicto, puede hacer dos cosas:

· Decidir no fusionarse. Las únicas limpiezas que necesita son restablecer el archivo de índice a la
HEAD se compromete a revertir 2. y limpiar los cambios del árbol de trabajo realizados por 2. y 3 .; git
merge --abort se puede utilizar para esto.

· Resolver los conflictos. Git marcará los conflictos en el árbol de trabajo. Edita los archivos
en forma y git add ellos al índice. Usar git hacer para sellar el trato.

Puede resolver el conflicto con varias herramientas:

· Utilice una herramienta de combinación. git mergetool para lanzar una mergetool gráfica que te funcionará
a través de la fusión.

· Mira las diferencias. git diff mostrará una diferencia de tres vías, destacando los cambios de
ambas versiones HEAD y MERGE_HEAD.

· Mira las diferencias de cada rama. git log --merge -p mostrará las diferencias primero
para la versión HEAD y luego la versión MERGE_HEAD.

· Mira los originales. git show: 1: filename muestra el ancestro común, git show
: 2: filename muestra la versión HEAD y git show: 3: filename muestra MERGE_HEAD
versión.

EJEMPLOS

· Fusiona arreglos y mejoras de ramas en la parte superior de la rama actual, creando un pulpo
unir:

$ git merge corrige mejoras

· Fusionar la rama obsoleta en la rama actual, utilizando nuestra estrategia de fusión:

$ git merge -s el nuestro obsoleto

· Fusionar el mantenimiento de la rama en la rama actual, pero no realizar una nueva confirmación
automáticamente:

$ git merge --mantenimiento sin compromiso

Esto se puede utilizar cuando desee incluir más cambios en la combinación o desee
escriba su propio mensaje de confirmación de fusión.

Debe abstenerse de abusar de esta opción para introducir cambios sustanciales en una combinación.
cometer. Serían aceptables pequeñas correcciones como golpear el nombre de la versión / versión.

UNIR ESTRATEGIAS

El mecanismo de combinación (comandos git merge y git pull) permite que el backend unir estrategias
a elegir con la opción -s. Algunas estrategias también pueden tomar sus propias opciones, que pueden ser
pasado dando -X argumentos para git merge y / o git pull.

Resolvemos
Esto solo puede resolver dos cabezas (es decir, la rama actual y otra rama que extrajo
from) utilizando un algoritmo de combinación de 3 vías. Intenta detectar cuidadosamente la fusión entrecruzada
ambigüedades y se considera generalmente seguro y rápido.

recursiva
Esto solo puede resolver dos cabezas usando un algoritmo de combinación de 3 vías. Cuando hay mas de
un antepasado común que se puede utilizar para la fusión de 3 vías, crea un árbol fusionado de la
ancestros comunes y lo usa como árbol de referencia para la combinación de 3 vías. Esto tiene
Se ha informado que da como resultado menos conflictos de fusión sin causar fusiones erróneas en las pruebas.
realizado en confirmaciones de fusión reales tomadas del historial de desarrollo del kernel de Linux 2.6.
Además, esto puede detectar y manejar fusiones que implican cambios de nombre. Este es el predeterminado
fusionar estrategia al extraer o fusionar una rama.

El recursiva La estrategia puede tomar las siguientes opciones:

soportar
Esta opción obliga a que los trozos en conflicto se resuelvan automáticamente de forma limpia al favorecer nuestro
versión. Los cambios del otro árbol que no entran en conflicto con nuestro lado son
reflejado en el resultado de la fusión. Para un archivo binario, se toman todos los contenidos
de nuestro lado.

Esto no debe confundirse con el soportar fusionar estrategia, que ni siquiera parece
en lo que el otro árbol contiene en absoluto. Descarta todo lo que hizo el otro árbol,
declarando nuestro la historia contiene todo lo que sucedió en ella.

suyo
Esto es lo contrario de soportar.

paciencia
Con esta opción fusionar-recursivo dedica un poco más de tiempo para evitar combinaciones erróneas
que a veces ocurren debido a líneas coincidentes sin importancia (p. ej., llaves de distintas
funciones). Úselo cuando las ramas que se van a fusionar hayan divergido enormemente. Ver también
diferencia git(1) --paciencia.

algoritmo diff = [paciencia | mínimo | histograma | myers]
Informa fusionar-recursivo utilizar un algoritmo de diferencia diferente, que puede ayudar a evitar
combinaciones erróneas que ocurren debido a líneas coincidentes sin importancia (como llaves de
funciones distintas). Ver también diferencia git(1) - algoritmo de diferencia.

ignorar-espacio-cambio, ignorar-todo-espacio, ignorar-espacio-en-eol
Trata las líneas con el tipo de cambio de espacio en blanco indicado como sin cambios para el
en aras de una fusión de tres vías. Cambios de espacios en blanco mezclados con otros cambios en una línea
no se ignoran. Ver también diferencia git(1) -b, -w y --ignore-space-at-eol.

· Si their la versión solo introduce cambios de espacios en blanco en una línea, nuestro la versión es
usado;

· Si nuestro la versión introduce cambios en los espacios en blanco pero their la versión incluye un
cambio sustancial, their se utiliza la versión;

· De lo contrario, la fusión se realiza de la forma habitual.

renormalizar
Esto ejecuta un check-out y check-in virtual de las tres etapas de un archivo cuando
resolver una combinación de tres vías. Esta opción está destinada a utilizarse al fusionar ramas.
con diferentes filtros limpios o reglas de normalización de final de línea. Ver "Fusionar
sucursales con diferentes atributos de registro / salida "en atributos de git(5) para
Detalles.

no renormalizar
Desactiva la opción de renormalizar. Esto anula merge.renormalize
variable de configuración.

renombrar-umbral =
Controla el umbral de similitud utilizado para la detección de cambio de nombre. Ver también diferencia git(1)
-METRO.

subárbol [= ]
Esta opción es una forma más avanzada de subárbol estrategia, donde la estrategia hace
una suposición sobre cómo se deben cambiar dos árboles para que coincidan al fusionarse.
En cambio, la ruta especificada tiene un prefijo (o se elimina desde el principio) para hacer
la forma de dos árboles a juego.

pulpo
Esto resuelve casos con más de dos cabezas, pero se niega a hacer una combinación compleja que
necesita resolución manual. Está destinado principalmente a ser utilizado para agrupar ramas de temas.
cabezas juntas. Esta es la estrategia de fusión predeterminada cuando se extrae o fusiona más de
una rama.

soportar
Esto resuelve cualquier número de cabezas, pero el árbol resultante de la fusión es siempre ese
de la rama actual, ignorando efectivamente todos los cambios de todas las demás ramas.
Está destinado a reemplazar el antiguo historial de desarrollo de las ramas laterales. Nota
que esto es diferente de la opción -Xours a la recursiva fusionar estrategia.

subárbol
Esta es una estrategia recursiva modificada. Al fusionar los árboles A y B, si B corresponde a
un subárbol de A, B se ajusta primero para que coincida con la estructura de árbol de A, en lugar de
leyendo los árboles al mismo nivel. Este ajuste también se realiza al común
árbol ancestro.

Con las estrategias que utilizan la combinación de 3 vías (incluida la predeterminada, recursiva), si hay un cambio
se realiza en ambas ramas, pero luego se revierte en una de las ramas, ese cambio será
presente en el resultado combinado; algunas personas encuentran confuso este comportamiento. Ocurre porque
Cuando se realiza una combinación, solo se consideran las cabezas y la base de combinación, no las
confirmaciones individuales. Por lo tanto, el algoritmo de fusión considera el cambio revertido como no
cambiar en absoluto, y sustituye la versión modificada en su lugar.

CONFIGURACIÓN

fusionar.conflictStyle
Especifique el estilo en el que los trozos en conflicto se escriben en los archivos de árbol de trabajo en
unir. El valor predeterminado es "fusionar", que muestra un <<<<<<< marcador de conflicto, cambios realizados por
un lado, un marcador =======, cambios realizados por el otro lado, y luego un marcador >>>>>>>.
Un estilo alternativo, "diff3", agrega un ||||||| marcador y el texto original antes del
======= marcador.

fusionar.defaultToUpstream
Si se llama a merge sin ningún argumento de confirmación, combine las ramas ascendentes configuradas
para la rama actual utilizando sus últimos valores observados almacenados en su
sucursales de seguimiento remoto. Los valores de la rama. .merge ese nombre
las sucursales en el control remoto nombradas por sucursal. .remote son consultados, y
luego se mapean vía remota. .fetch a su correspondiente seguimiento remoto
ramas y las puntas de estas ramas de seguimiento se fusionan.

fusionar.ff
De forma predeterminada, Git no crea una confirmación de fusión adicional cuando se fusiona una confirmación que es una
descendiente de la confirmación actual. En cambio, la punta de la rama actual es
avance rápido. Cuando se establece en falso, esta variable le dice a Git que cree una combinación adicional
confirmar en tal caso (equivalente a dar la opción --no-ff desde la línea de comando).
Cuando se establece en solo, solo se permiten esas fusiones de avance rápido (equivalente a dar la
opción --ff-only desde la línea de comando).

fusionar.branchdesc
Además de los nombres de las sucursales, complete el mensaje de registro con el texto de descripción de la sucursal
asociado con ellos. El valor predeterminado es falso.

fusionar.log
Además de los nombres de las sucursales, complete el mensaje de registro como máximo con los
número de descripciones de una línea de las confirmaciones reales que se están fusionando.
El valor predeterminado es falso y verdadero es sinónimo de 20.

fusionar.renameLimit
La cantidad de archivos a considerar al realizar la detección de cambio de nombre durante una combinación; si
no especificado, toma el valor predeterminado de diff.renameLimit.

fusionar.renormalizar
Dile a Git que la representación canónica de archivos en el repositorio ha cambiado
tiempo (por ejemplo, archivos de texto de registro de confirmaciones anteriores con terminaciones de línea CRLF, pero recientes
utilice terminaciones de línea LF). En tal repositorio, Git puede convertir los datos registrados en
se compromete a una forma canónica antes de realizar una fusión para reducir los conflictos innecesarios.
Para obtener más información, consulte la sección "Fusionar sucursales con registros de entrada / salida diferentes
atributos "en atributos de git(5).

combinar.stat
Si imprimir el diffstat entre ORIG_HEAD y el resultado de la fusión al final de la
unir. Verdadero por defecto.

fusionar.herramienta
Controla qué herramienta de combinación utiliza git-mergetool(1). La siguiente lista muestra los
valores incorporados. Cualquier otro valor se trata como una herramienta de combinación personalizada y requiere que
correspondiente mergetool. Se define la variable .cmd.

· Araxis

· antes de Cristo

· Bc3

· Codecompare

· Deltawalker

· Diffmerge

· Difuso

· Ecmerge

· Emerger

· Gvimdiff

· Gvimdiff2

· Gvimdiff3

· Kdiff3

· Fusionar

· Opendiff

· P4merge

· Tkdiff

· Tortuga emerger

· Vimdiff

· Vimdiff2

· Vimdiff3

· Winmerge

· Xxdiff

fusionar.verbosidad
Controla la cantidad de salida mostrada por la estrategia de combinación recursiva. Salidas de nivel 0
nada excepto un mensaje de error final si se detectaron conflictos. Solo salidas de nivel 1
conflictos, conflictos de 2 salidas y cambios de archivo. Depuración de salidas de nivel 5 y superior
información. El valor predeterminado es el nivel 2. Puede ser anulado por el GIT_MERGE_VERBOSIDAD
Variable ambiental.

unir. .nombre
Define un nombre legible por humanos para un controlador de combinación personalizado de bajo nivel. Ver
atributos de git(5) para obtener más detalles.

unir. .conductor
Define el comando que implementa un controlador de combinación personalizado de bajo nivel. Ver
atributos de git(5) para obtener más detalles.

unir. .recursivo
Nombra un controlador de combinación de bajo nivel que se utilizará al realizar una combinación interna entre
ancestros comunes. Ver atributos de git(5) para obtener más detalles.

rama. .mergeOptions
Establece las opciones predeterminadas para fusionarse en una rama. . La sintaxis y las opciones admitidas
son los mismos que los de git unir, pero los valores de opción que contienen caracteres de espacio en blanco
actualmente no son compatibles.

Use git-merge en línea usando los servicios de onworks.net