Restablezca la rama del repositorio local para que sea como el repositorio remoto HEAD

¿Cómo restablezco mi rama local para que sea igual que la rama en el repositorio remoto?

Yo hice:

git reset --hard HEAD

Pero cuando corro 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

¿Puede decirme por qué tengo estos 'modificados'? No he tocado estos archivos? Si lo hice, quiero eliminarlos.

La configuración de su rama para que coincida exactamente con la rama remota se puede hacer en dos pasos:

git fetch origin
git reset --hard origin/master

Si desea guardar el estado actual de su sucursal antes de hacerlo (por si acaso), puede hacer lo siguiente:

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

Ahora su trabajo se guarda en la rama "mi-trabajo-guardado" en caso de que decida que desea recuperarlo (o si desea verlo más tarde o compararlo con su rama actualizada).

Tenga en cuenta que el primer ejemplo supone que el nombre del repositorio remoto es "origen" y que la rama llamada "maestro" en el repositorio remoto coincide con la rama actualmente desprotegida en su repositorio local.

Por cierto, esta situación en la que se encuentra se parece mucho a un caso común en el que se ha realizado un empuje en la rama actualmente desprotegida de un repositorio no descubierto. ¿Ingresaste recientemente a tu repositorio local? De lo contrario, no se preocupe, algo más debe haber causado que estos archivos terminen modificados inesperadamente. De lo contrario, debe tener en cuenta que no se recomienda ingresar a un repositorio no desnudo (y no a la rama actualmente desprotegida, en particular).

Tenía que hacer (la solución en la respuesta aceptada):

git fetch origin
git reset --hard origin/master

Seguido por:

git clean -f

para eliminar archivos locales

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

git clean -n -f

Primero, reinicie a la búsqueda anterior HEADde la rama ascendente correspondiente:

git reset --hard @{u}

La ventaja de especificar @{u}o su forma detallada @{upstream}es que el nombre del repositorio remoto y la rama no tienen que especificarse explícitamente.

A continuación, según sea necesario, elimine los archivos no rastreados, opcionalmente también con -x:

git clean -df

Finalmente, según sea necesario, obtenga los últimos cambios:

git pull

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

Si tiene varias confirmaciones, esto no funcionará.

Lo que probablemente quiera hacer es restablecer la cabecera de origen o como se llame su repositorio remoto. Probablemente solo haría algo como

git reset --hard origin/HEAD

Pero ten cuidado. Los reinicios duros no se pueden deshacer fácilmente. Es mejor hacer lo que Dan sugiere, y ramificar una copia de sus cambios antes de reiniciar.

Todas las sugerencias anteriores son correctas, pero a menudo para realmente restablecer su proyecto, también necesita eliminar incluso los archivos que están en su .gitignore.

Para obtener el equivalente moral de borrar el directorio de su proyecto y volver a clonar desde el control remoto es:

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

Advertencia : git clean -x -d -fes irreversible y puede perder archivos y datos (por ejemplo, cosas que ha ignorado usar .gitignore).

Usa los comandos a continuación. Estos comandos también eliminarán todos los archivos no rastreados de git local

git fetch origin
git reset --hard origin/master
git clean -d -f

La pregunta mezcla dos cuestiones aquí:

1. cómo restablecer una rama local al punto donde está el control remoto
2. cómo borrar su área de preparación (y posiblemente el directorio de trabajo), por lo que git statusdicenothing to commit, working directory clean.

La respuesta única es:

1. git fetch --prune _{^{(opcional) Actualiza la instantánea local del repositorio remoto. Otros comandos son solo locales.}}
   git reset --hard @{upstream}_{^{Coloca el puntero de la rama local en el lugar donde se encuentra la instantánea del control remoto, y establece el índice y el directorio de trabajo en los archivos de esa confirmación.}}
2. git clean -d --force _{^{Elimina archivos y directorios no rastreados que dificultan que git diga "limpieza de directorio de trabajo".}}

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

También agregué un mensaje "¿estás seguro?" Y algunos resultados

#!/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

Siempre que el repositorio remoto sea origin, y que le interese branch_name:

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

Además, debe restablecer la rama actual de origina HEAD.

git fetch origin
git reset --hard origin/HEAD

Cómo funciona:

git fetch origin descarga lo último desde el control remoto sin intentar fusionar o volver a crear nada.

Luego git resetrestablece la <branch_name>rama a lo que acaba de obtener. La --hardopción cambia todos los archivos en su árbol de trabajo para que coincidan con los archivos origin/branch_name.

Yo hice:

git branch -D master
git checkout master

restablecer totalmente la rama

tenga en cuenta que debe pagar a otra sucursal para poder eliminar la sucursal requerida

Aquí hay un script que automatiza lo que sugiere la respuesta más popular ... Consulte https://stackoverflow.com/a/13308579/1497139 para obtener una versión mejorada que admite sucursales

#!/bin/bash
# reset the current repository
# WF 2012-10-15
# see /programming/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

Si tuvo un problema como yo, que ya ha cometido algunos cambios, pero ahora, por cualquier motivo que desee deshacerse de él, la forma más rápida es usarlo git resetasí:

git reset --hard HEAD~2

Tenía 2 commits no necesarios, de ahí el número 2. Puede cambiarlo a su propio número de commits para restablecer.

Entonces, responda su pregunta: si tiene 5 confirmaciones por delante del repositorio remoto HEAD, debe ejecutar este comando:

git reset --hard HEAD~5

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

Las respuestas anteriores suponen que la rama a restablecer es la rama actual (desprotegida). En los comentarios, OP hap497 aclaró que la rama está desprotegida, pero la pregunta original no lo requiere explícitamente. Como hay al menos una pregunta "duplicada", restablezca la rama completamente al estado del repositorio , lo que no supone que la rama esté desprotegida, aquí hay una alternativa:

