Restablecer la twig de repository local para que sea como el repository remoto HEAD

¿Cómo puedo restablecer mi twig local para que sea como la sucursal en el repository remoto?

Yo si:

git reset --hard HEAD 

Pero cuando ejecuto un git status ,

 On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: java/com/mycompany/TestContacts.java modified: java/com/mycompany/TestParser.java 

¿Puedes decirme por qué tengo estos 'modificados'? No he tocado estos files? Si lo hiciera, quiero eliminarlos.

Configurar su twig para que coincida exactamente con la twig remota se puede hacer en dos pasos:

 git fetch origin git reset --hard origin/master 

Si desea save el estado de su sucursal actual antes de hacer esto (por si acaso), puede hacer:

 git commit -a -m "Saving my work, just in case" git branch my-saved-work 

Ahora su trabajo se guarda en la twig "my-saved-work" en caso de que decida que lo quiere de nuevo (o quiere verlo más tarde o diferirlo contra su twig actualizada).

Tenga en count que en el primer ejemplo se supone que el nombre del repository remoto es "origen" y que la twig denominada "principal" en el repository remoto coincide con la twig actualmente pagada en su repository local.

Por cierto, esta situación en la que te encuentras se parece muchísimo a un caso común en el que se ha realizado un esfuerzo en la twig actualmente desprotegida de un repository no vacío. ¿Recientemente presionó en su repository local? Si no es así, entonces no hay problema: otra cosa debe haber causado que estos files terminen de forma inesperada modificados. De lo contrario, debe tener en count que no se recomienda insert en un repository no vacío (y no en la twig actualmente desprotegida, en particular).

Necesitaba hacer (la solución en la respuesta aceptada):

 git fetch origin git reset --hard origin/master 

Seguido por:

 git clean -f 

para eliminar files locales

Para ver qué files se eliminarán (sin eliminarlos realmente):

 git clean -n -f 

git reset --hard HEAD realidad solo se restablece al último estado comprometido. En este caso, HEAD se refiere a la CABEZA de su twig.

Si tienes varias confirmaciones, esto no funcionará …

Lo que probablemente desee hacer es restablecer al jefe de origen o lo que sea que se llame a su repository remoto. Probablemente haga algo como

 git reset --hard origin/HEAD 

Ten cuidado, sin embargo. Los restablecimientos fuertes no se pueden deshacer fácilmente. Es mejor hacer lo que Dan sugiere y ramificar una copy de tus cambios antes de reiniciar.

Primero, reinicie a la HEAD previamente captada de la twig ascendente correspondiente:

 git reset --hard @{u} 

La ventaja de especificar @{u} o su forma verbosa @{upstream} es que el nombre del repository y la sucursal remotos no tienen que especificarse explícitamente.

A continuación, obtenga los últimos cambios:

 git pull 

Todo lo anterior sugiere que es correcto, pero a menudo para restablecer realmente tu proyecto, también necesitas eliminar incluso los files que están en tu .gitignore .

Para get el equivalente moral de borrar su directory de proyecto y volver a clonar desde el control remoto, se encuentra:

 git fetch git reset --hard git clean -x -d -f 

Advertencia : git clean -x -d -f es irreversible y puede perder files y datos (por ejemplo, cosas que ha ignorado usando .gitignore ).

La pregunta mezcla dos problemas aquí:

  1. cómo restablecer una sucursal local al punto donde está el control remoto
  2. cómo borrar tu área de preparación (y posiblemente el directory de trabajo), para que el git status nothing to commit, working directory clean. diga nothing to commit, working directory clean.

La respuesta única es:

  1. git fetch --prune (opcional) Actualiza la instantánea local del repository remoto. Los commands adicionales son solo locales.
    git reset --hard @{upstream} Coloca el puntero de la twig local en el lugar donde se encuentra la instantánea del control remoto, y establece el índice y el directory de trabajo en los files de esa confirmación.
  2. git clean -d --force Elimina files y directorys no rastreados que impiden que git diga "working directory clean".

Esto es algo a lo que me enfrento regularmente, y he generalizado el script que Wolfgang proporcionó anteriormente para trabajar con cualquier twig

También agregué un post "¿estás seguro?" Y algunos comentarios

 #!/bin/bash # reset the current repository # WF 2012-10-15 # AT 2012-11-09 # see http://stackoverflow.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head timestamp=`date "+%Y-%m-%d-%H_%M_%S"` branchname=`git rev-parse --symbolic-full-name --abbrev-ref HEAD` read -p "Reset branch $branchname to origin (y/n)? " [ "$REPLY" != "y" ] || echo "about to auto-commit any changes" git commit -a -m "auto commit at $timestamp" if [ $? -eq 0 ] then echo "Creating backup auto-save branch: auto-save-$branchname-at-$timestamp" git branch "auto-save-$branchname-at-$timestamp" fi echo "now resetting to origin/$branchname" git fetch origin git reset --hard origin/$branchname 

