consola - Cómo resolver conflictos de fusión en Git

resolver conflictos git eclipse (30)

¿Hay una buena manera de explicar cómo resolver conflictos de combinación en Git?

git fetch
git checkout su rama
git rebase master

En este paso, intentará solucionar el conflicto utilizando su IDE preferido.

Puede seguir este enlace para verificar cómo solucionar el conflicto en el archivo
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

git add
git rebase --continue
git commit --amend
git push origin HEAD: refs / drafts / master (presione como un borrador)

Ahora todo está bien y encontrarás tu commit en gerrit

Espero que esto ayude a todos en este tema.

Prima:

Al hablar de extracción / recuperación / fusión en las respuestas anteriores, me gustaría compartir un truco interesante y productivo,

`git pull --rebase`

Este comando anterior es el comando más útil en mi vida de git que ahorró mucho tiempo.

Antes de enviar su nuevo cambio comprometido al servidor remoto, pruebe git pull --rebase lugar de git pull y la merge manual, se sincronizarán automáticamente los últimos cambios del servidor remoto (con fetch + merge) y colocará su último compromiso local en la parte superior de git Iniciar sesión. No hay necesidad de preocuparse por la extracción / fusión manual.

En caso de conflicto, solo use

git mergetool git add conflict_file git rebase --continue

Encuentre detalles en: http://gitolite.com/git-pull--rebase

Usando la `patience`

Me sorprende que nadie más haya hablado sobre la resolución de conflictos usando la patience con la estrategia recursiva de fusión. Para un gran conflicto de fusión, usar la patience proporcionó buenos resultados. La idea es que intentará hacer coincidir bloques en lugar de líneas individuales.

Si cambia la sangría de su programa, por ejemplo, la estrategia de fusión de Git predeterminada a veces coincide con llaves individuales { que pertenecen a funciones diferentes. Esto se evita con patience :

git merge -s recursive -X patience other-branch

De la documentación:

With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e.g., braces from distinct functions). Use this when the branches to be merged have diverged wildly.

Comparación con el ancestro común.

Si tiene un conflicto de fusión y desea ver lo que otros tenían en mente al modificar su rama, a veces es más fácil comparar su rama directamente con el ancestro común (en lugar de nuestra rama). Para eso puedes usar merge-base :

git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

Por lo general, solo desea ver los cambios para un archivo en particular:

git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>

Identifica qué archivos están en conflicto (Git debería decirte esto).
Abra cada archivo y examine las diferencias; Git los delimita. Esperemos que sea obvio qué versión de cada bloque guardar. Es posible que deba discutirlo con otros desarrolladores que cometieron el código.
Una vez que haya resuelto el conflicto en un archivo git add the_file .
Una vez que haya resuelto todos los conflictos, haga git rebase --continue o cualquier comando que Git haya dicho que haga cuando complete.

A partir del 12 de diciembre de 2016, puede fusionar sucursales y resolver conflictos en github.com

Por lo tanto, si no desea utilizar la línea de comandos o cualquier otra herramienta de terceros que se ofrece aquí en las respuestas anteriores , vaya con la herramienta nativa de GitHub.

Esta publicación del blog explica en detalle, pero lo básico es que al "fusionar" dos sucursales a través de la interfaz de usuario, ahora verá una opción de "resolución de conflictos" que lo llevará a un editor que le permitirá lidiar con estos conflictos de combinación.

Aquí está un caso de uso probable, desde la parte superior:

Vas a sacar algunos cambios, pero oops, no estás actualizado:

git fetch origin git pull origin master From ssh://[email protected]:22/projectname * branch master -> FETCH_HEAD Updating a030c3a..ee25213 error: Entry ''filename.c'' not uptodate. Cannot merge.

Así que te actualizas e intentas de nuevo, pero tienes un conflicto:

git add filename.c git commit -m "made some wild and crazy changes" git pull origin master From ssh://[email protected]:22/projectname * branch master -> FETCH_HEAD Auto-merging filename.c CONFLICT (content): Merge conflict in filename.c Automatic merge failed; fix conflicts and then commit the result.

