Cuando Git no puede combinar dos ramas automáticamente, se detiene y deja los cambios en conflicto para que usted los concilie. En un Mac, use git status para encontrar los archivos afectados, compare ambas versiones, edite cada conflicto para lograr un resultado combinado intencionado, y luego prepare (stage) y finalice la fusión. La clave es preservar la intención de ambos cambios, no aceptar ciegamente una de las partes ni asumir que mantener ambos bloques producirá código funcional.

Confirme la operación y proteja las modificaciones no terminadas

Abra Terminal o el terminal integrado de su editor, navegue hasta el repositorio y compruebe su estado:

cd "/path/to/repository"
git status

Utilice la ruta de carpeta real en lugar del ejemplo. El estado de Git le indica qué archivos no están fusionados y si la operación es un merge, rebase u otra acción. Este artículo cubre una fusión (merge). En una fusión ordinaria, Git mantiene la rama actual en su lugar mientras espera a que usted resuelva los conflictos; las rutas que se fusionaron sin problemas ya están actualizadas, mientras que las rutas en conflicto requieren revisión. Documentación de git merge de Git

Si tiene trabajo sin confirmar (uncommitted) anterior a la fusión, tenga cuidado de no sobrescribirlo mientras edita. Git documenta git merge --abort como una forma de detener una fusión, pero advierte que es posible que no siempre reconstruya los cambios no confirmados preexistentes. Si el estado no es claro, guarde una copia independiente de las modificaciones locales importantes antes de continuar. Aborte solo cuando tenga la intención de detener la fusión e inspeccione el estado resultante después. Instrucciones de Git para conflictos de fusión

Interprete cada conflicto como dos propuestas

Abra cada archivo listado en un editor de texto. Por lo general, un conflicto de texto se marca de la siguiente manera:

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

El texto situado por encima de ======= corresponde generalmente a la versión de la rama actual; el texto situado por debajo suele ser el de la rama que se está fusionando. Las etiquetas pueden variar. Git registra el ancestro común y las versiones de ambas ramas en el índice, y el archivo de trabajo muestra un resultado con marcas de conflicto para que usted lo edite. Documentación sobre merge de Git

Considere las dos secciones como evidencia de los cambios previstos, no como opciones que deba aceptar en su totalidad. Pregúntese qué intentaba lograr cada edición. Un lado puede añadir una condición de validación mientras que el otro cambia el nombre de un campo; preservar ambos puede implicar combinarlos en una única condición actualizada. En el caso de un conflicto a nivel de archivo, como cuando una parte elimina un archivo mientras la otra lo edita, decida si el archivo debe conservarse y, de ser así, incorpore las ediciones necesarias. Si la intención no es evidente a partir de las líneas, inspeccione el código circundante o consulte al autor del cambio antes de decidir.

Elimine todos los marcadores de conflicto y redacte una versión final coherente. No se limite a dejar ambos bloques de forma consecutiva, a menos que eso sea lo que el programa o documento deba contener. Mantener ambos puede duplicar declaraciones, sobrescribir comportamientos o generar una sintaxis no válida. Por el contrario, elegir solo un bloque puede descartar el trabajo útil de la otra rama. La resolución correcta depende del archivo circundante y del propósito de cada cambio.

Revise y prepare (stage) los archivos resueltos

Guarde el archivo editado y luego inspeccione los cambios. Para un archivo en conflicto, git diff muestra el trabajo de resolución de conflictos aún presente en su árbol de trabajo. Compruebe todo el contexto circundante, no solo las líneas marcadas. Busque marcadores restantes con la función de búsqueda de su editor, o use este comando en el repositorio:

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)'

Si encuentra coincidencias, revíselas: la documentación legítima o los archivos de prueba pueden contener estas cadenas, por lo que no elimine las coincidencias de manera indiscriminada. Una vez que el resultado de un archivo sea el correcto, prepárelo indicando a git add su ruta entre comillas, por ejemplo git add "Sources/Example.swift". Preparar el archivo (staging) le indica a Git que el conflicto del archivo ha sido resuelto; esto no demuestra que el resultado sea correcto. Las instrucciones de Git son editar cada conflicto, añadir las rutas resueltas y luego hacer commit o continuar con la fusión. Documentación sobre merge de Git

Para un flujo de trabajo visual en Mac, Visual Studio Code lista los archivos en conflicto en Merge Changes dentro de Control de código fuente (Source Control). Abra un archivo y use sus acciones de conflicto integradas (inline) o Open in Merge Editor para inspeccionar el lado actual, el lado entrante y el resultado. La acción Accept Both Changes del editor mantiene ambas secciones de forma consecutiva; revise el archivo resultante y combine o ajuste el contenido según sea necesario. Guarde el resultado y prepare el archivo en Control de código fuente. Estos controles pertenecen a VS Code; otros editores pueden usar diferentes etiquetas o funciones. Guía de conflictos de fusión de VS Code

Finalice la fusión y verifique el resultado

Después de resolver y preparar cada archivo en conflicto, vuelva a comprobar el estado:

git status
git diff --cached

Revise el diff de los cambios preparados para asegurarse de que ambas contribuciones previstas aparezcan de forma adecuada en la versión final y que no se hayan incluido modificaciones ajenas. Ejecute las verificaciones pertinentes del proyecto si están disponibles; Git no puede determinar si la lógica combinada se comporta según lo previsto.

Para una fusión mediante la línea de comandos, complete la operación con git merge --continue (o confirme la fusión mediante commit cuando Git se lo indique). El parámetro --continue de Git comprueba que haya una fusión en curso antes de crear el commit. A continuación, ejecute git status de nuevo para confirmar que la fusión ya no está en curso. Si Git informa de más conflictos, resuelva y prepare también esos archivos. Instrucciones de fusión de Git

Un conflicto se resuelve de forma segura cuando el archivo final contempla deliberadamente el trabajo previsto de ambas ramas, el diff preparado coincide con ese resultado y la fusión se ha completado. Cuando no pueda determinar qué pretendía lograr una de las partes, deténgase y obtenga ese contexto antes de descartarlo o reescribirlo.

Fuentes