Directo eliminado después de restablecer git –hard @ {u}

Cloné un repository vacío de github (llamémoslo repoA) y agregamos un directory (resultados nombrados) en él localmente (así que repoA / results)

Luego hice un git add results para agregar el directory de resultados al repository. Luego git commit -m "add results directory" . Finalmente git push

Durante la inserción tuve un error debido a un file demasiado grande que olvidé eliminar:

 Total 5660 (delta 2779), reused 0 (delta 0) remote: Resolving deltas: 100% (2779/2779), done. remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com. remote: error: Trace: 7b1b7d4f8a8e398ef7184a6410f06c66 remote: error: See http://git.io/iEPt8g for more information. remote: error: File results/quality/R1.linker.fastq is 360.01 MB; this exceeds GitHub's file size limit of 100.00 MB To https://github.com/XXX/repoA.git ! [remote rejected] master -> master (pre-receive hook declined) error: impossible de pousser des références vers 'https://github.com/XXX/repoA.git' 

Así que eliminé en local el file grande. y luego git commit -m "delete big file" intenté git push nuevamente pero tuve el mismo error.

git reset y el git checkout sin impacto.

Luego, git reset --hard @{u}

 HEAD is now at 78022b7 Initial commit 

Pero ahora el directory / results desapareció de mi computadora y no está presionado en github … ¿Hay algo que hacer para reparar mi (estúpido) error? Estos resultados fueron callados valiosos para mí …

Muchas gracias

Editar

Como sugerí que lo hice, hice que git reset 2f6116c :

 Modifications non indexées après reset : D results/benchmarkBlast/benchmarkBlast.R D results/benchmarkBlast/benchmark_blast_bowtie_01092017.jpg D results/benchmarkBlast/benchmark_blast_bowtie_01092017.pdf D results/benchmarkBlast/bowtie2_10000000_1_LTR.txt D results/benchmarkBlast/results/BLV/blast_1000000_10_10_BLV.txt D results/benchmarkBlast/results/BLV/blast_1000000_10_1_BLV.txt D results/benchmarkBlast/results/BLV/blast_1000000_10_2_BLV.txt etc.. 

y todavía nada en mi directory? D figures / benchmarkBlast / results / BLV / blast_1000000_10_3_BLV.txt

Editar

Lo resolví haciendo:

 git reset -- results git checkout -- results 

TL; DR: crea un nuevo nombre de sucursal para recuperar sus confirmaciones existentes

Puedes hacer esto con la git branch .

Larga explicación

  1. "no entres en pánico" 🙂

  2. Date count de que lo que es un compromiso, en Git, es una instantánea permanente e inmutable de lo que tengas en lo que Git llama tu índice o área de ensayo o caching (tres palabras para la misma cosa).

Cada confirmación restring su compromiso anterior (o principal ). Hiciste dos commits (probablemente uno a través de GitHub durante la creación del repository, pero el efecto es el mismo). El primero no tiene padre, porque no puede: fue el primer compromiso. (A esto lo llamamos cometer una confirmación raíz ).

Luego hiciste una segunda confirmación, pero como esta confirmación tenía una confirmación previa, Git hizo que la segunda confirmación utilizara la primera confirmación como su padre. Si llamamos a la primera confirmación A -en lugar de su nombre real, alguna ID de hash incomprensible como 78022b7... -y llamamos a la segunda confirmación B (en lugar de 2f6116c... ), podemos dibujar la situación así:

 A <-B 

Commit B ( 2f6116c... ) permite a Git encontrar commit A ( 78... ) porque la ID de la tienda B Pero Git necesita alguna forma de encontrar a B primero, porque sus ID de hash no tienen relación con el order en que hiciste los commits. Aquí es donde entran los nombres de las twigs como master :

 A <-B <-- master 

Decimos que el master nombre señala cometer B , porque localiza la confirmación B para nosotros.

Lo que hace el git reset es complicado, pero comienza con el cambio de los nombres de las twigs

Inicialmente, tienes estos dos commits en tu repository, con el master apuntando a B , e intentas hacer git push y eso falla.

Luego ejecutó el git reset --hard @{u} . Esto hace tres cosas, pero primero nos preocupemos por lo primero: mueve el nombre de la twig .

Los compromisos son permanentes e inmutables. git reset no afecta las confirmaciones, porque no puede . Pero afecta el nombre, en este caso el master porque los nombres no son permanentes y son modificables.

