2011-08-05 13 views
8

Trabajo en una compañía pequeña y nuestro repositorio de Git está un poco desordenado. Acabo de hacer un git pull y mis cambios realizados hoy se han ido!Git está perdiendo historial/contenido en archivos individuales

Cuando trabajo en la cabeza en la rama principal, git log muestra mi última confirmación b94940c63ef965ce45b0d64ccfba4359134d2552 en su historia.

Ahora, si hago git log filename para el archivo problemático que perdió mis cambios, esa confirmación no se muestra (solo muestra una confirmación anterior).

Realización git log --follow filename, mis cometer b94940c63ef965ce45b0d64ccfba4359134d2552 se muestra como más reciente.

y por supuesto si lo hago:

git checkout b94940c63ef965ce45b0d64ccfba4359134d2552 
git log filename 

continuación, el commit se muestra y mis cambios están en el archivo!

En otras palabras, el compromiso que hice se muestra en el historial de la sucursal (bloqueando una fusión de sucursal), pero los archivos modificados individuales no tienen esa confirmación en su historial. (a menos que yo explícitamente compruebe ese compromiso).

Preguntas:

  1. ¿Cómo diablos sucedió esto?

  2. ¿Cómo puedo solucionarlo? (Tenemos problemas con varios archivos en nuestro repositorio)

Respuesta

0

En primer lugar, usted debe obtener un control sobre lo que los comandos de Git hacen y qué datos se almacenan en el repositorio.

  • Obtener una herramienta de visualización de la historia como Giggle o gitk para ver su historia y se comprometen a ver lo que cometen se basa en lo que se comprometan.

  • git pull hace dos cosas: Recupera las nuevas confirmaciones del repositorio remoto, y se une la cabeza del repositorio remoto con su actual jefe (en su rama actual).

En vista de eso, es posible que desee tener más cuidado en el futuro. En lugar de usar git pull, puede hacer git fetch y fusionar manualmente lo que necesita fusionarse. De esta forma, usted tiene control sobre las ediciones que está realizando.

En cuanto a su situación actual, no creo que Git esté perdiendo datos. Dijiste que tu archivo aún está en el historial. Por lo tanto, ahora es probable que deba realizar algunos reinicios creativos (volviendo a las versiones anteriores) o parches (posiblemente de forma manual) para que los archivos de su proyecto lleguen al estado que desea que sean.

+0

Gracias por el consejo en Risita y gitk. Son útiles, pero solo me dicen lo mismo que muestra la consola; la sucursal tiene un historial correcto: el archivo no. De alguna manera, los archivos están en las versiones incorrectas. Afortunadamente, no hay pérdida de datos, por lo que puedo hacer los reinicios. Pero me preocupa que algo más esté sucediendo (y las cosas volverán a romperse muy pronto), y es por eso que quiero saber cómo llegaron las cosas de esta manera. – UsAaR33

1

Esto debería ser solo un comentario, pero sería difícil de leer.Después de la salida principal:

git checkout master 

¿cuál es la salida del

git status 

y

git whatchanged -m -p <path> 

y

git log --graph --oneline b94940c63ef965ce45b0d64ccfba4359134d2552..master 

?

+0

Nota para futuros comentaristas: whatchanged obtiene diff de git log --sigue – UsAaR33

4

Alright ha resuelto el problema. Cuando un compañero de trabajo se detuvo, tuvo algunos conflictos. En lugar de resolver, reinició todos los archivos por etapas. Esto fue similar a hacer un git checkout old_version en archivos antiguos individuales. Así que HEAD en el maestro terminó refiriéndose a algunos archivos que tenían old_version.

Ahora estoy restaurando manualmente lo que él apagó.

Moraleja de la historia: la modificación de las operaciones de git (verificación, reinicio, etc.) en archivos individuales es bastante peligrosa.

+6

Eso no es realmente la moraleja. La moraleja es: "aprende a resolver conflictos de fusión". Se aplica a cualquier VCS, y parece ser la habilidad menos practicada entre los desarrolladores en función de la cantidad de problemas que la rodean. –

+1

No podría estar más de acuerdo, @Ryan, y el problema a menudo es prolongado por personas que "restauran manualmente lo que él apagó" en lugar de revertir el cambio y hacerlo fusionar correctamente. –

0

En realidad se puede utilizar este script bash en la carpeta que desea ver qué archivos que podrían haber perdido sus compromete:

#!/bin/zsh 
 
for f in $(find . -name '*.php') 
 
do 
 
\t follow=$(git log --oneline -1 --pretty=format:"%h" -- $f) 
 
\t log=$(git log --follow --oneline -1 --pretty=format:"%h" -- $f) 
 
\t 
 
\t if [ $log != $follow ]; then 
 
    \t \t echo "follow $follow , log $log => $f" 
 
    \t fi 
 

 
done

Cuestiones relacionadas