git checkouttiene la --oursopción de verificar la versión del archivo que tenía localmente (en oposición a --theirscuál es la versión que introdujo). Puedes pasar .a git checkoutdecirle que revise todo en el árbol. Luego, debe marcar los conflictos como resueltos, lo que puede hacer git addy comprometer su trabajo una vez hecho:
git checkout --ours . # checkout our local version of all files
git add -u # mark all conflicted files as merged
git commit # commit the merge
Tenga .en cuenta el en el git checkoutcomando. Eso es muy importante y fácil de perder. git checkouttiene dos modos; uno en el que cambia las ramas y otro en el que extrae los archivos del índice a la copia de trabajo (a veces, primero los saca al índice de otra revisión). La forma en que se distingue es si ha pasado un nombre de archivo; si no ha pasado un nombre de archivo, intenta cambiar de rama (aunque si no pasa tampoco, solo intentará volver a revisar la rama actual), pero se niega a hacerlo si hay archivos modificados que eso afectaría. Entonces, si desea un comportamiento que sobrescribirá los archivos existentes, debe pasar .o un nombre de archivo para obtener el segundo comportamiento git checkout.
También es un buen hábito tener, al pasar un nombre de archivo, para compensarlo con --, como git checkout --ours -- <filename>. Si no hace esto, y el nombre de archivo coincide con el nombre de una rama o etiqueta, Git pensará que desea verificar esa revisión, en lugar de verificar ese nombre de archivo, y así usar la primera forma del checkoutcomando .
Expandiré un poco sobre cómo funcionan los conflictos y la fusión en Git. Cuando se fusiona en el código de otra persona (que también ocurre durante una extracción; una extracción es esencialmente una búsqueda seguida de una fusión), hay pocas situaciones posibles.
Lo más simple es que estás en la misma revisión. En este caso, ya está "actualizado" y no sucede nada.
Otra posibilidad es que su revisión sea simplemente un descendiente suyo, en cuyo caso, de forma predeterminada, tendrá una "fusión de avance rápido", en la que HEADsimplemente se actualiza a su confirmación, sin que ocurra la fusión (esto puede desactivarse si usted realmente quiero grabar una fusión, usando--no-ff ).
Luego entras en las situaciones en las que realmente necesitas fusionar dos revisiones. En este caso, hay dos resultados posibles. Una es que la fusión ocurre limpiamente; Todos los cambios están en archivos diferentes, o están en los mismos archivos pero lo suficientemente separados como para que ambos conjuntos de cambios puedan aplicarse sin problemas. Por defecto, cuando una fusión limpia sucede, se compromete de forma automática, aunque se puede desactivar esto con --no-commitsi usted necesita para editar antemano (por ejemplo, si cambia el nombre de función fooa bar, y otra persona añade un nuevo código que llama foo, que se fusionarán limpiamente , pero produzca un árbol roto, por lo que es posible que desee limpiarlo como parte de la confirmación de fusión para evitar tener confirmaciones dañadas).
La posibilidad final es que haya una fusión real y haya conflictos. En este caso, Git va a hacer la mayor cantidad de la fusión, ya que puede, y producen archivos con marcas de conflicto ( <<<<<<<, =======y >>>>>>>) en su copia de trabajo. En el índice (también conocido como "área de preparación"; el lugar donde se almacenan los archivos git addantes de confirmarlos), tendrá 3 versiones de cada archivo con conflictos; existe la versión original del archivo del antepasado de las dos ramas que está fusionando, la versión de HEAD(su lado de la fusión) y la versión de la rama remota.
Para resolver el conflicto, puede editar el archivo que está en su copia de trabajo, eliminando los marcadores de conflicto y arreglando el código para que funcione. O bien, puede consultar la versión desde uno u otro lado de la fusión, usando git checkout --ourso git checkout --theirs. Una vez que haya colocado el archivo en el estado que desea, indica que ha terminado de fusionar el archivo y que está listo para comprometerse a usarlo git add, y luego puede hacerlo git commit.