Reattach Head en Git
Un repositorio de Git se puede definir como un grupo de objetos y referencias. Las ramas son los objetos que utilizamos para presentar nuestro trabajo. Git también se ocupa de las etiquetas que hacen referencia a los commits en la rama en particular.
Un commit
es probablemente el estado del código fuente utilizado en un determinado momento. Los Commits
consisten en padres e hijos, así como datos completos sobre quién creó el compromiso y cuándo se creó. Los Commits
se colocan en el repositorio como objetos en la rama.
La referencia HEAD
apunta a el último commit en la rama actual. El puntero HEAD
es una referencia a la rama actualmente desprotegida y apunta a la parte superior de una rama.
Sin embargo, puede retroceder en el tiempo sin visitar una rama. Puede usar el puntero HEAD
para obtener cualquier confirmación en una rama, y luego puede usar el índice para obtener fácilmente cualquier versión de un archivo.
Puede usar el puntero HEAD
y los punteros de índice para realizar el check-out
a un commit específica llamada estado disociado HEAD
en Git. Además, puede verificar un commit específica y crear una nueva rama basada en un commit específica en una rama.
No se convertirá en un problema si solo hacemos esto una vez cada luna azul. Sin embargo, si lo repetimos mucho, pronto empezaremos a preguntarnos cómo volver a esa rama en la que estábamos trabajando.
La solución es muy sencilla, ya que antes de desproteger una rama debemos utilizar el comando git checkout master
. Este comando nos devuelve a la rama en la que estábamos trabajando antes de realizar el commit, pero no afecta el commit que estábamos revisando.
Una solución limpia sería configurar un nuevo repositorio de Git dedicado a almacenar la serie de parches y ponerlo a disposición de otros para obtener la rama más reciente en cualquier momento.
Estas situaciones son lo suficientemente raras como para que el costo de usabilidad y rendimiento de implementar HEAD separados supere su beneficio, por lo que Git actualmente carece de esta función. Git puede modificar los commits. Sin embargo, es imposible modificar el último commit en un HEAD desconectado.
Git tiene una forma de eliminar commits de forma permanente creando una rama secreta, registrando los datos de commit en esa rama y luego eliminando el commit de HEAD
de forma permanente. Sin embargo, esta función solo está disponible mientras se desconecta una única confirmación de HEAD
. Si un commit tiene varios padres, es imposible eliminarla de esa rama.
Cabeza separada en Git
Sin embargo, cuando cambiamos a otra rama, la situación es diferente. Si tenemos nuestro directorio de trabajo desprotegido, se actualiza a HEAD
, y ya no podemos modificar los archivos en él, o podemos crear algunos cambios nuevos si no entran en conflicto con la rama a la que hemos cambiado.
En este caso, HEAD
se separa de la rama actual. Al mismo tiempo, podemos usar el comando git checkout
para cambiar de rama sin actualizar nuestro directorio de trabajo a HEAD
, por lo que HEAD
se puede separar al mismo tiempo que se adjunta.
Es bastante confuso, pero puede ser útil si queremos cambiar rápidamente entre ramas sin tocar el directorio de trabajo rápidamente o cambiar a una rama diferente y verificar un nuevo directorio de trabajo simultáneamente. Podemos usar git checkout -b <newbranchname> <commit>
para hacer esto.
Podemos actuar así; solo echa un vistazo a la rama que deseamos.
$ git checkout <branch>
Por ejemplo:
$ git checkout master
Si queremos mantener los cambios en los que estamos trabajando, debemos crear una nueva rama o guardar nuestros cambios en la rama. Cualquier checkout
de un commit reciente que no pueda ser el nombre de una de nuestras ramas nos dará un HEAD separado.
Cuando se separa HEAD
, los commits parecen normales, excepto que no se actualiza ninguna rama con nombre. Es como una rama desconocida. Por ejemplo, podemos decir, si verificamos una rama remota antes de rastrearla primero; eventualmente, terminaremos con un HEAD
desprendido.
Abdul is a software engineer with an architect background and a passion for full-stack web development with eight years of professional experience in analysis, design, development, implementation, performance tuning, and implementation of business applications.
LinkedIn