Git: HEAD ha desaparecido, quiero fusionarlo en master

reflog vs GITK http://siteroller.net/archive/images/Forums/headless%20GIT.png

La image superior es la salida de: git reflog.
El background es lo que GITK en GIT GUI (msysgit) me muestra cuando veo todo el historial de sucursales.

Los últimos commits no aparecen en GIT GUI.

  • ¿Por qué no se muestran en GITK (al less como una twig o algo así)?
  • ¿Cómo los fusiono en el maestro?
  • Entiendo que esto sucedió cuando revisé la label 0.42. ¿Por qué no es lo mismo que maestro? (Había labeldo al maestro en su último estado)
  • Cuando hago clic en presionar, ¿por qué el repository remoto afirma estar actualizado … no debería intentar actualizar estos commits en cualquier twig en la que se encuentren?

La primera de las preguntas es importante. Me gustaría comenzar a entender qué está pensando GIT. Es más oracle que lógica en este punto.

Si hace una diferencia ver la historia anterior, el proyecto es un selector de color JS [bastante poderoso] que se puede ver aquí en su totalidad.

¿Por qué actualizar estos commits en cualquier twig en la que se encuentren?

Eso es todo: no estás en ninguna twig, pero actualmente trabajas en una cabeza separada :

a partir de la versión 1.5.0, el command anterior separa su HEAD de la twig actual y apunta directamente a la confirmación nombrada por la label.

Podrías verlo si haces un gitk --all

Una forma de solucionarlo (si has cometido todo)

 $ git log -1 # note the SHA-1 of latest commit $ git checkout master # reset your branch head to your previously detached commit $ git reset --hard <commit-id> 

Otra forma sería fusionar su trabajo en el HEAD maestro actual que se encuentra en la label:

  $ git checkout -m 0.42 

pero eso pierde la historia de tus commits hechos en un HEAD separado.


Entiendo que esto sucedió cuando revisé la label 0.42. ¿Por qué no es lo mismo que maestro? (Había labeldo al maestro en su último estado)

No, no es lo mismo que amo. Como señala Jefromi en los comentarios, la sucursal puede moverse (o ser renombrada, o eliminada, o …)
master estaba refiriendo a la misma confirmación que la label '0.42', pero ese no será siempre el caso.
Con la extracción de una label, no se puede sacar una twig, de ahí el estado 'HEAD separado'.


Nota: como se menciona en esta respuesta SO , la notación @{1} que ves es $(git symbolic-ref HEAD)@{1} , es decir, usa el reflog para la twig actual (aquí separada), no para el reflog HEAD.

En Git commits se forma un gráfico acíclico dirigido donde cada commit apunta a uno o más commits principales. Además de los objects de confirmación, también tiene objects ref (es decir, reference): twigs y tags. Señalan varias confirmaciones en el gráfico de confirmación. Tu problema es que no estabas en una twig cuando hiciste los commits y ninguna twig (o tag) los señala. En cualquier momento puedes usar commands

 git status 

y

 git branch 

para verificar si estás en una sucursal o no.

¿Por qué no se muestran en GITK (al less como una twig o algo así)?

Por lo que sé, Gitk busca los objects de compromiso a partir de los refs. Si no hay puntos de reference para sus confirmaciones (o el gráfico acíclico dirigido de las confirmaciones que los conducen) son efectivamente invisibles.

¿Cómo los fusiono en el maestro?

Afortunadamente, la function de reconfiguration realiza un seguimiento de las operaciones, como las transferencias y los compromisos (entre otras cosas). En su list de reflog, puede ver la input de su última confirmación:

1b8c11d HEAD @ {1} commit: abreviado function toRgb ()

Debería poder fusionar las confirmaciones en su twig principal utilizando la ID SHA1 que ve en el reflog:

 git checkout master git merge 1b8c11d 

Entiendo que esto sucedió cuando revisé la label 0.42. ¿Por qué no es lo mismo que maestro? (Había labeldo al maestro en su último estado)

La principal diferencia entre las twigs y las tags es que una label siempre apunta a la misma confirmación pero una twig se mueve hacia adelante. Por ejemplo, si está en la twig "master" y realiza una nueva confirmación, la twig "principal" avanza y comienza a señalar la nueva confirmación que acaba de crear. Cuando compras confirmaciones, tags o sucursales, Git toma tus commands de manera bastante literal y verifica exactamente lo que pediste.

Cuando hago clic en presionar, ¿por qué el repository remoto afirma estar actualizado … no debería intentar actualizar estos commits en cualquier twig en la que se encuentren?

Tus commits no están en ninguna twig. Primero debe fusionarlos en una bifurcación (por ejemplo, para masterizar) como se muestra arriba. Después de esto, el empuje debería funcionar normalmente.

La forma más fácil de resucitar tus commits es señalarles algún branch branch. Usted conoce los SHA, así que es fácil:

 git branch resurrected_junk 1b8c11d 

(esta es una lectura SHA de su captura de pantalla), también podría ser

 git branch resurrected_junk HEAD@1 

Esto apuntará una twig a la más reciente de las confirmaciones perdidas: las anteriores probablemente sean las de la más reciente, por lo que estarán en esta nueva twig; si no lo están (eso significa que hay dos "twigs sombreadas" de commits perdidos), debería revisar todos los commits y reiterar el procedimiento para los commits que faltan.

En tu caso, supongo que obtendrás un historial como este:

 Master --> Optimize toRGB --> ... ---> shortened toRGB = resurrected_junk 

A continuación, actualice su vista de gitk y se mostrarán las confirmaciones. (Estoy usando qgit, así que solo estoy adivinando)

Después de eso, deberías poder fusionar / pulsar / lo que quieras (como quieras).