Así que decides echar un vistazo a los cambios:

git mergetool

Oh yo, oh mi, upstream cambió algunas cosas, pero solo para usar mis cambios ... no ... sus cambios ...

git checkout --ours filename.c git checkout --theirs filename.c git add filename.c git commit -m "using theirs"

Y luego intentamos una última vez.

git pull origin master From ssh://[email protected]:22/projectname * branch master -> FETCH_HEAD Already up-to-date.

¡Ta-da!

Encuentro que las herramientas de combinación rara vez me ayudan a entender el conflicto o la resolución. Por lo general, soy más exitoso al ver los marcadores de conflicto en un editor de texto y al usar git log como complemento.

Aquí hay algunos consejos:

Consejo Uno

Lo mejor que he encontrado es usar el estilo de conflicto de combinación "diff3":

git config merge.conflictstyle diff3

Esto produce marcadores de conflicto como este:

<<<<<<< Changes made on the branch that is being merged into. In most cases, this is the branch that I have currently checked out (i.e. HEAD). ||||||| The common ancestor version. ======= Changes made on the branch that is being merged in. This is often a feature/topic branch. >>>>>>>

La sección del medio es el aspecto del antepasado común. Esto es útil porque puede compararlo con las versiones superior e inferior para tener una mejor idea de lo que se cambió en cada rama, lo que le da una mejor idea de cuál fue el propósito de cada cambio.

Si el conflicto es solo de unas pocas líneas, esto generalmente hace que el conflicto sea muy obvio. (Saber cómo solucionar un conflicto es muy diferente; debe estar consciente de en qué está trabajando otra gente. Si está confundido, probablemente sea mejor llamar a esa persona a su habitación para que puedan ver lo que está buscando. a.)

Si el conflicto es más largo, cortaré y pegaré cada una de las tres secciones en tres archivos separados, como "mío", "común" y "suyo".

Luego puedo ejecutar los siguientes comandos para ver los dos tipos de diferencias que causaron el conflicto:

diff common mine diff common theirs

Esto no es lo mismo que usar una herramienta de combinación, ya que una herramienta de combinación incluirá todas las diferencias no conflictivas también. Encuentro que eso me distrae.

Consejo dos

Alguien ya mencionó esto, pero entender la intención detrás de cada tramo de diferencias es generalmente muy útil para entender de dónde vino un conflicto y cómo manejarlo.

git log --merge -p <name of file>

Esto muestra todas las confirmaciones que tocaron ese archivo entre el ancestro común y las dos cabezas que está fusionando. (Por lo tanto, no incluye confirmaciones que ya existen en ambas ramas antes de fusionar). Esto le ayuda a ignorar las diferencias que claramente no son un factor en su conflicto actual.

Consejo Tres

Verifica tus cambios con herramientas automatizadas.

Si tiene pruebas automatizadas, ejecute esas. Si tienes una lint , ejecuta eso. Si se trata de un proyecto compilable, créelo antes de comprometerse, etc. En todos los casos, debe hacer un poco de prueba para asegurarse de que sus cambios no rompan nada. (Diablos, incluso una combinación sin conflictos puede romper el código de trabajo).

Consejo cuatro

Planea con anticipación comunicarse con compañeros de trabajo

Planear con anticipación y ser consciente de lo que otros están trabajando puede ayudar a prevenir conflictos de fusión y / o ayudar a resolverlos antes, mientras que los detalles aún están en mente.

Por ejemplo, si sabe que usted y otra persona están trabajando en una refactorización diferente que afectará al mismo conjunto de archivos, debe hablar entre ellos con anticipación y tener una mejor idea de qué tipo de cambios es cada uno de ustedes. fabricación. Puede ahorrar mucho tiempo y esfuerzo si realiza los cambios planeados en serie en lugar de en paralelo.

Para las refactorizaciones importantes que cortan una gran franja de código, debe considerar trabajar en serie: todos dejarán de trabajar en esa área del código mientras una persona realiza la refactorización completa.