La secuencia de confirmación A<-B permanece en su repository, pero vamos a dibujarlo un poco diferente para que podamos señalar master a A :

 A <-- master \ B [abandoned] 

Ahora bien, si somos Git y comenzamos por mirar master , encontramos el compromiso A y lo mostramos, y luego confirmamos que A es la confirmación raíz (no tiene padre), así que nos detenemos.

Commit B todavía está allí, sin nombre. Afortunadamente, el reflog (que ya has visto) guarda su ID de hash, que la guarda, mientras la input de reflog permanezca activa (al less 30 días por defecto).

Restablecer hace una, dos o tres cosas

Restring arriba que dije " git reset --hard @{u} hizo tres cosas. Mover el nombre de la twig fue solo uno de los tres.

Las otras dos cosas que git reset puede, y con --hard does, do son:

  • Vuelva a establecer el índice.

    El índice (que de nuevo también se denomina área de transición o caching) quizás se describa mejor como "lo que entrará en la siguiente confirmación que realice".

  • Vuelva a establecer el tree de trabajo .

    El tree de trabajo es en realidad la única obvia de estas cosas: es donde haces tu trabajo. En el tree de trabajo, sus files tienen su forma habitual y están disponibles para todos los progtwigs informáticos normales. Las cosas en el índice y las confirmaciones internas están en una forma especial solo de Git.

Puedes hacer que Git se detenga después de hacer solo una cosa: git reset --soft . Esto mueve un nombre de twig y no toca el índice y el tree de trabajo.

Puedes hacer que Git se detenga después de hacer dos cosas: git reset --mixed . Esto mueve un nombre de twig y restablece el índice.

O bien, puedes hacer que Git haga las tres cosas: git reset --hard . Esto mueve un nombre de twig, restablece el índice y restablece el tree de trabajo.

Lo que le gustaría tener es algo como esto:

 A <-- master \ B <-- recovery 

Esto le dará dos nombres de twig para los dos commits existentes.

Si actualmente tiene el master nombre apuntando a confirmar A , puede simplemente agregar un nuevo nombre de twig, recovery , apuntando al compromiso B :

 git branch recovery 2f6116c 

lo haré.

Si el master nombres apunta actualmente a cometer B , puede hacer otro git reset para que apunte a comprometer A nuevamente. Primero puede crear el nombre de recovery y no tiene que deletrear la ID de hash de B :

 git branch recovery git reset 78022b7 

Cada vez que ejecutas git reset esta manera, mueves el nombre de la bifurcación actual -la twig en la que el git status dice que estás conectado- a la confirmación dada. Si usa --mixed (el valor pnetworkingeterminado), también restablece el índice. Si usa --hard , también restablece el tree de trabajo. Pero cualquiera que sea el hash de confirmación que proporciones, mueves el nombre de la twig actual para apuntar a esa confirmación.

Los commits permanecen donde están, permanentes e invariables. Qué cambios son:

  • tus nombres de twig;
  • su índice / área de ensayo; y
  • tu tree de trabajo.

Todo lo que haya guardado con la git commit se almacena de forma permanente, sin interrupción, mientras haya un nombre de sucursal mediante el cual pueda encontrar la input de compromiso o de reajuste manteniendo viva una confirmación de otro modo abandonada. Solo después de aproximadamente un mes, cuando las inputs de los reflog comiencen a expirar, los commit abandonados realmente desaparecerán.

Restablecer en realidad puede hacer aún más cosas

Me tomó el time suficiente para responder a esto que se te ocurrió git reset -- results . Esto es otra cosa que puede hacer el git reset : "mueve" el nombre de la sucursal actual a donde está ahora, lo que no tiene ningún efecto, y luego restablece algunas inputs o inputs de índice específicas a lo que está en la nueva confirmación actual. Esto le permite ejecutar git checkout para extraer la input de índice en el tree de trabajo.

(También puede extraer directamente de una confirmación, que se copy primero en el índice y luego en el tree de trabajo. Es una buena idea tener en count que, en todo momento, Git está trabajando con tres copys de cada file: una en ¡el compromiso HEAD , uno en el índice y un tercero en el tree de trabajo!)

  • git reflog le dará las operaciones realizadas
  • A partir de allí, encuentre el hash de operación antes del restablecimiento completo
  • git reset <commithash>
  • Si el reset lo llevará de return cuando los files fueron eliminados (como parece en su caso) porque no apuntó al hash correcto de operación, es posible que deba realizar un git checkout -- . para restaurarlos