¿Cómo puedo descartar cambios remotos y marcar un archivo como "resuelto"?

Tengo algunos archivos locales, los extraigo de una rama remota y hay conflictos. Sé que me gustaría mantener mis cambios locales e ignorar los cambios remotos que causan conflictos. ¿Hay algún comando que pueda usar para decir "marcar todos los conflictos como resueltos, usar local"?

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.

Asegúrese del origen del conflicto: si es el resultado de a git merge, vea la respuesta de Brian Campbell .

Pero si es el resultado de a git rebase, para descartar los cambios remotos (sus) y usar los cambios locales , deberá hacer lo siguiente:

git checkout --theirs -- .

Consulte " ¿Por qué se invierte el significado de" ours"y" theirs" " para ver cómo oursytheirs se intercambian durante un rebase (porque la rama ascendente está desprotegida).