Si no puede trabajar en serie (debido a la presión del tiempo, tal vez), entonces la comunicación sobre los conflictos de fusión esperados al menos lo ayuda a resolver los problemas antes, mientras que los detalles aún están en mente. Por ejemplo, si un compañero de trabajo está realizando una serie de confirmaciones disruptivas en el transcurso de un período de una semana, puede elegir fusionar / reagrupar en esa rama de compañeros de trabajo una o dos veces al día durante esa semana. De esa manera, si encuentra conflictos de fusión / rebase, puede resolverlos más rápidamente que si espera unas semanas para fusionar todo en un solo bulto.

Consejo cinco

Si no está seguro de una fusión, no la fuerce.

La fusión puede resultar abrumadora, especialmente cuando hay muchos archivos en conflicto y los marcadores de conflicto cubren cientos de líneas. Muchas veces, cuando estimamos proyectos de software, no incluimos el tiempo suficiente para los elementos generales, como el manejo de una combinación ingeniosa, por lo que se siente como un lastre real pasar varias horas analizando cada conflicto.

A la larga, planificar con anticipación y ser consciente de en qué están trabajando los demás son las mejores herramientas para anticipar conflictos de combinación y prepararse para resolverlos correctamente en menos tiempo.

Hay 3 pasos:

Encuentra que archivos causan conflictos por comando
git status
Revisa los archivos, en los que encontrarás los conflictos marcados como
<<<<<<<<head blablabla
Cámbielo a la forma que desee, y luego confirme con comandos.
git add solved_conflicts_files git commit -m ''merge msg''

La respuesta de CoolAJ86 resume casi todo. En caso de que haya cambios en ambas ramas en el mismo fragmento de código, tendrá que hacer una combinación manual. Abra el archivo en conflicto en cualquier editor de texto y debería ver la siguiente estructura.

(Code not in Conflict) >>>>>>>>>>> (first alternative for conflict starts here) Multiple code lines here =========== (second alternative for conflict starts here) Multiple code lines here too <<<<<<<<<<< (Code not in conflict here)

Elija una de las alternativas o una combinación de ambas de la forma en que desea que sea el nuevo código, al mismo tiempo que elimina signos iguales y corchetes angulares.

git commit -a -m "commit message" git push origin master

Los conflictos de combinación ocurren cuando se realizan cambios en un archivo al mismo tiempo. Aquí es cómo resolverlo.

`git` CLI

Aquí hay pasos simples que hacer cuando te encuentras en un estado de conflicto:

Tenga en cuenta la lista de archivos en conflicto con: git status (en la sección Unmerged paths ).
Resuelva los conflictos por separado para cada archivo mediante uno de los siguientes enfoques:
- Utilice GUI para resolver los conflictos: git mergetool (la forma más fácil).
- Para aceptar una versión remota / otra, use: git checkout --theirs path/file . Esto rechazará cualquier cambio local que haya hecho para ese archivo.
- Para aceptar la versión local / nuestra, use: git checkout --ours path/file
  ^{Sin embargo, hay que tener cuidado, ya que los cambios remotos que los conflictos se realizaron por algún motivo.}
  Relacionado: ¿Cuál es el significado preciso de "nuestro" y "suyo" en git?
- Edite los archivos en conflicto manualmente y busque el bloque de código entre <<<<< / >>>>> luego elija la versión de arriba o abajo ===== . Ver: Cómo se presentan los conflictos .
- Los conflictos de ruta y nombre de archivo se pueden resolver mediante git add / git rm .
Por último, revise los archivos listos para confirmar usando: git status .
Si aún tiene algún archivo en Unmerged paths y resolvió el conflicto manualmente, entonces informe a Git que lo resolvió mediante: git add path/file .
Si todos los conflictos se resolvieron con éxito, confirme los cambios: git commit -a y presione a remoto como de costumbre.

Vea también: Resolver un conflicto de fusión desde la línea de comando en GitHub

DiffMerge

He utilizado con éxito DiffMerge que puede comparar visualmente y combinar archivos en Windows, macOS y Linux / Unix.

