¿Cómo fuerzo a "git pull" a sobrescribir los archivos locales?

¿Cómo fuerzo a "git pull" a sobrescribir los archivos locales?

¿Cómo fuerzo la sobrescritura de archivos locales en un git pull ?

El escenario es el siguiente:

  • Un miembro del equipo está modificando las plantillas de un sitio web en el que estamos trabajando
  • Están agregando algunas imágenes al directorio de imágenes (pero se olvida de agregarlas bajo el control de código fuente)
  • Me están enviando las imágenes por correo, más tarde,
  • Estoy agregando las imágenes bajo el control de código fuente y las envío a GitHub junto con otros cambios
  • No pueden extraer actualizaciones de GitHub porque Git no quiere sobrescribir sus archivos.

Este es el error que recibo:

error: el archivo de árbol de trabajo sin seguimiento 'public / images / icon.gif' se sobrescribirá mediante la combinación

¿Cómo obligo a Git a sobrescribirlos? La persona es un diseñador; por lo general, resuelvo todos los conflictos a mano, por lo que el servidor tiene la versión más reciente que solo necesita actualizar en su computadora.

Mostrar la mejor respuesta

cualquiera que lea esto y piense que podría perder archivos, he estado en esta posición y descubrí que el búfer de Sublime Text me ha salvado; si estoy trabajando en algo, borre todo accidentalmente tratando de resolver un problema similar a este o usando una respuesta a esta pregunta y he tenido los archivos abiertos en Sublime (lo cual es muy probable), entonces los archivos seguirán allí, es Sublime, ya sea allí, o en el historial de deshacer

git reset --hard origin/branch_to_overwrite

Básicamente, solo haga una extracción desde el desarrollo después del pago inicial -b. haga su trabajo, luego empuje hacia adentro.

