¿Por qué usar `git commit` cuando está separado?

Question

Usando git log Encontré una versión anterior de mi proyecto con la que quería meterme. Hice git checkout version52 haciendo que el proyecto estuviera en un estado 'separado', realicé algunos cambios, luego hice git commit en él. No me di cuenta de que esto se cometería en un estado separado.

Después de esto volví a mi maestro con git checkout master pero cuando lo hago git log mis cambios ya no aparecen. Ahora me doy cuenta de que los cambios están trabados en mi version52.

Puedo obtener estos cambios aplicados con bastante facilidad con git merge version52 pero me preguntaba, ¿cuál es el punto de poder comprometer en estados separados en git? Como novato, esto me confundió por un tiempo y no entiendo por qué está permitido, o cuándo usar esa característica.

EDITAR: Disculpa, escribí "desconectado" anteriormente pero quise decir "desconectado". En git esto sucede cuando decides ver una versión previamente registrada de tu proyecto.

Answer 1

Para el futuro, debe haber creado una rama de trabajar fuera de

git branch branchName version52 
git checkout branchName 

o

git checkout -b brannchName version52 

Editado después comentario

El modelo de objetos git, que he escrito aproximadamente here, simplemente rastrea un árbol de objetos. Una rama es un puntero a una confirmación. Aunque los dos están relacionados, no es necesario que tenga una rama apuntando a la punta de una línea de confirmaciones.

Cuando crea una confirmación, todavía está creando un árbol de objetos que existirá en el repositorio hasta que envejezca y ejecute git-gc para limpiar estas confirmaciones huérfanas. Creo que lo que te preocupa es que no hay un requisito obligatorio para los commits en una sucursal. Esto crea flexibilidad en la herramienta que a veces atrapa a los usuarios, pero git es una herramienta avanzada.

En su caso usted hizo una confirmación y luego volvió a su rama principal y pensó que había perdido sus confirmaciones, pero si hubiera mirado la salida de git reflog, vería el sha de la confirmación que creó aunque no estaba en una rama. Podría haber creado una rama aquí por git branch branchName <sha of commit>. O podría haber fusionado o vuelto a establecer estas confirmaciones con/en otra sucursal sin seguir los pasos adicionales de crear y eliminar una sucursal solo para esto. Bueno, esto es solo un par de pasos extra, con solo unas pocas teclas; pero es útil en algunos casos.

Lo que ocurre es que una rama es solo una abreviatura de un árbol de confirmaciones, del mismo modo que una etiqueta es una abreviatura de una confirmación en particular. Excepto que cuando realiza commits en una bifurcación, el puntero de bifurcación se mueve junto con la última confirmación.

siempre existe el puntero head que apunta a la última de comprometerse, que ha realizado el pedido, por lo que son en realidad nunca 'desconectados'

Answer 2

Parece un poco confundido sobre el control de versiones: realiza una confirmación cada vez que realiza un cambio que funciona y pasa las pruebas. Normalmente me comprometo una vez cada hora más o menos, me da un estado conocido al que puedo volver y me da algo contra lo que puedo diferir. Si estás "conectado" o no, no está aquí ni allá.

Answer 3

Compromiso para una cabeza separada por sí es bastante inútil, pero también es utilizado durante el rebase interactivo, que le permite reescribir el historial de un árbol, si marca un compromiso para editarlo.

Después de que git llegue a tal confirmación mientras se rebase, detiene el proceso y puede cambiar esta confirmación con git commit --amend o incluso insertar nuevas confirmaciones como lo hace normalmente. Lo que es más importante, dichos commits no pertenecen a ninguna rama, como se ve claramente en git status, por lo que te comprometes con una cabeza separada.

Muchos usuarios de Git, incluyéndome a mí, piensan que el rebasado interactivo es una de las funciones de git más útiles y que no funcionaría si no fuera posible comprometerse con un HEAD separado.