Gráficamente puede mostrar los cambios entre 3 archivos y permite la fusión automática (cuando es seguro hacerlo) y un control total sobre la edición del archivo resultante.

^{Fuente de la imagen: DiffMerge (captura de pantalla de Linux)}

Simplemente descárgalo y ejecuta en repo como:

git mergetool -t diffmerge .

Mac OS

En macOS puedes instalarlo a través de:

brew install caskroom/cask/brew-cask brew cask install diffmerge

Y probablemente (si no se proporciona) necesita la siguiente envoltura extra simple colocada en su RUTA (por ejemplo, /usr/bin ):

#!/bin/sh DIFFMERGE_PATH=/Applications/DiffMerge.app DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge exec ${DIFFMERGE_EXE} --nosplash "$@"

Luego puedes usar los siguientes atajos de teclado:

Alt - Alt - Arriba / Abajo para saltar a los cambios anteriores / siguientes.
Alt - Alt - Izquierda / Derecha para aceptar cambios de izquierda o derecha

Alternativamente, puede usar opendiff (parte de Xcode Tools) que le permite combinar dos archivos o directorios para crear un tercer archivo o directorio.

O bien quiero mi versión o la versión completa, o quiero revisar los cambios individuales y decidir por cada uno de ellos.

Acepta plenamente mi versión o la de ellos :

Acepta mi versión (local, nuestra):

git checkout --ours -- <filename> git add <filename> # Marks conflict as resolved git commit -m "merged bla bla" # An "empty" commit

Acepta su versión (remota, suya):

git checkout --theirs -- <filename> git add <filename> git commit -m "merged bla bla"

Si desea hacer para todos los archivos de conflicto ejecutar:

git merge --strategy-option ours

git merge --strategy-option theirs

Revisa todos los cambios y acéptalos individualmente.

git mergetool
Revisa los cambios y acepta cualquiera de las versiones para cada uno de ellos.
git add <filename>
git commit -m "merged bla bla"

El mergetool predeterminado funciona en la línea de comandos . Cómo usar una línea de comando mergetool debería ser una pregunta separada.

También puede instalar una herramienta visual para esto, por ejemplo, meld y ejecutar

git mergetool -t meld

Se abrirá la versión local (nuestra), la versión "base" o "combinada" (el resultado actual de la fusión) y la versión remota (la de ellos). Guarde la versión combinada cuando haya terminado, ejecute git mergetool -t meld nuevamente hasta que git mergetool -t meld "No es necesario fusionar archivos", luego vaya a los pasos 3. y 4.

Para los usuarios de Emacs que desean resolver conflictos de combinación de forma semi-manual:

git diff --name-status --diff-filter=U

Muestra todos los archivos que requieren resolución de conflictos.

Abra cada uno de esos archivos uno por uno, o todos a la vez por:

emacs $(git diff --name-only --diff-filter=U)

Cuando visite un búfer que requiera ediciones en Emacs, escriba

ALT+x vc-resolve-conflicts

Esto abrirá tres búferes (el mío, el suyo y el búfer de salida). Navegue presionando ''n'' (siguiente región), ''p'' (región de previsión). Presione ''a'' y ''b'' para copiar la región mía o de ellos en el búfer de salida, respectivamente. Y / o editar el buffer de salida directamente.

Cuando haya terminado: presione ''q''. Emacs le pregunta si desea guardar este búfer: sí. Después de terminar un búfer, márquelo como resuelto ejecutando desde el teriminal:

git add FILENAME

Cuando termine con todos los buffers de tipo.

git commit

para terminar la fusión.

Podría arreglar los conflictos de combinación de varias maneras, como otras han detallado.

Creo que la verdadera clave es saber cómo fluyen los cambios con los repositorios locales y remotos. La clave para esto es entender las ramas de seguimiento. Descubrí que pienso en la rama de seguimiento como la "pieza que falta en el medio" entre mi directorio local de archivos reales y el control remoto definido como origen.

Personalmente he adquirido el hábito de 2 cosas para ayudar a evitar esto.

En lugar de:

