restaurar - revertir cambios en un archivo git
¿Restablecer o revertir un archivo específico a una revisión específica usando Git? (27)
Realicé algunos cambios en un archivo que se ha comprometido varias veces como parte de un grupo de archivos, pero ahora quiero restablecer / revertir los cambios en él a una versión anterior.
He hecho un git log junto con un git diff para encontrar la revisión que necesito, pero no tengo ni idea de cómo recuperar el archivo a su estado anterior en el pasado.
Muchas respuestas aquí afirman usar git reset ... <file> o git checkout ... <file> pero al hacerlo, perderá todas las modificaciones en <file> cometidas después del commit que desea revertir.
Si desea revertir los cambios de una confirmación en un solo archivo, al igual que git revert haría, pero solo para un archivo (o diga un subconjunto de los archivos de confirmación), le sugiero que use tanto git diff como git apply así ( con <sha> = el hash de la confirmación que desea revertir):
git diff <sha>^ <sha> path/to/file.ext | git apply -R
Básicamente, generará primero un parche correspondiente a los cambios que desea revertir, y luego aplicará el parche de forma inversa para soltar esos cambios.
Por supuesto, no funcionará si las líneas revertidas han sido modificadas por cualquier compromiso entre <sha1> y HEAD (conflicto).
Puede revisar rápidamente los cambios realizados en un archivo usando el comando diff:
git diff <commit hash> <filename>
Luego, para revertir un archivo específico a esa confirmación, use el comando de reinicio:
git reset <commit hash> <filename>
Es posible que necesite usar la opción --hard si tiene modificaciones locales.
Un buen flujo de trabajo para gestionar waypoints es utilizar etiquetas para marcar puntos en su línea de tiempo. No puedo entender tu última oración, pero lo que puedes desear es divergir de una rama de un punto anterior en el tiempo. Para hacer esto, use el útil comando de pago:
git checkout <commit hash>
git checkout -b <new branch name>
A continuación, puede volver a establecer la base en su línea principal cuando esté listo para combinar esos cambios:
git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>
git revert <hash>
Revertirá un compromiso determinado. Parece que piensas que git revert solo afecta la confirmación más reciente.
Eso no resuelve su problema, si desea revertir un cambio en un archivo específico y esa confirmación cambió más que ese archivo.
Tienes que tener cuidado cuando dices "revertir". Si solía tener una versión de un archivo en commit $ A, y luego realizó dos cambios en dos commits por separado $ B y $ C (entonces lo que está viendo es la tercera iteración del archivo), y si usted dice " Quiero retroceder al primero ", ¿realmente lo dices en serio?
Si desea deshacerse de los cambios tanto en la segunda como en la tercera iteración, es muy simple:
$ git checkout $A file
y luego comprometes el resultado. El comando pregunta "Quiero verificar el archivo desde el estado registrado por el commit $ A".
Por otro lado, lo que usted quiso decir es deshacerse del cambio de la segunda iteración (es decir, comprometer $ B) ingresada, mientras se mantiene lo que commit $ C le hizo al archivo, usted desearía revertir $ B
$ git revert $B
Tenga en cuenta que quien creó commit $ B puede no haber sido muy disciplinado y haber cometido un cambio totalmente diferente en la misma confirmación, y esta reversión puede afectar a otros archivos que no sean archivos, puede ver cambios ofensivos, por lo que puede verificar el resultado cuidadosamente después de hacer asi que.
Esto funcionó para mí:
git checkout <commit hash> file
Luego comprometa el cambio:
git commit -a
Creo que lo encontré ... de http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
Algunas veces solo quieres regresar y olvidarte de cada cambio más allá de cierto punto porque están todos equivocados.
Empezar con:
$ git log
que muestra una lista de confirmaciones recientes y sus hashes SHA1.
Luego, escribe:
$ git reset --hard SHA1_HASH
para restaurar el estado de una confirmación determinada y borrar todas las confirmaciones más recientes del registro de forma permanente.
Obviamente, alguien necesita escribir un libro inteligible en git, o git necesita explicarse mejor en la documentación. Enfrentado con este mismo problema, supuse que
cd <working copy>
git revert master
Desharía el último commit que parece hacer.
Ian
Y para volver a la última versión confirmada, que se necesita con mayor frecuencia, puede usar este comando más simple.
git checkout HEAD file/to/restore
Si sabe cuántos commits necesita volver, puede usar:
git checkout master~5 image.png
Esto supone que estás en la rama master y que la versión que quieres son 5 confirmaciones.
Use git log para obtener la clave hash para la versión específica y luego use git checkout <hashkey>
Nota: No olvide escribir el hash antes del último. Last hash apunta a su posición actual (HEAD) y no cambia nada.
git checkout -- foo
Eso restablecerá foo en HEAD. Tú también puedes:
git checkout HEAD^ foo
para una revisión posterior, etc.
git checkout ref | commitHash - filePath
p.ej
git checkout HEAD~5 -- foo.bar
or
git checkout 048ee28 -- foo.bar
Tengo que conectar EasyGit aquí, que es un envoltorio para que git sea más accesible para los principiantes sin confundir a los usuarios experimentados. Una de las cosas que hace es dar más significados a git revert . En este caso, simplemente diría:
eg revert foo/bar foo/baz
En el caso de que desee revertir un archivo a una confirmación previa (y el archivo que desea revertir ya comprometido) puede usar
git checkout HEAD^1 path/to/file
o
git checkout HEAD~1 path/to/file
Luego solo realiza una etapa y confirma la "nueva" versión.
Armado con el conocimiento de que un compromiso puede tener dos padres en el caso de una combinación, debe saber que HEAD ^ 1 es el primer padre y HEAD ~ 1 es el segundo padre.
Cualquiera de los dos funcionará si solo hay un padre en el árbol.
Para ir a una versión de confirmación anterior del archivo, obtenga el número de confirmación, por ejemplo, eb917a1.
git checkout eb917a1 YourFileName
Si solo necesitas volver a la última versión comprometida
git reset HEAD YourFileName
git checkout YourFileName
Esto simplemente lo llevará al último estado comprometido del archivo
Así es como funciona rebase :
git checkout <my branch> git rebase master git checkout master git merge <my branch>
Supongamos que tiene
---o----o----o----o master /---A----B <my branch>
Los primeros dos comandos ... commit git checkout git rebase master
... revisa la rama de cambios que deseas aplicar a la rama master . El comando rebase toma las confirmaciones de <my branch> (que no se encuentran en el master ) y las vuelve a aplicar al jefe del master . En otras palabras, el padre del primer compromiso en <my branch> ya no es una confirmación previa en el historial master , sino el jefe actual del master . Los dos comandos son los mismos que:
git rebase master <my branch>
Puede ser más fácil recordar este comando ya que las ramas "base" y "modificar" son explícitas.
. El resultado final de la historia es:
---o----o----o----o master /----A''----B'' <my branch>
Los últimos dos comandos ...
git checkout master
git merge <my branch>
... realice una combinación de avance rápido para aplicar todos los cambios de <my branch> en master . Sin este paso, la confirmación de rebase no se agrega al master . El resultado final es:
---o----o----o----o----A''----B'' master, <my branch>
master y <my branch> ambos referencia B'' . Además, a partir de este punto, es seguro eliminar la referencia <my branch> .
git branch -d <my branch>
De manera divertida, ''git checkout foo'' no funcionará si la copia de trabajo está en un directorio llamado foo; sin embargo, tanto ''git checkout HEAD foo'' como ''git checkout ./foo'':
$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo
Puedes usar cualquier referencia a un commit de git, incluido el SHA-1 si es más conveniente. El punto es que el comando se ve así:
git checkout [commit-ref] -- [filename]
Tenga en cuenta, sin embargo, que git checkout ./foo y git checkout HEAD ./foo no son exactamente lo mismo; caso en punto:
$ echo A > foo
$ git add foo
$ git commit -m ''A'' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A
(El segundo add el archivo en el índice, pero no se compromete).
Git checkout ./foo significa revertir la ruta ./foo del índice ; la adición de HEAD instruye a Git para revertir esa ruta en el índice a su revisión HEAD antes de hacerlo.
Muchas sugerencias aquí, la mayoría a lo largo de las líneas de git checkout $revision -- $file . Un par de alternativas oscuras:
git show $revision:$file > $file
Y también, uso mucho esto solo para ver temporalmente una versión en particular:
git show $revision:$file | less
o
git show $revision:$file | vim -R -
(OBS: $file necesita un prefijo ./ si es una ruta relativa para git show $revision:$file to work)
Y el aún más extraño:
git archive $revision $file | tar -x0 > $file
git-aliases, awk y shell-functions al rescate!
git prevision <N> <filename>
donde <N> es el número de revisiones del archivo para deshacer para el archivo <filename> .
Por ejemplo, para pagar la revisión anterior inmediata de un solo archivo x/y/zc , ejecute
git prevision -1 x/y/z.c
¿Cómo funciona la previsión de git?
Agregue lo siguiente a su gitconfig
[alias]
prevision = "!f() { git checkout `git log --oneline $2 | awk -v commit="$1" ''FNR == -commit+1 {print $1}''` $2;} ;f"
El comando básicamente
- realiza un
git logen el archivo especificado y- selecciona la identificación de compromiso apropiada en el historial del archivo y
- ejecuta un
git checkouta la identificación de compromiso para el archivo especificado.
Esencialmente, todo lo que uno haría manualmente en esta situación,
envuelto en un git-alias hermoso y eficiente - git-prevision
Aquí está mi camino.
a) En Android Studio, abra el archivo.
b) git -> Mostrar historial, encuentra el compromiso anterior al que quiero revertir. Obtenga el commit_id (es decir, commit hash).
c) git checkout commit_id file_path
Para mí, ninguna de las respuestas parecía clara y, por lo tanto, me gustaría agregar la mía, que parece muy fácil.
Tengo un commit abc1 y después he hecho varias (o una modificación) a un archivo file.txt .
Ahora digo que metí la pata en algo en el archivo file.txt y quiero volver a una confirmación anterior abc1 .
1. git checkout file.txt : esto eliminará los cambios locales, si no los necesitas
2. git checkout abc1 file.txt : esto traerá su archivo a su versión deseada
3. git commit -m "Restored file.txt to version abc1" : esto comprometerá su reversión.
-
git push: esto empujará todo en el repositorio remoto
Entre los pasos 2 y 3, por supuesto, puedes hacer el git status para entender lo que está sucediendo. Por lo general, debería ver el file.txt ya agregado y es por eso que no hay necesidad de git add .
Primero restablecer la cabeza para el archivo de destino
git reset HEAD path_to_file
Segundo pago ese archivo
git checkout -- path_to_file
Tuve el mismo problema ahora y encontré esta respuesta más fácil de entender ( commit-ref es el valor SHA del cambio en el registro al que desea volver):
git checkout [commit-ref] [filename]
Esto colocará esa versión anterior en su directorio de trabajo y desde allí puede confirmarla si lo desea.
Si está utilizando extensiones de Git y solo desea volver a la confirmación principal para el archivo, puede seleccionar la confirmación que contiene los cambios que desea revertir, luego seleccione la pestaña ''Diferencia'' en el panel de detalles, haga clic con el botón derecho. el archivo que desea revertir, luego ''Restablecer archivo (s)'' a ''..., luego'' A ''(el padre)
Suponiendo que el hash de la confirmación que desea es c5f567 :
git checkout c5f567 -- file1/to/restore file2/to/restore
La página man de git checkout brinda más información.
Si desea volver a la confirmación antes de c5f567 , agregue ~1 (funciona con cualquier número):
git checkout c5f567~1 -- file1/to/restore file2/to/restore
Como nota al margen, siempre me he sentido incómodo con este comando porque se usa tanto para cosas comunes (cambiando entre sucursales) como para cosas inusuales y destructivas (descartando cambios en el directorio de trabajo).