Si la rama "mybranch" no está actualmente desprotegida, para restablecerla a la cabeza de la rama remota "myremote / mybranch", puede usar este comando de bajo nivel :

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

Este método deja la rama desprotegida como está y el árbol de trabajo intacto. Simplemente mueve la cabeza de mybranch a otra confirmación, lo que sea que se dé como segundo argumento. Esto es especialmente útil si es necesario actualizar varias ramas a nuevos cabezales remotos.

Sin embargo, tenga cuidado al hacer esto, y use gitko una herramienta similar para verificar el origen y el destino. Si accidentalmente hace esto en la rama actual (y git no lo mantendrá alejado de esto), puede confundirse, porque el contenido de la nueva rama no coincide con el árbol de trabajo, que no cambió (para corregir, actualizar la rama nuevamente, a donde estaba antes).

Esto es lo que uso a menudo:

git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;

Tenga en cuenta que es una buena práctica de no hacer cambios a su maestro local / desarrollar rama, pero en lugar de pagar a otra rama para cualquier cambio, con el nombre de la sucursal antepuesto por el tipo de cambio, por ejemplo feat/, chore/, fix/, etc. De esta manera sólo se necesitan tire de los cambios, no empuje ningún cambio desde el maestro. Lo mismo para otras ramas a las que otros contribuyen. Por lo tanto, lo anterior solo debe usarse si ha cometido cambios en una rama a la que otros se han comprometido y necesita restablecerse. De lo contrario, en el futuro, evite presionar a una rama a la que otros presionan, en lugar de pagar y enviar a dicha rama a través de la rama desprotegida.

Si desea restablecer su sucursal local a la última confirmación en la rama ascendente, lo que funciona para mí hasta ahora es:

Verifique sus controles remotos, asegúrese de que su origen y origen sean lo que espera, si no es como se esperaba, use git remote add upstream <insert URL>, por ejemplo, el repositorio original de GitHub del que bifurcó, y / o git remote add origin <insert URL of the forked GitHub repo>.

git remote --verbose

git checkout develop;
git commit -m "Saving work.";
git branch saved-work;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force

En GitHub, también puede pagar la rama con el mismo nombre que la local, para guardar el trabajo allí, aunque esto no es necesario si el desarrollo de origen tiene los mismos cambios que la rama local de trabajo guardado. Estoy usando la rama de desarrollo como ejemplo, pero puede ser cualquier nombre de rama existente.

git add .
git commit -m "Reset to upstream/develop"
git push --force origin develop

Luego, si necesita fusionar estos cambios con otra rama mientras existen conflictos, preservando los cambios en el desarrollo, use:

git merge -s recursive -X theirs develop

Mientras uso

git merge -s recursive -X ours develop

para preservar los cambios conflictivos de branch_name. De lo contrario, use una herramienta de combinación con git mergetool.

Con todos los cambios juntos:

git commit -m "Saving work.";
git branch saved-work;
git checkout develop;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;
git add .;
git commit -m "Reset to upstream/develop";
git push --force origin develop;
git checkout branch_name;
git merge develop;

Tenga en cuenta que en lugar de upstream / desarrollo, podría usar un hash de confirmación, otro nombre de rama, etc. Use una herramienta CLI como Oh My Zsh para verificar que su rama sea verde, lo que indica que no hay nada que confirmar y que el directorio de trabajo está limpio ( que es confirmado o también verificable por git status). Tenga en cuenta que esto puede agregar realmente compromete en comparación a aguas arriba a desarrollar si hay algo añadido automáticamente por un commit, por ejemplo, diagramas UML, cabeceras de licencia, etc., por lo que en ese caso, se podría entonces tirar de los cambios en la origin developque upstream develop, si es necesario.

La respuesta

git clean -d -f

fue subestimado ( -d para eliminar directorios). ¡Gracias!

Si desea volver al HEADestado del directorio de trabajo y del índice, debería hacerlo git reset --hard HEAD, en lugar de hacerlo HEAD^. (Esto puede haber sido un error tipográfico, al igual que para el guión simple versus doble --hard).

En cuanto a su pregunta específica de por qué esos archivos aparecen en el estado modificado, parece que quizás hizo un restablecimiento parcial en lugar de un restablecimiento completo. Esto hará que los archivos que se modificaron en la HEADconfirmación aparezcan como si estuvieran en escena, lo que probablemente es lo que está viendo aquí.

Ninguna cantidad de reinicio y limpieza pareció tener ningún efecto en los archivos no rastreados y modificados en mi repositorio git local (probé todas las opciones anteriores). Mi única solución a esto fue confirmar el repositorio local y volver a clonarlo desde el control remoto.

Afortunadamente no tenía otras ramas que me importaran.

xkcd: Git

La única solución que funciona en todos los casos que he visto es eliminar y volver a colocar. Tal vez hay otra forma, pero obviamente de esta manera no hay posibilidad de que el viejo estado se quede allí, así que lo prefiero. Bash one-liner puede establecer como macro si a menudo arruina 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 archivos .git no están dañados

¿Has olvidado crear una rama de características y te has comprometido directamente en master por error?

Puede crear la rama de características ahora y volver a configurar el maestro sin afectar el árbol de trabajo (sistema de archivos local) para evitar generar compilaciones, pruebas y problemas con los bloqueos de archivos:

git checkout -b feature-branch
git branch -f master origin/master

Solo 3 comandos lo harán funcionar

git fetch origin
git reset --hard origin/HEAD
git clean -f

Si no le importa guardar sus cambios locales, pero aún así desea actualizar su repositorio para que coincida con el origen / HEAD, simplemente puede esconder sus cambios locales y luego extraer:

git stash
git pull