git add . git commit -m"some msg"

Que tiene dos inconvenientes -

a) Se agregan todos los archivos nuevos / modificados y eso puede incluir algunos cambios no deseados.
b) No puedes revisar la lista de archivos primero.

Así que en cambio yo hago:

git add file,file2,file3... git commit # Then type the files in the editor and save-quit.

De esta manera, es más deliberado sobre qué archivos se agregan y también puede revisar la lista y pensar un poco más mientras usa el editor para el mensaje. Me parece que también mejora mis mensajes de confirmación cuando uso un editor de pantalla completa en lugar de la opción -m .

[Actualización - a medida que pasa el tiempo he cambiado más a:

git status # Make sure I know whats going on git add . git commit # Then use the editor

]

También (y más relevante para su situación), trato de evitar:

git pull

git pull origin master.

porque pull implica una combinación y si tiene cambios locales que no deseaba combinar, puede terminar fácilmente con un código combinado y / o conflictos de combinación para el código que no debería haberse fusionado.

En su lugar trato de hacer

git checkout master git fetch git rebase --hard origin/master # or whatever branch I want.

También puede encontrar esto útil:

git branch, fork, fetch, merge, rebase y clone, ¿cuáles son las diferencias?

Por favor, siga los siguientes pasos para arreglar conflictos de combinación en Git:

Compruebe el estado de Git: estado de Git
Obtén el conjunto de parches: git fetch (compra el parche correcto de tu Git commit)
Verifique una sucursal local (temp1 en mi ejemplo aquí): git checkout -b temp1
Extraiga los contenidos recientes del master: git pull --rebase origin master
Inicie mergetool y verifique los conflictos y corríjalos ... y verifique los cambios en la rama remota con su rama actual: git mergetool
Compruebe el estado de nuevo: estado de git
Elimine los archivos no deseados creados localmente por mergetool, generalmente mergetool crea un archivo adicional con la extensión * .orig. Borre ese archivo ya que es solo el duplicado y repare los cambios localmente y agregue la versión correcta de sus archivos. git add #your_changed_correct_files
Compruebe el estado de nuevo: estado de git
Confirme los cambios en el mismo ID de confirmación (esto evita un nuevo conjunto de parches separados): git commit --amend
Empuje a la rama maestra: git push (a su repositorio Git)

Si realiza frecuentes confirmaciones pequeñas, comience mirando los comentarios de confirmación con git log --merge . Entonces git diff te mostrará los conflictos.

Para conflictos que involucran más de unas pocas líneas, es más fácil ver lo que sucede en una herramienta de GUI externa. Me gusta opendiff - Git también soporta vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emerge fuera de la caja y puedes instalar otros: git config merge.tool "your.tool" configurará tu herramienta elegida y luego git mergetool después de una fusión fallida le mostrará las diferencias en el contexto.

Cada vez que edite un archivo para resolver un conflicto, git add filename actualizará el índice y su diff ya no lo mostrará. Cuando todos los conflictos se manejen y sus archivos hayan sido git add , git commit completará su fusión.

Simplemente, si sabe bien que los cambios en uno de los repositorios no es importante, y desea resolver todos los cambios a favor del otro, use:

git checkout . --ours

para resolver cambios a favor de su repositorio , o

git checkout . --theirs

para resolver cambios a favor del otro o del repositorio principal .

O bien, tendrá que usar una herramienta de combinación de GUI para recorrer los archivos uno por uno, digamos que la herramienta de combinación es p4merge , o escriba el nombre de cualquiera que ya haya instalado

git mergetool -t p4merge

y después de terminar un archivo, tendrá que guardar y cerrar, para que se abra el siguiente.

Vea cómo se presentan los conflictos o, en Git, la documentación de git merge para comprender qué son los marcadores de combinación de conflictos.

Además, la sección Cómo resolver conflictos explica cómo resolver los conflictos:

