Cloné un repositorio remoto de git hace aproximadamente un mes. El repositorio remoto ha sufrido muchos cambios y ahora se ha vuelto inestable. Ahora necesito otra copia del repositorio, versión idéntica a la que cloné hace un mes.
¿Cómo hago esto?
Cloné un repositorio remoto de git hace aproximadamente un mes. El repositorio remoto ha sufrido muchos cambios y ahora se ha vuelto inestable. Ahora necesito otra copia del repositorio, versión idéntica a la que cloné hace un mes.
¿Cómo hago esto?
Respuestas:
Puede "restablecer" su repositorio a cualquier confirmación que desee (por ejemplo, hace 1 mes).
Use git-reset para eso:
git clone [remote_address_here] my_repo
cd my_repo
git reset --hard [ENTER HERE THE COMMIT HASH YOU WANT]
master
rama, que está desprotegida por defecto en un clon. Si una rama que no master
sea su rama de desarrollo principal debe verificarse antesgit reset
git checkout -b new_branch hash
para crear una nueva rama basada en el hash sin tocar ninguna otra rama. Mover la cabeza de una sucursal existente puede causar problemas cuando es hora de enviar algo a un servidor remoto.
git pull origin [branch]
contrario, afaik, se pierde.
Puedes usar simplemente
git checkout commithash
en esta secuencia
git clone `URLTORepository`
cd `into your cloned folder`
git checkout commithash
commit hash se parece a esto "45ef55ac20ce2389c9180658fdba35f4a663d204"
git reset --hard
debe evitar a favor de a git checkout commit-hash
. A git reset --hard
elimina parte del historial de git que a veces no es deseable.
git init
no es necesario
Use git log
para encontrar la revisión a la que desea revertir y tome nota del hash de confirmación. Después de eso, tienes 2 opciones:
Si planea confirmar algo después de esa revisión, le recomiendo que realice el pago en una nueva sucursal:git checkout -b <new_branch_name> <hash>
Si no planea comprometer nada después de esa revisión, simplemente puede pagar sin una rama: git checkout <hash>
- NOTA: Esto colocará su repositorio en un estado 'HEAD separado', lo que significa que actualmente no está conectado a ninguna rama, entonces usted ' tendrá un poco de trabajo extra para fusionar nuevos commits a una rama real .
Ejemplo:
$ git log
commit 89915b4cc0810a9c9e67b3706a2850c58120cf75
Author: Jardel Weyrich <suppressed>
Date: Wed Aug 18 20:15:01 2010 -0300
Added a custom extension.
commit 4553c1466c437bdd0b4e7bb35ed238cb5b39d7e7
Author: Jardel Weyrich <suppressed>
Date: Wed Aug 18 20:13:48 2010 -0300
Missing constness.
$ git checkout 4553c1466c437bdd0b4e7bb35ed238cb5b39d7e7
Note: moving to '4553c1466c437bdd0b4e7bb35ed238cb5b39d7e7'
which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 4553c14... Missing constness.
De esta forma, no pierde ninguna información, por lo que puede pasar a una nueva revisión cuando se estabilice.
git checkout develop
desarrollar el nombre de su sucursal.
A diferencia de los sistemas de control de versiones centralizados, Git clona todo el repositorio, por lo que no solo obtiene los archivos remotos actuales, sino todo el historial. Su repositorio local incluirá todo esto.
Puede haber etiquetas para marcar una versión en particular en ese momento. Si no, puede crearlos usted mismo localmente. Una buena manera de hacer esto es usar git log
o quizás más visualmente con herramientas como gitk
(quizás gitk --all
para ver todas las ramas y etiquetas). Si puede detectar los hash de confirmación que se usaron en ese momento, puede etiquetarlos usando git tag <hash>
y luego verificarlos en nuevas copias de trabajo (por ejemplo git checkout -b new_branch_name tag_name
o directamente con el hash en lugar del nombre de la etiqueta).
Puedes resolverlo así:
git reset --hard sha
dónde sha
por ejemplo:85a108ec5d8443626c690a84bc7901195d19c446
Puede obtener el sha deseado con el comando:
git log
uploadpack.allowReachableSHA1InWant
Desde Git 2.5.0, esta variable de configuración se puede habilitar en el servidor, aquí la solicitud de función de GitHub y el compromiso de GitHub habilitan esta función .
Bitbucket Server lo habilitó desde la versión 5.5+ .
Uso:
# Make remote with 4 commits, and local with just one.
mkdir server
cd server
git init
touch 1
git add 1
git commit -m 1
git clone ./ ../local
for i in {2..4}; do
touch "$i"
git add "$i"
git commit -m "$i"
done
# Before last commit.
SHA3="$(git log --format='%H' --skip=1 -n1)"
# Last commit.
SHA4="$(git log --format='%H' -n1)"
# Failing control without feature.
cd ../local
# Does not give an error, but does not fetch either.
git fetch origin "$SHA3"
# Error.
git checkout "$SHA3"
# Enable the feature.
cd ../server
git config uploadpack.allowReachableSHA1InWant true
# Now it works.
cd ../local
git fetch origin "$SHA3"
git checkout "$SHA3"
# Error.
git checkout "$SHA4"
El árbol fuente que necesita todavía está disponible en el repositorio de git, sin embargo, necesitará el SHA1 del commit que le interesa. Supongo que puede obtener el SHA1 del clon actual que tiene.
Si puede obtener ese SHA1, puede crear una rama / restablecer allí para tener el repositorio idéntico.
Comandos según la respuesta de Rui
Probablemente git reset
resuelva tu problema.
git reset --hard -#commit hash-