Respuesta corta: elimine y vuelva a crear la rama. 1. Eliminar rama: git branch <branch> -D 2. Restablecer a una confirmación antes del conflicto: git reset <commit> --hard 3. Vuelva a crear la rama: git branch <branch> 4. Establezca el seguimiento en el servidor: git --set-upstream-to=origin/<branch> <branch> 5. Pull: git pull`

Para cambiar todas las terminaciones CRLF a LF, (iniciar limpio) git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .

En su lugar, puede estar buscando esta pregunta: en su lugar, stackoverflow.com/q/1628088/1148030 "Restablece la rama del repositorio local para que sea al igual que el repositorio remoto HEAD "Por ejemplo, si el control remoto ha sido empujado a la fuerza y ​​quieres tirar de él y descartar la encarnación anterior de la rama que tienes. (Algunas otras preguntas apuntan a esta pregunta como un duplicado, pero creo que deberían señalar esta otra pregunta).

Elimine manualmente todos los archivos y carpetas del repositorio local. Luego ejecute git checkout <branch> && git add -A . && git reset --hard origin/<branch> && git pull . Consulte stackoverflow.com/a/65239330 .

Definitivamente hay una respuesta a esto porque lo hice por accidente. Ahora se han ido muchas semanas de trabajo :(

Parece que la mejor manera es hacer primero:

git clean
 

Para eliminar todos los archivos sin seguimiento y luego continuar con el git pull habitual ...

Intenté usar "git clean" para resolver el mismo problema, pero no lo resolvió. git status dice "Tu rama y 'origin / master' han divergido, # y tienen 2 y 9 confirmaciones diferentes cada una, respectivamente". y git pull dice algo similar a lo que tienes arriba.

¿No necesitaría cambiar a la rama maestra y luego hacer git clean para que funcione? Luego, puede volver a la rama de desarrollo en la que estaba trabajando.

@slacy: Entonces necesitas fusionar las dos ramas.

git clean es un instrumento bastante contundente y podría tirar muchas cosas que quizás quieras conservar. Es mejor eliminar o cambiar el nombre de los archivos de los que se queja git hasta que la extracción tenga éxito.

No creo que esto funcione en general. ¿No hay una manera de hacer básicamente un clon remoto de git a través de un git pull forzado?

@mathick: git fetch origin && git reset --hard origin/master

Necesitaba agregar un -x a ese git clean para que me funcionara, por alguna razón (-d no estaba eliminando un .ideas directorio por alguna razón), pero esto solucionó mi problema, ciertamente.

Evite un paro cardíaco repentino: use git clean -n primero

¿Es git clean la mejor respuesta aquí? Parece que eliminar archivos no es necesariamente lo que quiere el OP. Pidieron "una sobrescritura de los archivos locales", no la eliminación.

git clean por sí solo no parece ayudar, la solución de @Arrowmaster está más cerca, pero una mejor de Lloyd Moore está en la siguiente respuesta.

Nunca hagas nada 'git' (ni siquiera tengas una carpeta .git) excepto en una copia de tu carpeta de trabajo real, y evita todo el estrés cardíaco. No le des a git y sus obtusos sintaxis / métodos la oportunidad de arruinarte en primer lugar.

Pruebe esto:

git reset --hard HEAD
git pull
 

Debe hacer lo que quieras.

Hice esto y algunos archivos locales que ya no estaban en repositorio se dejaron en el disco.

No creo que esto sea correcto. lo anterior realizará una fusión, no sobrescribirá lo que se solicitó en la pregunta: "¿Cómo forzar a git a sobrescribirlos?" No tengo la respuesta, actualmente la estoy buscando ... en este momento cambio a la rama con el código que quiero mantener "git checkout BranchWithCodeToKeep", luego hago "git branch -D BranchToOverwrite" y finalmente "git checkout -b BranchToOverwrite". ahora tendrá el código exacto de BranchWithCodeToKeep en la rama BranchToOverwrite sin tener que realizar una combinación.

en lugar de fusionar usando 'git pull', intente git fetch --todo seguido de 'git reset --hard origin / master'

La sugerencia de Lloyd Moore es correcta, pero tenga en cuenta que puede eliminar las confirmaciones locales no solicitadas de su rama.

sí, la solución @lloydmoore funcionó para mí. Le vendría bien ser una respuesta en lugar de un simple comentario.

Esto restablecerá los cambios actuales a la última confirmación de rama extraída. Luego, git pull fusiona los cambios de la última rama. Esto hizo exactamente lo que quería que hiciera ... ¡Gracias!

¿Esto ensuciará el control remoto?

Buena respuesta, pero agregue más detalles, quiero decir que algunas personas pueden no saber nada sobre el restablecimiento y perder sus archivos ...

@Travis R, ¿podría explicar el propósito de git rest --hard HEAD?

git reset --hard HEAD realmente no se restablece todo en algunos casos

Esto es principalmente en lo que pienso cuando pienso en forzar el tirón. Sobre todo después de que probé algunas configuraciones

Puede que este comando le resulte útil para deshacerse de los cambios locales:

git checkout <your-branch> -f
 

Y luego haga una limpieza (elimina los archivos sin seguimiento del árbol de trabajo):

git clean -f
 

Si desea eliminar directorios sin seguimiento además de archivos sin seguimiento:

git clean -fd
 

Creo que la descripción del escenario deja en claro que realmente no quiere tirar el contenido. Más bien, lo que quiere es dejar de resistirse a sobrescribir los archivos. Vea mi sugerencia.

Aunque esa respuesta podría no coincidir exactamente con la descripción, me salvó de la frustración de git jugando con los retornos de carro (evento con autocrlf falso). Cuando git reset --hard HEAD no te deja con "no" archivos modificados, estos indicadores "-f" son bastante útiles. Gracias un montón.

Puede ignorar ese archivo con un archivo en la carpeta base de su proyecto:

.gitignore

public/images/*
 

Luego, extraiga los cambios y elimine esa línea de su archivo gitignore.

Acabo de resolver esto yo mismo:

 git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp
  

donde el último comando da una lista de cuáles fueron sus cambios locales. Siga modificando la rama "tmp" hasta que sea aceptable y luego vuelva a fusionarla con la maestra con:

git checkout master && git merge tmp
 

Para la próxima vez, probablemente puedas manejar esto de una manera más limpia buscando "git stash branch", aunque es probable que stash te cause problemas en los primeros intentos, así que primero experimenta en un proyecto no crítico. .

Tuve el mismo problema. Nadie me dio esta solución, pero funcionó para mí.

Lo resolví de la siguiente manera:

  1. Elimine todos los archivos. Deje solo el directorio .git .
  2. git reset --hard HEAD
  3. git pull
  4. git push

Ahora funciona.

Aquí igual. A veces, solo la solución muy difícil funciona, sucede a menudo que solo restablecer y limpiar no son suficientes de alguna manera ...

Tuve un problema similar. Tuve que hacer esto:

git reset --hard HEAD
git clean -f
git pull
 

use git clean con precaución

ADVERTENCIA: git clean elimina todos los archivos / directorios sin seguimiento y no se puede deshacer.


A veces, solo clean -f no ayuda. En caso de que tenga DIRECTORIOS sin seguimiento, también se necesita la opción -d:

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull
 

ADVERTENCIA: git clean elimina todos los archivos / directorios sin seguimiento y no se puede deshacer.

Considere usar la marca -n (--dry-run ) primero. Esto le mostrará lo que se eliminará sin eliminar nada:

git clean -n -f -d
 

Salida de ejemplo:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...
 

Puede darle a git clean un argumento de ruta para ser más específico y evitar eliminar archivos sin seguimiento que no estén en conflicto.

Creo que la descripción del escenario deja en claro que realmente no quiere tirar el contenido. Más bien, lo que quiere es dejar de resistirse a sobrescribir los archivos. @Lauri, esto no debería haberte pasado. Desafortunadamente, la gente parece haber malinterpretado la esencia de la descripción del escenario; vea mi sugerencia.

POR FIN . git clean -f -d es útil cuando make clean no limpia todo.

Si desea sincronizar todo el directorio con el repositorio remoto, este es el camino a seguir.

@crizCraig a menos que se agreguen en .gitignore

@BleedingFingers Luego agregue -x . Pero los archivos existentes que están cubiertos por .gitignore no deberían ser un problema: suponiendo que los otros contribuyentes a ese repositorio usen el mismo archivo .gitignore , una extracción no recibirá ninguna confirmación que agregue archivos conflictivos.

@earthmeLon, para eso es posible que desee git clean -dfx . El -x ignora .gitignore. Normalmente, sus productos de compilación estarán en .gitignore.

Puede ser bueno ejecutar git clean -nfd primero, que solo muestra lo que se eliminaría antes de que se haga realmente, es decir, antes de que surja algún problema. :-)

Lo único que funcionó para mí fue:

git reset --hard HEAD~5
 

Esto le devolverá cinco confirmaciones y luego con

git pull
 

Descubrí que buscaba cómo deshacer una combinación de Git .

Esto fue lo que finalmente funcionó para mí, ya que había forzado a empujar mi rama al repositorio de origen y seguía teniendo conflictos de fusión al intentar llevarla a mi repositorio remoto.

Hola, en realidad este es un truco para un work around pero realmente efectivo. Debido a que algunos conflictos pueden ocurrir solo en unas pocas confirmaciones, revertir 5 confirmaciones asegurará que no haya conflictos con el código remoto.

Tuve el mismo problema y, por alguna razón, incluso un git clean -f -d no lo haría. Este es el motivo: por alguna razón, si Git ignora su archivo (a través de una entrada .gitignore, supongo), todavía se molesta en sobrescribirlo con un pull posterior, pero un clean no lo eliminará, a menos que agregue -x .

Tengo una situación extraña en la que ni git clean ni git reset funcionan. Tengo que eliminar el archivo en conflicto de git index utilizando el siguiente script en cada archivo sin seguimiento:

git rm [file]
 

Entonces puedo tirar sin problemas.

Creo que hay dos posibles causas de conflicto, que deben resolverse por separado y, por lo que puedo decir, ninguna de las respuestas anteriores se refiere a ambas:

  • Los archivos locales que no se rastrean deben eliminarse, ya sea manualmente (más seguro) o como se sugiere en otras respuestas, mediante git clean -f -d

  • Las confirmaciones locales que no están en la rama remota también deben eliminarse. En mi opinión, la forma más fácil de lograr esto es con: git reset --hard origin/master (reemplace 'master' por cualquier rama en la que esté trabajando y ejecute un git fetch origin primero)

Avatar RNA
Respuesta aceptada

⚠ Importante: Si tiene cambios locales, se perderán. Con o sin la opción --hard , se perderán todas las confirmaciones locales que no se hayan enviado. [*]

Si tiene archivos no rastreados por Git (por ejemplo, contenido de usuario cargado), estos archivos no se verán afectados.

Primero, ejecute una búsqueda para actualizar todas las referencias de origin/<branch> a la última:

git fetch --all
 

Haga una copia de seguridad de su rama actual:

git checkout -b backup-master
 

Entonces, tiene dos opciones:

git reset --hard origin/master
 

O si se encuentra en otra rama:

git reset --hard origin/<branch_name>
 

Explicación:

git fetch descarga lo último desde el control remoto sin intentar fusionar o reajustar nada.

Luego, el git reset restablece la rama maestra a lo que acaba de obtener. La opción --hard cambia todos los archivos en su árbol de trabajo para que coincidan con los archivos en origin/master

Mantener las confirmaciones locales actuales

[*] : Vale la pena señalar que es posible mantener las confirmaciones locales actuales creando una rama desde master antes de restablecer:

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master
 

Después de esto, todas las confirmaciones antiguas se mantendrán en new-branch-to-save-current-commits .

Cambios no confirmados

Sin embargo, los cambios no confirmados (incluso por etapas) se perderán. Asegúrate de guardar y comprometer todo lo que necesites. Para eso, puede ejecutar lo siguiente:

git stash
 

Y luego, para volver a aplicar estos cambios no confirmados:

git stash pop
 

¡Cuidado! Si tiene confirmaciones locales sin presionar, ¡esto las eliminará de su rama! Esta solución mantiene intactos los archivos sin seguimiento que no están en el repositorio, pero sobrescribe todo lo demás.

Avatar Red

Es una pregunta popular, por lo que me gustaría aclarar el comentario principal aquí. Acabo de ejecutar comandos como se describe en esta respuesta y no ha eliminado TODOS los archivos locales. Solo se sobrescribieron los archivos rastreados de forma remota y todos los archivos locales que estaban aquí se dejaron intactos.

Perdí todas las confirmaciones locales que no estaban en el árbol origin/master después de un rebase. Aquí es muy posible que te pegues un tiro en el pie.

También puede hacer esto para una rama de seguimiento si tiene la misma rama en origen y localmente, simplemente cambie git reset --hard origin / master a git reset --hard origin / (branch)

en caso de que esté extrayendo de un repositorio que tiene su nombre de rama remota diferente de "maestro", use git reset --hard origin/branch-name

Esta debería ser la respuesta aceptada. Funciona bien para mi. Sin embargo, supongo que la suposición aquí es que no tiene confirmaciones locales, lo que en mi caso es bueno ya que "local" solo posee una clave de implementación.

Avatar mcv

¿No eliminará esto también mis confirmaciones locales? Quiero mantener mis confirmaciones y solo sobrescribir los cambios sin seguimiento / no confirmados.

Solo uso "git fetch" para obtener la rama ascendente y luego reinicio cuando necesito arreglar un montón de archivos. Puede obtener la rama ascendente con "git branch -vv"

@mcv Para mantener sus confirmaciones locales, desea git reset --hard HEAD que luego podría seguir por git merge origin/master .

Dada la cantidad de votos a favor de esta pregunta y respuesta, creo que git debería incorporar un comando como git pull -f

Las confirmaciones que no fueron empujadas antes del restablecimiento completo se pueden recuperar usando git reflog , que enumera todas las confirmaciones, también aquellas sin una base. Hasta que limpies tu copia local usando git gc , entonces todo está perdido

¿Esto eliminará los archivos que tengo .gitignore'd?

@FelipeSchenone En realidad existe git pull -f , pero no hace lo que todos queremos que haga.

Para ser correcto, los cambios no comprometidos se pierden, pero las confirmaciones antiguas están colgando, esperando la recolección de basura. Aún puede verlos en git reflog y mover su HEAD hacia atrás con git reset --hard HEAD@{1} .

Quiero señalar aquí que también eliminará cualquier cambio realizado en cualquier otra rama que no se rastree de forma remota. Perdí la mía, espero que los demás tengan cuidado.

Haga una copia de seguridad de la carpeta con sus archivos locales, incluida la carpeta .git. Ahora no puede 'perder' nada si esta solución no funciona para usted; puede hacer otra copia e intentar otra cosa. No opere desde una sola carpeta y confíe en git como si fuera una herramienta de copia de seguridad 100% confiable. Un error tipográfico, especialmente en sucursales, puede ser una pesadilla. Sugiero una copia de seguridad de la vieja escuela en las carpetas tar.gz, y luego ejecutar git desde la última copia.

@Red Sí, si desea eliminar todo lo que no se rastreó, incluso ignorado, use git clean -dxf después de reiniciar por completo.

Hice esto y mis cambios locales NO se descartaron, lo cual es lamentable porque esperaba que lo fueran. ¿Alguien sabe cómo hacer esto, pero también obliga a git a descartar cualquier cambio de configuración regional que no exista en la rama remota? Básicamente, quiero una correspondencia EXACTA, 1 a 1 con la sucursal remota.

Hecho poco conocido: en realidad, puede hacer una copia de seguridad de todo su repositorio de git con un tar -czf myrepodir.tar.gz myrepodir/. antiguo. Si su repositorio se estropea debido a la rareza de git, elimínelo y restaure desde el archivo tar.gz para REALMENTE volver a donde estaba antes de intentar este experimento desafortunado. ¡Solo asegúrese de tener el . después de myrepodir/ o su .git y otros archivos ocultos no se guardarán!

¿Puede esta técnica funcionar para archivos individuales? por ejemplo, -- index.php helpers.js ect. en lugar de --all ?

no funcionó para mí. probé esta solución, probé git clean -dfx . probé git pull -f . todavía tengo el mismo mensaje de error.

Tenga en cuenta que puede abreviar el nombre de la rama con @{u} , que es mucho más corto.

@GershomMaes git clean -dfx después del restablecimiento completo, como se menciona anteriormente en IceGlow ?

¿No es más fácil simplemente rm -rf / folder y hacer git clone nuevamente, si desea descartar todos sus cambios locales?

Cuando uses git clean -dffx , asegúrate de ejecutarlo desde directorio de nivel superior del proyecto git . Es una buena idea ejecutar git clean -ndffx primero para enumerar los archivos antes de que se eliminen, ya que -x elimina los archivos .gitignored y no mostrados por git status

Avatar Sz.

@JonB: "¿no es más fácil simplemente rm -rf / folder y hacer git clone de nuevo ...?" Un gran repositorio (ni siquiera demasiado) + ancho de banda bajo me trajo aquí. Me encantaría volver a clonar, pero la primera vez fue lo suficientemente doloroso, así que soy de los que buscan una solución más rápida.

funcionó para mí cuando la rama fuente contenía actualizaciones como cambios de nombre de archivos de "general" a "General". En Windows, no importa cuál sea el caso, por lo que este enfoque me desbloqueó.

Mercurial tiene hg update pero no hay equivalente en git ...

Sería más consistente si pudiera hacer git pull --force y simplemente sobrescribiría su sucursal local. Viendo que puede hacer lo contrario, sobrescribiendo el control remoto con git push --force

Perdí todas mis confirmaciones locales con tus comandos sugeridos.

Tenga en cuenta que la rama maestra ahora se llama rama principal de forma predeterminada, así que preste atención a los copiadores, ya que es posible que estos comandos ya no funcionen.

perdón. Demasiado complicado. Simplemente elimínelo y clone nuevamente en su lugar ...

Si ejecuta git checkout -b backup-master, debe volver a su rama (master en el ejemplo) antes de ejecutar git reset. De lo contrario, puede usar git branch backup-master en su lugar para crear la rama de respaldo pero permanecer en master.

Advertencia, hacer esto eliminará permanentemente sus archivos si tiene alguna entrada de directorio / * en su archivo gitignore.

Algunas respuestas parecen terribles. Terrible en el sentido de lo que le sucedió a @Lauri al seguir la sugerencia de David Avsajanishvili.

Más bien (git> v1.7.6):

git stash --include-untracked
git pull
 

Más tarde puedes limpiar el historial de alijo.

Manualmente, uno por uno:

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}
 

Brutalmente, todo a la vez:

$ git stash clear
 

Por supuesto, si quieres volver a lo que escondiste:

$ git stash list
...
$ git stash apply stash@{5}
 

¿No está asumiendo que nunca se ha realizado una confirmación? En mi caso, hice varias confirmaciones en mi sucursal local, pero quería "restablecer" todo de nuevo a la sucursal remota

No, no lo creo. El almacenamiento solo elimina los archivos no comprometidos. Lo anterior también mueve (almacena) archivos que git no rastrea. Esto evita que los archivos que se han agregado al control remoto, que aún no se han transferido a su máquina, pero que usted ha creado (!), Se eliminen. Todo sin destruir el trabajo no comprometido. ¿Espero que tenga sentido?

Si no tiene 1.7.6, puede imitar --include-untracked simplemente git add temporalmente, guardando todo su repositorio y luego guardándolo inmediatamente.

Estoy de acuerdo con Hedgehog. Si hace las respuestas populares aquí, es más que probable que descubra que ha matado inadvertidamente muchas cosas que realmente no quería perder.

Tenía otros archivos sin seguimiento, además del que la combinación / extracción quería sobrescribir, por lo que esta solución funcionó mejor. git stash apply recuperó todos mis archivos sin seguimiento con la excepción (con razón) de los que la fusión ya había creado: "ya existe, sin pago". Funcionó perfectamente.

Esta puede ser la forma más fácil de administrar un repositorio sin querer, como lo que le sucedió a @Lauri, pero peor porque cree que está protegiendo archivos para que no se eliminen. Si tiene una regla .gitignore que tiene un comodín, despídase de ella. Explicación

Esta es la respuesta más limpia y debería ser la aceptada. Para ahorrar algo de escritura, puede usar la forma corta: git stash -u .

El enlace sobre git stash, que incluye carpetas de destrucción sin seguimiento que están gitignored, está muerto, busquemos un reemplazo. Mientras tanto, el comentario de @Waif sobre cómo esta respuesta puede destruir carpetas gitignore'd debe ser votado y, preferiblemente, convertido en una nueva respuesta. El problema de GitLab que vinculó tiene detalles. Utilizo mucho git stash y me sorprendió mucho saber que puede destruir archivos.

Al igual que Hedgehog, creo que las respuestas son terribles. Pero aunque la respuesta de Hedgehog podría ser mejor, no creo que sea tan elegante como podría ser. La forma en que encontré para hacer esto es usando fetch y merge con una estrategia definida. Lo que debería hacer que sus cambios locales se conserven siempre que no sean uno de los archivos con los que está intentando forzar una sobrescritura.

Primero haz una confirmación de tus cambios

 git add *
 git commit -a -m "local file server commit message"
 

A continuación, obtenga los cambios y sobrescriba si hay un conflicto

 git fetch origin master
 git merge -s recursive -X theirs origin/master
 

-X es un nombre de opción y theirs es el valor de esa opción. Está eligiendo usar cambios de their (la otra opción es cambios de ours ) si hay un conflicto.

Esta es la mejor respuesta que he visto hasta ahora. No lo he probado, pero a diferencia de otras respuestas, esto no intenta destruir todos sus archivos sin seguimiento, lo cual es muy peligroso por razones obvias.

Ditto: esto funcionó para mí cuando hice una fusión muy grande (solicitud de extracción de GitHub) en la que solo quería aceptarlo todo además de lo que tenía. ¡Buena respuesta! En mi caso, los dos últimos comandos fueron: 1) get fetch other-repo ; 2) git merge -s recursive -X theirs other-repo/master

Esto sobrescribirá cualquier conflicto con los archivos de los repositorios y no con los locales, ¿correcto?

La mejor respuesta. La respuesta más alta aceptada me dejó en mi caso con la cabeza indiferente. Volví a la rama maestra local y ejecuté git merge -X theirs origin/master

Intenté esto, luego agregue / confirme mis nuevos archivos modificados, pero aún dije que mi rama estaba detrás del control remoto cuando intenté presionar. Mucho tiempo perdido porque "git pull" no pregunta "¿Sobrescribir local? Y / n / all".

Espera ... ¿no tiene git add * y git commit -a <more-options-here> tienen el mismo efecto? ¿Por qué necesitarías ambos?

@ MarcelStör no necesitas ambos pero tampoco hacen lo mismo. git commit -a solo tiene ese efecto en los archivos que ya están rastreados; git add * agregará archivos que no se rastrean. Entonces, si hace git commit -a , no capturará archivos nuevos, entonces es posible que deba hacer un git add después, pero si lo hace git add * no lo hará necesita -a en la confirmación.

El problema con esta (excelente) respuesta es que agrega todos los archivos locales, que a veces pueden no ser lo que desea. Es posible que desee agregar los archivos específicos que se omitieron. Pero lo mejor de esto es que lo lleva a hacer lo que debería haber hecho: agregarlos localmente. Probablemente no necesite la estrategia -X suya, ya que son la misma imagen. De hecho, sugiero dejarlo al principio, solo para averiguar si hay alguna anomalía, y agregarlo si lo hay, después de revisar que 'suyo' es siempre la opción correcta. Pero entonces, estoy paranoico.

Solo quería que el maldito git sobrescribiera todo y se callara. después de todo, solo lo estoy usando entre mi PC de trabajo y algunos sistemas Raspberry Pi. Deseando una opción de sobrescritura forzada, al menos para el líder del proyecto

después de probar este comando, todavía obtengo el mismo error "los archivos del árbol de trabajo sin seguimiento se sobrescribirán mediante la fusión" y una lista larga pero incompleta de los archivos que no puedo simplemente forzar a sobrescribirlos.

hmmm ... tal vez intente git add . primero

En primer lugar, pruebe la forma estándar:

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!
 

Advertencia : los comandos anteriores pueden provocar la pérdida de datos / archivos solo si no los ha confirmado. Si no está seguro, primero haga una copia de seguridad de toda la carpeta del repositorio.

Luego, jálalo de nuevo.

Si lo anterior no ayuda y no le importan sus archivos / directorios sin seguimiento (haga la copia de seguridad primero por si acaso), pruebe los siguientes pasos simples:

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again
 

Esto ELIMINARÁ todos los archivos git (excempt .git/ dir, donde tiene todas las confirmaciones) y los extraerá nuevamente.


¿Por qué git reset HEAD --hard podría fallar en algunos casos?

  1. Reglas personalizadas en .gitattributes file

    Tener la regla eol=lf en .gitattributes podría hacer que git modifique algunos cambios de archivo convirtiendo los finales de línea CRLF en LF en algunos archivos de texto.

    Si ese es el caso, debe confirmar estos cambios CRLF / LF (revisándolos en git status ), o intente: git config core.autcrlf false para ignorarlos temporalmente.

  2. Incompatibilidad del sistema de archivos

    Cuando utiliza un sistema de archivos que no admite atributos de permisos. Por ejemplo, tiene dos repositorios, uno en Linux / Mac (ext3 / hfs+ ) y otro en un sistema de archivos basado en FAT32 / NTFS.

    código> lo intentas, git siempre detecta algunos "cambios".

El problema con todas estas soluciones es que son demasiado complejas o, un problema aún mayor, es que eliminan todos los archivos sin seguimiento del servidor web, lo cual no queremos, ya que siempre hay archivos de configuración necesarios. que están en el servidor y no en el repositorio de Git.

Aquí está la solución más limpia que estamos usando:

 # Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull
  
  • El primer comando obtiene los datos más recientes.

  • El segundo comando verifica si hay archivos que se están agregando al repositorio y borra los archivos sin seguimiento del repositorio local que podrían causar conflictos.

  • El tercer comando comprueba todos los archivos que se modificaron localmente.

  • Finalmente, hacemos un tirón para actualizar a la versión más reciente, pero esta vez sin ningún conflicto, ya que los archivos sin seguimiento que están en el repositorio ya no existen y todos los archivos modificados localmente ya son los mismos que en el repositorio.

Usar "git merge origin / master" como última línea (como dice en su nota) en lugar de "git pull" será más rápido, ya que ya ha eliminado los cambios del repositorio de git.

Sí, por supuesto, git merge origin/master será más rápido y probablemente incluso más seguro. Dado que si alguien empujó nuevos cambios durante la eliminación de archivos de este script (lo que no es probable que suceda, pero es posible), toda la extracción podría fallar. La única razón por la que puse pull allí es porque es posible que alguien no esté trabajando en la rama maestra, sino en alguna otra rama y quería que el script fuera universal.

Si ha creado archivos localmente como archivos de opciones, colóquelos en .gitignore .

En lugar de fusionar con git pull , intente esto:

git fetch --all

seguido de:

git reset --hard origin/master .

Restablezca el índice y el encabezado a origin/master , pero no restablezca el árbol de trabajo:

git reset origin/master
 

Personalmente, encontré esto muy útil. Luego mantiene su árbol de trabajo para que pueda registrarlo nuevamente. Para mi problema, se eliminaron los mismos archivos que se agregaron, por lo que se atascó. Extraño, lo sé.

Basado en mis propias experiencias similares, la solución ofrecida por Strahinja Kustudic arriba es, con mucho, la mejor. Como han señalado otros, simplemente hacer un restablecimiento completo eliminará todos los archivos sin seguimiento que podrían incluir muchas cosas que no desea eliminar, como archivos de configuración. Lo que es más seguro es eliminar solo los archivos que están a punto de agregarse y, para el caso, es probable que también desee verificar cualquier archivo modificado localmente que esté a punto de actualizarse.

Teniendo esto en cuenta, actualicé el guión de Kustudic para hacer precisamente eso. También solucioné un error tipográfico (faltaba 'en el original).

 #/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull
  

Usar "git merge origin / master" como última línea (como dice en su nota) en lugar de "git pull" será más rápido, ya que ya ha eliminado los cambios del repositorio de git.

Se necesita la comprobación de archivos modificados, por lo que esto funciona el 100% de las veces. Actualicé mi script con eso hace mucho tiempo, pero también olvidé actualizar aquí. También lo uso un poco diferente a ti. Reviso archivos que tienen algún tipo de modificación, no solo M, por lo que funciona todo el tiempo.

En lugar de hacer:

git fetch --all
git reset --hard origin/master
 

Le aconsejo que haga lo siguiente:

git fetch origin master
git reset --hard origin/master
 

No es necesario buscar todos los controles remotos y las ramas si va a restablecer la rama de origen / maestra, ¿verdad?

Su respuesta es justo lo que necesitaba para su representante. Debo preguntar, ¿esto también elimina todos los archivos sin seguimiento?

Sí, la mayor parte de mi representante viene de aquí :) Esto también eliminará todos los archivos sin seguimiento. Algo que había olvidado y me recordó dolorosamente hace solo 2 días ...

Consulte los comentarios sobre esta otra respuesta: stackoverflow.com/a/8888015/2151700

Esto no eliminó mis archivos sin seguimiento; que es en realidad lo que esperaba. ¿Hay alguna razón por la que podría serlo para algunas personas y no para otras?

Los archivos sin seguimiento no se ven afectados por git reset. Si desea que también se eliminen, haga git add . primero, antes de git reset --hard

Esto es exactamente lo que necesitaba: algo que sobrescriba los archivos sin seguimiento que existen en el control remoto y deja todo lo demás intacto.

Parece que la mayoría de las respuestas aquí se centran en la rama master ; sin embargo, hay ocasiones en las que estoy trabajando en la misma rama de función en dos lugares diferentes y quiero que un rebase en uno se refleje en el otro sin muchos saltos.

Basado en una combinación de respuesta de ARN y respuesta de torek a una pregunta similar , se me ocurrió esto que funciona espléndidamente:

git fetch
git reset --hard @{u}
 

Ejecute esto desde una sucursal y solo restablecerá su sucursal local a la versión anterior.

Esto también se puede poner en un alias de git (git forcepull ):

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

O, en su archivo .gitconfig :

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"
 

¡Disfruta!

Esta respuesta también es buena porque funciona independientemente de la rama en la que se encuentre.

Estos cuatro comandos me funcionan.

git reset --hard HEAD
git checkout origin/master
git branch -D master
git checkout -b master
 

Para verificar / extraer después de ejecutar estos comandos

git pull origin master
 

Intenté mucho, pero finalmente tuve éxito con estos comandos.

"git branch -D master" elimina la rama. así que ten cuidado con eso. Prefiero usar "git checkout origin / master -b " que crea una nueva rama con un nuevo nombre y ya necesitas 3,4 líneas. También se recomienda utilizar "git clean -f".

A pesar de la pregunta original, las respuestas principales pueden causar problemas a las personas que tienen un problema similar, pero no quieren perder sus archivos locales. Por ejemplo, vea los comentarios de Al-Punk y crizCraig.

La siguiente versión confirma los cambios locales en una rama temporal (tmp ), comprueba la rama original (que supongo que es master ) y fusiona las actualizaciones. Podrías hacer esto con stash , pero he descubierto que generalmente es más fácil usar simplemente el enfoque de rama / fusión.

git checkout -b tmp
git add *; git commit -am "my temporary files"
git checkout master

git fetch origin master
git merge -s recursive -X theirs origin master
 

donde asumimos que el otro repositorio es origin master .

Una forma más sencilla sería:

git checkout --theirs /path/to/file.extension
git pull origin master
 

Esto anulará su archivo local con el archivo en git

Resumí otras respuestas. Puede ejecutar git pull sin errores:

git fetch --all
git reset --hard origin/master
git reset --hard HEAD
git clean -f -d
git pull
 

Advertencia : esta secuencia de comandos es muy eficaz, por lo que podría perder los cambios.

Esto sobrescribirá los archivos modificados (archivos que se registraron previamente) y eliminará los archivos sin seguimiento (archivos que nunca se han registrado). Exactamente lo que estaba buscando, gracias!

Sospecho que la tercera línea git reset --hard HEAD puede ser redundante; mi página de manual local (2.6.3) dice que reset en la segunda línea git reset --hard origin/master "por defecto es HEAD en todas las formas".

@arichards Creo que su sospechoso tiene razón, pero si la segunda línea no funciona (por cualquier motivo), la tercera línea funciona bien para restablecer. Esta solución no necesita optimizarse. Solo resumí otras respuestas. Eso es todo. Gracias por tu comentario. :)

Gracias por el resumen. Estos pasos son realmente poderosos :)

Requisitos:

  1. Realice un seguimiento de los cambios locales para que nadie aquí los pierda.
  2. Haga que el repositorio local coincida con el repositorio de origen remoto.

Solución:

  1. Esconda los cambios locales.
  2. Obtener con una limpieza de archivos y directorios ignorando .gitignore y restablecimiento completo al origen .

    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    

Conozco un método mucho más fácil y menos doloroso:

$ git branch -m [branch_to_force_pull] tmp
$ git fetch
$ git checkout [branch_to_force_pull]
$ git branch -D tmp
 

¡Eso es todo!

Intenté hacer lo que se sugiere en esta respuesta. NINGÚN ARCHIVO se extrajo del repositorio remoto. En realidad, no es muy sorprendente cuando se piensa en ello; después de todo, no hay ninguna referencia a origin/<branch_to_force_pull> .

Usé este comando para deshacerme de los archivos locales que me impiden hacer una extracción / fusión. ¡Pero ten cuidado! Ejecute git merge … primero para ver si solo hay aquellos archivos que realmente desea eliminar.

git merge origin/master 2>&1 >/dev/null | grep ^[[:space:]] | sed s/^[[:space:]]//g | xargs -L1 rm
 
  • git merge enumera, entre otras cosas, todos esos archivos. Están precedidos por un espacio en blanco.
  • 2>&1 >/dev/null redirige la salida de error a la estándar para que sea detectada por grep .
  • grep ^[[:space:]] filtra solo las líneas con nombres de archivo.
  • sed s/^[[:space:]]//g recorta el espacio en blanco desde el principio.
  • xargs -L1 rm llama a rm en cada uno de esos archivos, eliminándolos.

Manéjelo con cuidado: cualquier git merge que salga, se llamará al rm para cada línea que comience con un espacio en blanco.

Solo hazlo

git fetch origin branchname
git checkout -f origin/branchname // This will overwrite ONLY new included files
git checkout branchname
git merge origin/branchname
 

Para evitar todos los efectos secundarios no deseados, como eliminar archivos o directorios que deseaba conservar, etc.

Lindo. Al usar primero checkout -f en la rama desde la que quería fusionar, eso eliminó todos los archivos problemáticos sin seguimiento. Luego pude volver a pagar mi destino y finalmente fusionarme sin problemas.

Bonificación:

Al hablar de pull / fetch / merge 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 me ahorró mucho tiempo.

Antes de enviar su nueva confirmación al servidor, pruebe este comando y sincronizará automáticamente los últimos cambios del servidor (con una búsqueda + combinación) y colocará su confirmación en la parte superior del registro de Git. No hay necesidad de preocuparse por la combinación / extracción manual.

Encuentra detalles en ¿Qué hace "git pull --rebase"? .

En resumen: git pull -r .

En mi caso, antes de hacer eso, tuve que 1) git add -A , 2) git commit -m 3) y finalmente git pull rebase . Gracias.

Leí todas las respuestas, pero estaba buscando un solo comando para hacer esto. Aquí esta lo que hice. Se agregó un alias de git a .gitconfig

[alias]
      fp = "!f(){ git fetch ${1} ${2} && git reset --hard ${1}/${2};};f"
 

Ejecute su comando como

git fp origin master
 

equivalente a

git fetch origin master
git reset --hard origin/master
 

Estaba tratando de usar la rama Material2 en Angular2-Webpack-Starter y lo pasé genial. Esta era la única forma en que podía descargar y usar esa rama.

git clone --depth 1 https://github.com/angularclass/angular2-webpack-starter.git

cd angular2-webpack-starter/

git checkout -b material2
 

Abra la carpeta del proyecto y elimine todos los archivos y carpetas no ocultos. Deje todos los ocultos.

git add .

git commit -m "pokemon go"

git reset --hard

git pull origin material2
 

(Cuando aparezca el editor, presione ': wq' y luego presione Enter )

Ahora está listo.

Esta es la mejor práctica para revertir los cambios:

  • git commit Confirme sus cambios por etapas para que se guarden en reflog (ver más abajo)
  • git fetch Obtenga los últimos cambios ascendentes
  • git reset --hard origin/master Restablecimiento completo a la rama maestra de origen

El reflog registra las ramas y otras referencias que se actualizan en el repositorio local. . O simplemente, el reflog es el historial de sus cambios .

Por eso, comprometerse siempre es una buena práctica. Las confirmaciones se añaden al reflog, lo que garantiza que siempre tendrá una forma de recuperar el código eliminado.

No use git reset --hard . Eso borrará sus cambios que bien pueden ser completamente indeseables. En su lugar:

git pull
git reset origin/master
git checkout <file1> <file2> ...
 

Por supuesto, puede usar git fetch en lugar de git pull ya que claramente no se fusionará, pero si usualmente tira, tiene sentido continuar tirando aquí.

Entonces, lo que sucede aquí es que git pull actualiza su origen / referencia maestra ; git reset actualiza la referencia de su sucursal local para que sea la misma que origin / master sin actualizar ningún archivo, por lo que su estado extraído no cambia; luego, git checkout revierte los archivos al estado de índice de su sucursal local según sea necesario. En los casos en los que se haya agregado exactamente el mismo archivo en vivo y en el maestro ascendente, el índice ya coincide con el archivo después del reinicio, por lo que en el caso común no es necesario hacer git checkout en absoluto.

Si la rama ascendente también contiene confirmaciones que desea aplicar automáticamente, puede seguir una variación sutil del proceso:

git pull
git merge <commit before problem commit>
git reset <problem commit>
git checkout <file1> <file2> ...
git pull
 

En Windows, ejecute este único comando:

git fetch --all & git reset --hard origin/master
 

¿Por qué sería diferente a, por ejemplo, Linux? ¿Qué implementación / paquete particular de git usas? ¿Y / o en qué entorno (por ejemplo, MinGW)?

No estoy seguro, solo estoy seguro de que funciona en Windows. En linux, ¿cuál es el separador para concatenar dos comandos en una sola línea? (no la tubería, simplemente concatenar sin pasar la salida)

si desea restablecer la rama de seguimiento remoto de forma genérica, utilice:

git fetch
git reset --keep origin/$(git rev-parse --abbrev-ref HEAD)
 

si también desea restablecer sus cambios locales:

git fetch
git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)
 

Si se encuentra usando esto con frecuencia, agregue un atajo de bash alias gplf='git fetch && echo "HEAD was at $(git rev-parse --short HEAD)" && git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)'

Brillante. ¡Gracias! La gente no considera los scripts automatizados al responder. Esto es muy elegante cuando simplemente no puede pasar el nombre de la rama.

1: restablecer a una confirmación anterior

git reset --hard HEAD
 

2: Eliminar archivos sin seguimiento

git clean -f
 

3: tira de las confirmaciones

git pull
 

Fuentes:

git fetch --all && git reset --hard origin/master && git pull

git fetch --all
 

entonces, si estás en la rama maestra

git reset --hard origin/master
 

más

git reset --hard origin/master<branch_name>
 

El último fragmento debe ser origin/<branch_name> no origin/master<branch_name> .

puede probar git pull --force o tal vez esconder sus confirmaciones usando git stash y luego ejecutando git pull

Esto no funciona. fatal: refusing to merge unrelated histories

Automatic merge failed; fix conflicts and then commit the result.

No: error: The following untracked working tree files would be overwritten by merge: , no me importan esos archivos. Si solo fueran dos o tres, simplemente los eliminaría. Pero hay tantos.

Hice esto para que funcionara:

En la computadora donde creé la nueva rama:

git push --all
 

En la computadora donde quería que se mostrara la nueva rama:

git fetch --all
 

Como a menudo necesito una forma rápida de restablecer la rama actual en Windows a través del símbolo del sistema, aquí hay una forma rápida:

for /f "tokens=1* delims= " %a in ('git branch^|findstr /b "*"') do @git reset --hard origin/%b
 

Una vez que hagas git pull, obtendrás una lista de archivos que no coinciden. Si la cantidad de archivos no es muy grande, puede verificar esos archivos, esta acción sobrescribirá esos archivos.

git checkout -

Por lo general, lo hago si, para una verificación rápida, modifico los archivos locales en el servidor (no hay ninguna razón recomendada y probable detrás de que obtenga este problema: D), verifico los archivos modificados después de encontrar una solución.

A pesar de que esta pregunta ya tiene muchas respuestas, la pregunta original es resolver esta pregunta

error: el archivo de árbol de trabajo sin seguimiento 'public / images / icon.gif' se sobrescribirá mediante la combinación

Dado que los archivos binarios no se pueden combinar, una respuesta simple es

git checkout public/images/icon.gif
 

Con eso el archivo recuperará el estado anterior que tenía en esta rama.

Normalmente hago git stash si no quiero perder mis cambios o algo como git checkout . si no me preocupan los archivos modificados localmente. En mi opinión, mucho más simple que reset --hard , clean ... y todas estas cosas más adecuadas para dejar la rama como en remoto, incluidas confirmaciones, archivos sin seguimiento, en lugar de simplemente resolver una modificación local archivo.

Creo que también puede forzar mediante git push -f / git push --force

La pregunta es sobre tirar, no empujar.

Probé la mayor parte de lo que pude encontrar aquí, ninguno funcionó en mi caso.

Lo que funcionó fue git merge -X theirs

Paso 1 . (opcional)
Desde la raíz de su repositorio local, guarde una copia de seguridad y vaciar la carpeta actual :

mkdir -p ../<branch>-bkp && mv --backup=t * ../<branch>-bkp
 

Paso 2 . Descargue todos los archivos y carpetas de la rama desde el repositorio remoto:

git checkout <branch> && git add -A . && git reset --hard origin/<branch> && git pull
 

donde debe reemplazar <branch> con el nombre de la rama desea sobrescribir.

<”Comentarios:

  • Es posible que prefiera hacer una copia de seguridad manualmente y eliminar los archivos actuales y carpetas en lugar del paso 1 .
    De hecho, recomiendo hacer esto con un manejador de archivos en la GUI de su sistema operativo.
  • Si omite el paso 1 , tenga cuidado: perderá todo el trabajo en el repositorio!
  • Importante: si omite git pull en el paso 2 ,
    ¡corre el riesgo de no obtener la última versión del repositorio remoto !
    Según la segunda referencia a continuación, git reset --hard
    restablece el área de preparación y el directorio de trabajo para que coincidan con la mayoría confirmación reciente .
    ¡Mi experiencia contradice esta afirmación!
  • Si ejecuta git reset --hard origin/<branch_to_overwrite> sin eliminar primero todos los archivos y carpetas de su repositorio local, tenga en cuenta que cualquier archivo basura que aún esté por ahí puede colarse en el control remoto repositorio en un git push posterior, incluso si esa no era su intención.
    El git add -A . adicional en el paso 2 evita que esto suceda si elija omitir el paso 1 .

Referencias:
https://gitforwindows.org/
https://www.atlassian.com/git/tutorials/undoing- cambios / git-reset
https://www.atlassian.com/git/tutorials/rewriting- history / git-reflog

Puede probar:

$ git fetch --all
$ git reset --hard origin/master 
$ git pull
 

¡Esto funcionó muy bien para mí!

git fetch --all
git reset --hard origin/master