Después de ver un conflicto, puedes hacer dos cosas:
Decide no fusionar. Las únicas limpiezas que necesita son restablecer el archivo de índice al compromiso HEAD para revertir 2. y limpiar los cambios del árbol de trabajo realizados por 2. y 3; git merge --abort se puede utilizar para esto.
Resuelve los conflictos. Git marcará los conflictos en el árbol de trabajo. Edite los archivos en forma y git add al índice. Usa git commit para sellar el trato.
Puede trabajar a través del conflicto con una serie de herramientas:
Utilice un mergetool. git mergetool para iniciar un gráfico mergetool que le ayudará a realizar la fusión.
Mira las diferencias. git diff mostrará un git diff tres vías, destacando los cambios de las versiones HEAD y MERGE_HEAD .
Mira las diferencias de cada rama. git log --merge -p <path> mostrará primero las diferencias para la versión HEAD y luego la versión MERGE_HEAD .
Mira los originales. git show :1:filename muestra el antepasado común, git show :2:filename muestra la versión HEAD y git show :3:filename muestra la versión MERGE_HEAD .

También puede leer acerca de los marcadores de conflicto de fusión y cómo resolverlos en la sección de libros de Pro Git Conflictos de combinación básicos .

Verifique las respuestas en la pregunta de desbordamiento de pila Abortando una fusión en Git , especialmente la respuesta de Charles Bailey, que muestra cómo ver las diferentes versiones del archivo con problemas, por ejemplo,

# Common base version of the file. git show :1:some_file.cpp # ''Ours'' version of the file. git show :2:some_file.cpp # ''Theirs'' version of the file. git show :3:some_file.cpp

Esta respuesta es agregar una alternativa para aquellos usuarios de VIM como yo que prefiere hacer todo dentro del editor.

TL; DR

Tpope creó este gran complemento para VIM llamado fugitive . Una vez instalado, puede ejecutar :Gstatuspara verificar los archivos que tienen conflictos y :Gdiffpara abrir Git en una combinación de 3 formas.

Una vez en la combinación de 3 vías, fugitivo le permitirá obtener los cambios de cualquiera de las sucursales que está fusionando de la siguiente manera:

:diffget //2, obtener cambios de la rama original ( HEAD ):
:diffget //3 , obtener cambios de la fusión de la rama:

Una vez que haya terminado de fusionar el archivo, escriba :Gwriteel búfer combinado. Vimcasts lanzó un gran video explica en detalle estos pasos.

Los conflictos de fusión podrían ocurrir en diferentes situaciones:

Cuando se ejecuta "git fetch" y luego "git merge"
Cuando se ejecuta "git fetch" y luego "git rebase"
Cuando se ejecuta "git pull" (que en realidad es igual a una de las condiciones mencionadas anteriormente)
Cuando se ejecuta "git stash pop"
Cuando está aplicando parches de git (confirmaciones que se exportan a archivos para transferir, por ejemplo, por correo electrónico)

Necesitas instalar una herramienta de combinación que sea compatible con Git para resolver los conflictos. Personalmente uso KDiff3, y me parece agradable y práctico. Puedes descargar su versión de Windows aquí:

https://sourceforge.net/projects/kdiff3/files/

Por cierto, si instala Git Extensions, hay una opción en su asistente de configuración para instalar Kdiff3.

Luego configura las configuraciones de git para usar Kdiff como mergetool:

$ git config --global --add merge.tool kdiff3 $ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" $ git config --global --add mergetool.kdiff3.trustExitCode false $ git config --global --add diff.guitool kdiff3 $ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" $ git config --global --add difftool.kdiff3.trustExitCode false

(Recuerde reemplazar la ruta con la ruta real del archivo exe Kdiff).

Luego, cada vez que te encuentras con un conflicto de fusión, solo necesitas ejecutar este comando:

$git mergetool

Luego abre Kdiff3, y primero intenta resolver los conflictos de fusión automáticamente. La mayoría de los conflictos se resolverían de manera espontánea y usted necesita arreglar el resto manualmente.

Aquí es cómo se ve Kdiff3:

Luego, una vez que haya terminado, guarde el archivo y pasará al siguiente archivo con conflicto y volverá a hacer lo mismo hasta que se resuelvan todos los conflictos.

