Git: CABEZA ha desaparecido, que fusionar en maestro

Question

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

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

Los últimos compromete no se ven en GIT interfaz gráfica de usuario.

• ¿Por qué no se muestran en GITK (al menos como una rama o algo así)?
• ¿Cómo los fusiono en el maestro?
• Entiendo que esto sucedió cuando revisé la etiqueta 0.42. ¿Por qué no es lo mismo que maestro? (Había marcado el maestro en su último estado)
• Cuando hago clic empuje, ¿por qué el reclamo de recompra a distancia para estar al día .. ¿No debería tratar de actualizar estas confirmaciones en cualquier rama que se encuentran?

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

Si hace una diferencia para ver la historia anterior, el proyecto es un selector de color [bastante poderoso] JS que puede ser viewed here en su totalidad.

Answer 1

¿por qué actualizar estos commits en cualquier rama en la que se encuentren?

de eso se trata: no se encuentra en cualquiera de las ramas, pero actualmente trabajando en un detached head:

partir de la versión 1.5.0, el comando anterior se desprende que su HEAD de la rama actual y directamente puntos en la confirmación nombrada por la etiqueta.

Es posible que vea que si lo hace de una manera gitk --all

Uno de solucionarlo (si ha 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 la de combinar su trabajo en el maestro actual CABEZA, que pasa a estar en la etiqueta:

$ git checkout -m 0.42 

pero que pierde el historial de sus commits m Ade en un HEAD separado.

---

Deduzco esto sucedió cuando llegué etiqueta 0,42. ¿Por qué no es lo mismo que maestro? (He etiquetado al maestro en su último estado)

No, no es lo mismo que el maestro. Como Jefromi señala en los comentarios, la sucursal se puede mover (o se puede renombrar, o eliminar, o ...)
master se refería a la misma confirmación que la etiqueta '0,42', pero ese no será siempre el caso.
Con la extracción de una etiqueta, no se puede sacar una rama, de ahí el estado 'HEAD separado'.

---

Nota: como se menciona en this SO answer, la @{1} notación que se ve es $(git symbolic-ref HEAD)@{1}, es decir, que es utiliza para reflog rama actual (en este caso individual), no la cabeza reflog.

Answer 2

La manera más fácil de resucitar sus commits es apuntarles algún branch branch. Usted sabe que el SHA, así que es fácil:

git branch resurrected_junk 1b8c11d 

(esto es un SHA lee desde la captura de pantalla), podría ser también

git branch resurrected_junk HEAD@1 

Este apuntará una rama a la más reciente de sus confirmaciones perdidos - los anteriores son probablemente los padres de la más reciente, por lo que estarán en esta nueva rama; si no lo están (eso significa que hay dos "ramas sombreadas" de commits perdidos), debería revisar todos los commits y reiterar el procedimiento para los commits que faltan.

En su caso, supongo que obtendrá una historia como esta:

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

A continuación, actualizar la vista gitk y las confirmaciones debe aparecer. (Estoy usando qgit, así que estoy adivinando)

Después de eso, debería ser capaz de combinar/pulsar/lo que desee (como desee).

Answer 3

En Git commits se forma un gráfico acíclico dirigido donde cada commit apunta a una o más confirmaciones principales. Además de los objetos de confirmación, también tiene objetos ref (es decir, referencia): ramas y etiquetas. Señalan varias confirmaciones en el gráfico de confirmación. Tu problema es que no estabas en una rama cuando hiciste los commits y ninguna rama (o tag) los señala. En cualquier momento puede utilizar comandos

git status 

y

git branch 

para comprobar si se encuentra en una rama o no.

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

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

¿Cómo los fusiono en master?

Afortunadamente, la función de reajuste realiza un seguimiento de las operaciones, como las transferencias y los compromisos (entre otras cosas).En su reflog lista se puede ver la entrada de su última confirmación:

@ 1b8c11d CABEZA {1} cometer: la función acortado toRgb()

Usted debe ser capaz de fusionar los commits al maestro rama utilizando el ID de SHA1 que se ve en la reflog:

git checkout master 
git merge 1b8c11d 

deduzco esto sucedió cuando llegué etiqueta 0,42. ¿Por qué no es lo mismo que maestro? (He etiquetado al maestro en su último estado)

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

Cuando hago clic en presionar, ¿por qué el repositorio remoto afirma estar actualizado ... no debería intentar actualizar estas confirmaciones en la rama en la que se encuentran?

Sus compromisos no están en ninguna rama. Primero debe fusionarlos en una rama (por ejemplo, para dominar) como se muestra arriba. Después de esto, el empuje debería funcionar normalmente.