git perdió mi historial de edición sin fusión y conflicto

Tengo un compromiso en Wed Aug 27 19:43:46 2014 +0800,

commit bbdbbb7214de8611a787c92daf93dbc2719600d0 Author: malloc (malloc@slowcast.com) Date: Wed Aug 27 19:51:17 2014 +0800 commit a5f8bcbf7fdfa995325a338a02ad8eef611ac9f8 Author: malloc (malloc@slowcast.com) Date: Wed Aug 27 19:43:46 2014 +0800 

la edición de la confirmación muestra que se han modificado 3 files.

 git d --name-only a5f8bcb^..a5f8bcb res/layout/layout_login.xml base/BaseAct.java ui/login/Login.java (END) 

entonces otras personas cometen sus modificaciones.

 commit 833dee16869ceb834cb1b8d8ac38bf3d0f147e66 Author: simon (simon@slowcast.com) Date: Wed Aug 27 20:13:42 2014 +0800 commit b391737ac94d5d779c1cb00b05a7c3bccee98915 Author: muham (muham@slowcast.com) Date: Wed Aug 27 20:00:35 2014 +0800 

en la versión b391737, Login.java es la nueva versión, pero en la versión 833dee1 el contenido de Login.java es una versión anterior. (y también otros files han sido modificados)

compruebe el commit 833dee1, solo se compromete un file

 git d --name-only 833dee1^..833dee1 res/values/strings.xml (END) 

y luego revisa el logging de Login.java

 git log ui/login/Login.java commit c5a5ae9a48c2f1d44b6cd3654c20834ed49b3991 Author: simon (simon@slowcast.com) Date: Thu Aug 21 15:54:39 2014 +0800 commit 7e65405d19a946349ee4ac07176a37098f52867b Author: shubin (nick@slowcast.com) Date: Fri Aug 15 15:22:01 2014 +0800 

el último compromiso es el Jue 21 de agosto 15:54:39 ​​2014 +0800, no hay ningún logging de mi edición.

¿Cómo pudo pasar esto? El commit 833dee1 no tenía el file que edité y el historial de Login.java también perdió mi edición.
¿Hay alguna order de que pueda encontrar toda la historia de Login.java?

editar

=========================================
usamos solo un maestro de sucursal, y el logging no es solo local, git clone from remote obtiene el mismo historial de logging. Agregue algo de salida:

 $ git log --oneline --graph --color=auto --decorate --all ui/login/Login.java 
  • b77af0c (CABEZA, origen / maestro, origen / CABEZA, maestro) recuperar inicio de session
  • 9f88669 corrección temporal
  • c5a5ae9 agrega algún comentario
  • 7e65405 config edit … …

c5a5ae9 es el 21 de agosto 15:54:39 ​​2014, hace muchos días, 9f88669 y b77af0c se confirma después de que encontremos el problema, git pierde el logging en a5f8bcb.

 git log --oneline --graph --color=auto --decorate 833dee16...bbdbbb72 
  • 833dee1 cambio var
  • bbdbbb7 modifica el estilo de avatar pnetworkingeterminado
  • Estilo de la página de inicio de session a5f8bcb
  • 8b4aff8 agrega una string
  • ab1e53c agrega una cadena
  • 9ab6bea edit estilo de página de usuario rec

Incluso con la edición es difícil estar seguro, pero creo que hay suficiente información aquí para adivinar lo que sucedió, en este punto: usted hizo la confirmación (en el master ya que esa es su única twig), pero luego la arrojó de la twig, probablemente ejecutando git reset --hard (casi con certeza alguna variante de git reset ).

De hecho, al less dos confirmaciones no están en su sucursal: muestra:

 bbdbbb7214de8611a787c92daf93dbc2719600d0 a5f8bcbf7fdfa995325a338a02ad8eef611ac9f8 

en la parte superior, pero tu salida principal de git log no muestra ninguno. De hecho, 833dee1... también falta en esa salida, como es b391737...

Lo bueno de git es que los commits están de hecho todavía en tu repository. Gracias a los reflogs, los commits permanecen por lo less durante 30 días por defecto. Todo lo que necesitas hacer es resucitar o copyrlos.

Si quieres resucitar esa confirmación (y cualquier confirmación previa que también hayas descartado mediante la git reset ), asigna un nombre a la confirmación de la mayoría de las sugerencias (twig o label, ya sea una). Asumiendo que bbdbbb7... es lo más bbdbbb7... y quieres crear una twig para él:

 git branch somework bbdbbb7 # you can use the full 40-char SHA1 # or an abbreviation, either does thes # same job here 

hará el truco; ahora git log --graph --decorate --oneline --all debe mostrar ambos commits, bajo el nuevo nombre de somework . (Si bbdbbb7... no es la confirmación más importante, y a5f8bcb... es que puede apuntar a la nueva twig. Mire a través de los reflogs, git reflog o git log -g , para encontrar cualquier commit "perdido" que quiero traer de vuelta.)

Si simplemente desea copyr alguna confirmación previa, puede usar git cherry-pick para hacer eso. Esto intentará repetir los mismos cambios en la confirmación nombrada, pero aplicándolos a su tree de trabajo actual y luego haciendo una nueva confirmación del resultado (y también copyndo el post de confirmación original para esta nueva confirmación).

Es un poco difícil saber qué está pasando solo con la información provista.

Ha enumerado algunas confirmaciones, pero no ha hecho nada para mostrar en qué twigs están o cuál es el historial de fusión. Es muy posible que las confirmaciones que parece haber perdido se encuentren en una twig diferente a la que está mirando actualmente.

Otra posibilidad es que te engañe el hecho de que las confirmaciones más recientes pueden tener marcas de time que son más antiguas que las que te faltan. Es posible volver a establecer las asignaciones, aplicar las confirmaciones más antiguas sobre las más nuevas, de modo que cuando miras el historial, ves primero las más antiguas.

Otra posibilidad es que haya descartado sus compromisos de alguna manera, dejándolos separados en su repository local sin haberlos empujado y fusionado con la otra historia. Esto podría suceder si alguna vez has hecho un git reset a la twig ascendente.

Aquí es cómo puedes descubrir lo que está pasando. Una de las mejores maneras de hacerlo es visualizar la historia. Puede hacerlo con una herramienta gráfica como gitk si lo tiene instalado, o simplemente use git log --graph para hacerlo en el terminal si no lo está.

Intenta ejecutar los siguientes commands para ver qué está pasando. Si no está seguro de cómo interpretar el resultado, edite su pregunta para includela y puedo seguir explicando. El primero debe mostrar todo el historial de ese único file, en todas las twigs, local y remota. El segundo debe mostrar el historial que se incluye en uno de esos commits, pero no el otro.

 $ git log --oneline --graph --color=auto --decorate --all ui/login/Login.java $ git log --oneline --graph --color=auto --decorate 833dee16...bbdbbb72 

También puede ver un historial de lo que ha hecho en su repository. Simplemente escriba git reflog ; que le mostrará el historial de las versiones particulares que ha revisado; por lo que podrá ver si hubo un momento en que le quitaron la confirmación de su compromiso faltante, y luego cambió a otro compromiso que no lo incluyó.