Para verificar si todo se fusionó correctamente, simplemente ejecute el comando mergetool nuevamente, debe obtener este resultado:

$git mergetool No files need merging

Para aquellos que están usando Visual Studio (2015 en mi caso)

Cierra tu proyecto en VS. Especialmente en los grandes proyectos, VS tiende a enloquecer al fusionarse utilizando la interfaz de usuario.
Haga la combinación en el símbolo del sistema.
git checkout target_branch
git merge source_branch
Luego abre el proyecto en VS y ve a Team Explorer -> Branch. Ahora hay un mensaje que dice que la fusión está pendiente y que los archivos en conflicto aparecen debajo del mensaje.
Haga clic en el archivo en conflicto y tendrá la opción de Combinar, Comparar, Tomar origen, Tomar objetivo. La herramienta de combinación en VS es muy fácil de usar.

Prueba: git mergetool

Abre una GUI que te guía a través de cada conflicto y puedes elegir cómo fusionar. A veces requiere un poco de edición manual después, pero por lo general es suficiente por sí mismo. Es mucho mejor que hacerlo todo a mano sin duda.

Según el comentario de @JoshGlover:

El comando no necesariamente abre una GUI a menos que instales una. Ejecutar git mergetool para mí resultó en el uso de vimdiff . Puede instalar una de las siguientes herramientas para usarla: opendiff , kdiff3 , tkdiff , xxdiff , xxdiff , tortoisemerge , gvimdiff , diffuse , ecmerge , p4merge , araxis , vimdiff , emerge .

A continuación se muestra el procedimiento de ejemplo para usar vimdiff para resolver conflictos de combinación. Basado en este enlace

Paso 1 : Ejecuta los siguientes comandos en tu terminal

git config merge.tool vimdiff git config merge.conflictstyle diff3 git config mergetool.prompt false

Esto establecerá vimdiff como la herramienta de combinación predeterminada.

Paso 2 : Ejecutar el siguiente comando en la terminal

git mergetool

Paso 3 : Verás una pantalla vimdiff en el siguiente formato

+----------------------+ | | | | |LOCAL |BASE |REMOTE | | | | | +----------------------+ | MERGED | | | +----------------------+

Estas 4 vistas son

LOCAL - este es un archivo de la rama actual
BASE - ancestro común, cómo se veía el archivo antes de ambos cambios
REMOTO - archivo que se está fusionando en su rama
MERGED - fusionar resultado, esto es lo que se guarda en el repositorio

Puedes navegar entre estas vistas usando ctrl+w . Puede acceder directamente a la vista MERGED utilizando ctrl+w seguido de j .

Más información sobre la navegación vimdiff here y here

Paso 4 . Podrías editar la vista MERGED de la siguiente manera.

Si quieres conseguir cambios desde REMOTO

:diffg RE

Si quieres conseguir cambios desde BASE

:diffg BA

Si desea obtener cambios de LOCAL

:diffg LO

Paso 5 Guardar, salir, cometer y limpiar

:wqa guardar y salir de vi

git commit -m "message"

git clean Eliminar archivos adicionales (por ejemplo, * .orig) creados por la herramienta diff.

Si desea combinar de rama (prueba) a maestro, puede seguir estos pasos:

Paso 1: Ir a la rama.

git checkout test

Paso 2: git pull --rebase origin master

Paso 3: Si hay algunos conflictos, vaya a estos archivos para modificarlos.

Paso 4: Añade estos cambios

git add #your_changes_files

Paso 5: git rebase --continue

Paso 6: si todavía hay conflicto, vuelva al paso 3 nuevamente. Si no hay conflicto, haz lo siguiente:git push origin +test

Paso 7: Y entonces no hay conflicto entre prueba y maestro. Puedes usar fusionar directamente.

Si está utilizando intelliJ como IDE, intente fusionar el padre con su sucursal

git checkout <localbranch> git merge origin/<remotebranch>

Mostrará todos los conflictos como este.

