git checkout borra files

Soy nuevo en git y quería probar la function de twig. Estoy trabajando con un repository local. El problema es que si creo una nueva twig y luego vuelvo a la twig principal, algunos files se pierden.

Esto es lo que hago:

Tengo dos directorys:

$ ls g_LT LT 

y un file de código fuente lt_mp2.F en el directory LT:

 $ ls LT/ | grep lt_mp2.F lt_mp2.F 

El otro directory contiene un enlace simbólico relativo a este file:

 $ ls -l g_LT/ | grep lt_mp2.F lt_mp2.F -> ../LT/lt_mp2.F 

Ambos files se pierden si creo una nueva twig y luego vuelvo a la twig principal. Por lo tanto, déjame mostrar esto:

Antes de crear la nueva twig, compruebe que no hay nada que confirmar:

 $ git status HEAD detached from 2617e8a nothing to commit, working directory clean here 

También verifiquemos que estamos en la twig principal y que el último compromiso es del 13 de octubre de 2016

 $ git branch -a * (detached from 2617e8a) master $ git log commit 3484261bdd585671bf7c74568542a62610c2deaf Author: [...] Date: Thu Oct 13 09:25:06 2016 +0200 [...] 

Ahora creo una nueva twig:

 $ git checkout -b testbranch Switched to a new branch 'testbranch' 

Los files fuente todavía están allí:

 $ ls LT/ | grep lt_mp2.F lt_mp2.F $ ls -l g_LT/ | grep lt_mp2.F lt_mp2.F -> ../LT/lt_mp2.F 

Ahora vuelvo a la twig principal:

 $ git checkout master Switched to branch 'master' 

Pero ahora los files fuente se han ido:

 $ ls LT/ | grep lt_mp2.F (no output) $ ls -l g_LT/ | grep lt_mp2.F (no output) 

Además, el último compromiso es repentinamente desde diciembre de 2015 en lugar de 13 de octubre de 2016:

 $ git log commit 634741172ed34cd687fd91f14da45004b3328f8b Author: [...] Date: Tue Dec 1 18:54:57 2015 +0100 [...] 

¿Qué está pasando aquí y por qué estoy perdiendo mis files de origen?

Usted no está (perdiendo ningún file, ni ningún commit).

Esta parte de su reclamo inicial es incorrecta:

También verifiquemos que estamos en la twig principal [recorte]

 $ git branch -a * (detached from 2617e8a) master 

Esto muestra que no está en el master sucursal al comienzo. En cambio, tienes una "CABEZA separada". El git checkout de git checkout explícito más reciente de un ID de hash sin formatting, o su equivalente, como un nombre de label o un nombre de twig de seguimiento remoto, confirma 2617e8a . Su salida de git log muestra que la confirmación actual es probablemente 1 3484261bdd585671bf7c74568542a62610c2deaf , y la frase "separado de" sugiere que probablemente haya cometido esto usted mismo (Git usa "desconectado en" cuando no ha movido HEAD, y "separado de" cuando tener).

El command git log pnetworkingeterminada para mostrar commits a partir de su commit actual ( HEAD ) 2 y trabajando hacia atrás. Esto es cierto ya sea que HEAD esté "separado" o no. (Un HEAD no separado es un HEAD que hace reference al nombre de una twig, como master . Ejecutar git checkout branchname le da un HEAD no separado, es decir, HEAD ahora apunta a branchname , de modo que los commits se encuentran usando la twig indicada . )

Si desea ver más u otras confirmaciones, puede indicarle a git log que inicie en otro lugar. Donde sea que le digas que comience, funciona hacia atrás desde allí.

Por lo tanto, esto solo significa que el master , el nombre de la sucursal, señala un compromiso desde el año 2015. Una vez que HEAD apunta a master , el git log (sin arguments adicionales) comienza con su confirmación más reciente y funciona hacia atrás desde allí.

Es de suponer que si el master está así de desactualizado, todo el trabajo real ha estado ocurriendo en alguna otra twig (s).

Los files desaparecen cuando pasas de 3484261... a 6347411... (esta es probablemente la confirmación identificada por el master ) porque están en la confirmación anterior y no están en la última. Entonces, Git los elimina del índice y del tree de trabajo cuando se cambian los commits. Volver al 3484261... ( 3484261... por ID, o por el nuevo nombre que le diste) los regresará al índice y al tree de trabajo.


1 git log clasifica su salida por date, de forma pnetworkingeterminada, mostrando primero las confirmaciones con dates posteriores. Este código cambió un poco en algún punto que perdí, porque solía ser posible "dater" una confirmación en 2038 o algo así, de modo que siempre se mostraba en la parte superior de la salida de git log de git log , si se mostraba en absoluto. Esto dejó de funcionar cuando lo probé recientemente.

2 Consulte la nota al pie de página 1 y observe que puede cambiar el order de sorting y / o restringirlo, por ejemplo, con --topo-order . Agregar sets de --topo-order . Por lo general, las dates de los commits están más o less en línea con su topología de gráfico, de modo que estos indicadores no hacen grandes cambios en el order de sorting.