Aquí hay una secuencia de commands que automatiza lo que sugiere la respuesta más popular … Consulte http://sofes.miximages.com/a/13308579/1497139 para get una versión mejorada que admita sucursales.

 #!/bin/bash # reset the current repository # WF 2012-10-15 # see http://sofes.miximages.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head timestamp=`date "+%Y-%m-%d-%H_%M_%S"` git commit -a -m "auto commit at $timestamp" if [ $? -eq 0 ] then git branch "auto-save-at-$timestamp" fi git fetch origin git reset --hard origin/master 

Yo si:

 git branch -D master git checkout master 

para reiniciar totalmente la twig


tenga en count que debe realizar el pago en otra sucursal para poder eliminar la sucursal requerida

Si tuviste un problema como yo, que ya has realizado algunos cambios, pero ahora, por cualquier motivo, quieres deshacerte de él, la forma más rápida es usar git reset esta manera:

 git reset --hard HEAD~2 

Tuve 2 commits no necesarios, de ahí el número 2. Puedes cambiarlo a tu propio número de commits para reiniciar.

Para responder a su pregunta, si tiene 5 confirmaciones antes del repository remoto HEAD, debe ejecutar este command:

 git reset --hard HEAD~5 

Tenga en count que perderá los cambios que ha realizado, ¡así que tenga cuidado!

Siempre que el repository remoto sea de origin y que esté interesado en branch_name :

 git fetch origin git reset --hard origin/<branch_name> 

Cómo funciona:

git fetch origen de git fetch descarga lo último del control remoto sin intentar unir o rebase nada.

Luego, el git reset restablece la twig principal a lo que acaba de get. La opción --hard cambia todos los files en su tree de trabajo para hacer coincidir los files en origin/branch_name .

Si quiere volver al estado HEAD tanto para el directory de trabajo como para el índice, entonces debe git reset --hard HEAD , en lugar de HEAD^ . (Esto puede haber sido un error tipográfico, al igual que el guión único versus doble para --hard .)

En cuanto a su pregunta específica sobre por qué esos files aparecen en el estado como modificados, parece que tal vez hizo un restablecimiento parcial en lugar de un restablecimiento completo. Esto hará que los files que se cambiaron en el HEAD muestren como si estuvieran representados, lo que probablemente sea lo que está viendo aquí.

Las respuestas anteriores asumen que la twig que se reinicia es la twig actual (desprotegida). En los comentarios, OP hap497 aclaró que la twig está realmente desprotegida, pero esto no está explícitamente requerido por la pregunta original. Como hay al less una pregunta "duplicada", restablecer la bifurcación completamente al estado del repository , lo que no supone que la twig esté desprotegida, aquí hay una alternativa:

Si la twig "mybranch" no está actualmente desprotegida, para restablecerla a la sucursal remota "myremote / mybranch", puede usar este command de bajo nivel :

 git update-ref refs/heads/mybranch myremote/mybranch 

Este método deja la twig desprotegida tal como está y el tree de trabajo intacto. Simplemente mueve la cabeza de mybranch a otro compromiso, lo que se da como el segundo argumento. Esto es especialmente útil si se deben actualizar múltiples twigs a nuevas cabezas remotas.

Sin embargo, gitk cuidado al hacer esto y use gitk o una herramienta similar para verificar el origen y el destino. Si accidentalmente haces esto en la twig actual (y git no te evitará esto), puedes confundirte, porque el nuevo contenido de la twig no coincide con el tree de trabajo, que no cambió (para arreglar, actualizar la twig nuevamente, a donde estaba antes).

Ninguna cantidad de reinicio y limpieza parecía tener ningún efecto en los files no registrados y modificados en mi repository local de git (probé todas las opciones anteriores). Mi única solución a esto era registrar el repository local y volver a clonarlo desde el control remoto.

Afortunadamente, no tenía otras twigs que me importasen.

La única solución que funciona en todos los casos que he visto es eliminar y volver a sellar. Tal vez haya otra forma, pero obviamente esta forma no deja ninguna posibilidad de que el viejo estado quede allí, así que lo prefiero. Bash one-liner puedes establecerlo como una macro si a menudo desorderas las cosas en git:

 REPO_PATH=$(pwd) && GIT_URL=$(git config --get remote.origin.url) && cd .. && rm -rf $REPO_PATH && git clone --recursive $GIT_URL $REPO_PATH && cd $REPO_PATH 

* asume que tus files .git no están corruptos

Si no te importa save tus cambios locales, y aun así quieres actualizar tu repository para que coincida con origin / HEAD, puedes esconder tus cambios locales y luego extraer:

 git stash git pull 

Si desea que los cambios actuales se utilicen más tarde y luego oculte los cambios, puede usar estos dos commands,

 git fetch origin git reset --hard origin/master