Cómo recuperar files de una carpeta de trabajo git corrupta

Tuve el desafortunado incidente de get un BSOD mientras cambiaba mi twig de Git que no había enviado a mi repository remoto. Después de que la computadora se reinició y se volvió a conectar, descubrí que mi espacio de trabajo está dañado. Aquí están los síntomas:

  • El nombre de la twig es "(…)"
  • el directory .git existe con los files y directorys estándar (hooks, info, logs, objects, refs)
  • todo el command git que hice excepto clone e init resultó en "fatal: no es un repository git (ni ninguno de los directorys padre): .git"
  • "$ git init" no arrojó ningún error, pero no solucionó el problema
  • "$ git fsck –full" resultó en "fatal: no en un repository de git (ni en ninguno de los directorys principales): .git"
  • Solo algunos de los directorys en el espacio de trabajo muestran icons de TortoiseGit que indican que no hay cambios, otros no tienen los icons, todos los files no tienen los icons

¿Puede alguien ayudarme a poner el espacio de trabajo nuevamente en funcionamiento o recuperar algunos de los files en la twig o alijo?

Con la ayuda de mi antiguo colega, descubrí cómo recuperarme de esto. Probablemente quiera hacer esto como último recurso porque probablemente perderá algo de información y es posible que esto no funcione debido a la corrupción.

Pongamos que el espacio de trabajo corrupto es "corruptoWorkspace" y el espacio de trabajo a arreglar es "fixWorkspace". El primer paso que debe hacer es crear un nuevo espacio de trabajo para realizar su recuperación y copyr el object y refs:

  1. $ mkdir fixWorkspace
  2. $ cd fixWorkspace
  3. $ git init
  4. $ cp ../corruptWorkspace/.git/objects .git -r -a
  5. $ cp ../corruptWorkspace/.git/refs .git -r -a

Desde aquí puede recuperar una bifurcación / confirmación.

  1. Encuentre la twig que desea recuperar encontrándola en .git \ refs \ heads o en el file .git \ logs \ HEAD
  2. Abra en un editor de text y encontrará el último commit SHA para esa twig en el file de bifurcación o la segunda columna SHA de su último logging para la bifurcación en el file HEAD

Este command debe ser legible y mostrar los últimos cambios de compromiso

  1. $ git show [commit SHA]

Después de confirmar que la twig se ve bien, intente verificarlo

  1. $ git checkout [nombre de la sucursal]

Entonces puedes restablecer la twig

  1. $ git reset –hard

En este punto, tiene la última versión comprometida de su sucursal. El siguiente paso es recuperar el file oculto.

  1. Busque el alijo que desea recuperar encontrándolo en .git \ refs \ stash o en el file .git \ logs \ stash
  2. Abre en un editor de text y encontrarás el último commit SHA para ese alijo en el file oculto o la segunda columna SHA de tu último logging oculto para la twig en el file oculto

Enumere los files que están en el escondite para que los recupere, desde aquí puede get la location y el file guardados que se utilizarán para restaurar el file

  1. $ git show –name-only [stash SHA]

Recuperar los files escondidos

  1. $ git show [stash SHA]: [ruta completa del file]> [ruta completa del file]

Después de haber hecho el command anterior para todos sus files escondidos, ha terminado de get su sucursal y su file escondido. si el file de configuration no está dañado, es posible que incluso pueda copyr la definición de "origen" e insert sus cambios.

Buena suerte

Estoy teniendo el mismo problema con uno de mis repositorys locales esta mañana. Nunca he visto esto en todos los años que he estado usando Git. He estado usando este repository en particular durante 4 meses, pero ahora me dice que no es un repository git cuando todos los directorys y files (incluido .git) están allí. He tenido algunos problemas con mi máquina (Windows 7) apagándose por la noche sin motivo aparente que podría haber causado cierta corrupción, ya que tiendo a dejar Intellij abierto todo el time. Mi versión de git es 1.9.4. Intenté con "git init" para reiniciar el repository local, pero no ayudó. Actualicé Git a la versión 1.9.5, sin ayuda. El repository local todavía tiene mi configuration local (git config –local -l). Afortunadamente, me comprometo y empujo mis twigs a menudo para que la recuperación sea tan fácil como volver a clonar, pero aún me deja arañando. Cambié el nombre de mi repository local existente a otra cosa, luego volví a clonar el repository remoto y todo está bien ahora con el nuevo clon (el anterior aún está muerto).