A_MBPro: probar anu $ git merge origin / Auto-merging src / test / java / com /.../ TestClass.java CONFLICT (contenido): Combinar conflicto en src / test / java / com /.../ TestClass.java

Ahora note que el archivo TestClass.java se muestra en rojo en intelliJ También se mostrará el estado de git

Unmerged paths: (use "git add <file>..." to mark resolution) both modified: src/test/java/com/.../TestClass.java

Abra el archivo en intelliJ, tendrá secciones con

<<<<<<< HEAD public void testMethod() { } ======= public void testMethod() { ... } >>>>>>> origin/<remotebranch>

donde HEAD es cambios en su sucursal local y origen / es cambios desde la sucursal remota. Aquí guarde las cosas que necesita y elimine las que no necesita. Después de lo que deberían hacer los pasos normales. Es decir

git add TestClass.java git commit -m "commit message" git push

Siempre sigo los pasos a continuación para evitar conflictos.

git checkout master (ven a la rama master)
git pull (actualiza tu master para obtener el último código)
git checkout -b mybranch (compra una nueva rama y comienza a trabajar en esa rama para que tu maestro siempre permanezca en la cima del tronco).
git añadir. Y git commit Y git push (en su sucursal local después de sus cambios)
git checkout master (vuelve con tu maestro)

Ahora puede hacer lo mismo y mantener la cantidad de sucursales locales que desee y trabajar de forma simultánea, simplemente haciendo un chequeo de git a su sucursal cuando sea necesario.

Sigo el proceso de abajo.

El proceso para arreglar el conflicto de fusión:

Primero, extraiga lo último de la rama de destino a la que desea fusionar git pull origin develop
A medida que obtenga lo último del destino, ahora resuelva el conflicto manualmente en IDE eliminando esos caracteres adicionales.
Haga una git addpara agregar estos archivos editados a la cola de git para que pueda ser commity pusha la misma rama en la que estamos trabajando.
Como git addse hace, haga un git commitpara confirmar los cambios.
Ahora empuje los cambios a su rama de trabajo por git push origin HEAD

Esto es todo y lo verás resuelto en tu solicitud de extracción si estás utilizando Bitbucket o GitHub.

Prueba el código de Visual Studio para editarlo si aún no lo has hecho. Lo que hace es después de tratar de fusionar (y terminar en conflictos de combinación). El código VS detecta automáticamente los conflictos de combinación.

Puede ayudarlo muy bien al mostrar cuáles son los cambios realizados en el original y en caso de que acepte incomingo

current change (es decir, original antes de fusionar) ''?.

¡Me ayudó y puede funcionar para ti también!

PS: Solo funcionará si has configurado git con tu código y Visual Studio Code.

Una forma más segura de resolver conflictos es usar git-mediate (las soluciones comunes que se sugieren aquí son bastante propensas a errores en el momento).

Vea esta publicación para una introducción rápida sobre cómo usarla.

git checkout branch1 git fetch origin git rebase -p origin/mainbranch

Si hay conflictos de fusión, corríjalos. Luego, continúe el proceso de rebase ejecutando:git rebase –-continue

Después de la reparación, puede confirmar y enviar su sucursal local a una sucursal remota.

git push origin branch1

git log --merge -p [[--] path]

No parece que siempre funcione para mí y, por lo general, termina mostrando cada confirmación que fue diferente entre las dos ramas, esto ocurre incluso cuando se usa -- para separar la ruta del comando.

Lo que hago para solucionar este problema es abrir dos líneas de comando y en una ejecución

git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

y en el otro

git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

Reemplazando $MERGED_IN_BRANCH con la rama que $MERGED_IN_BRANCH y [path] con el archivo que está en conflicto. Este comando registrará todas las confirmaciones, en forma de parche, entre ( .. ) dos confirmaciones. Si deja un lado vacío como en los comandos anteriores, git usará automáticamente HEAD (la rama en la que se está fusionando en este caso).

Esto le permitirá ver qué confirmaciones ingresaron en el archivo en las dos ramas después de que se separaron. Por lo general hace que sea mucho más fácil resolver conflictos.