Directorio de artículos
prefacio
Este artículo seguirá al artículo anterior " [Git] Explicación detallada del comando git reset (1) ", continúa combinando ejemplos específicos y comandos subyacentes de Git, y explica el uso básico de git reset en detalle a través de gráficos y texto.
git reset commit – archivo
git reset [<commit>] [--] <file>
Este comando restaurará el archivo especificado por <file> en el área de almacenamiento temporal al estado del objeto de confirmación especificado por <commit>. hay que tener en cuenta es:
- Si no se especifica <commit>, por defecto es el objeto de confirmación apuntado por HEAD.
- Solo los archivos especificados por <file> en el área de almacenamiento temporal se verán afectados (git reset [–soft | --mixed [-N] | --hard ] [<commit>] afectará a todos los archivos en el área de almacenamiento temporal) .
- Los modos suave y duro no se pueden configurar, de lo contrario, se informará un error.
- No cambiará la orientación de HEAD (git reset [–soft | --mixed [-N] | --hard ] [<commit>] cambiará la orientación de HEAD).
Probemos este comando a mano.
Creamos un archivo newfile.txtx bajo el directorio de trabajo (es decir, el directorio learngit), el contenido es:
This is a new file.
Y modificamos el contenido del archivo readme.txt en el directorio de trabajo a:
Git is a distributed version control system.
Git is a free software.
Git has a mutable index called stage.
Agregaremos el archivo readme.txt modificado y el archivo newfile.txtx recién creado al área de almacenamiento temporal y los enviaremos juntos al almacén:
El historial de compromisos es el siguiente:
Primero usemos el comando git cat-file para ver el objeto de envío d4ac459791ee1411bf771cc312092c89de13a1d0 al que apunta el HEAD actual:
Como se puede ver en la figura anterior, el objeto de confirmación d4ac459791ee1411bf771cc312092c89de13a1d0 apunta a un objeto de árbol f90c81e6736a257d5aad417426cff9c01d135919. Además, el objeto de envío principal del objeto de envío d4ac459791ee1411bf771cc312092c89de13a1d0, es decir, el objeto de envío del último envío es 7b674f020f76a168dbe4bbdec11b1fd137d0b291.
Continuamos usando el comando git cat-file para ver el objeto de árbol f90c81e6736a257d5aad417426cff9c01d135919:
Como puede verse en la figura anterior, el objeto de árbol f90c81e6736a257d5aad417426cff9c01d135919 apunta al objeto de datos 67668a2400494229c8f9dd64ec07ee302378a4cb y el objeto de datos 85c4f2db496bd7c17f5582756c304758c304758c354758c.
El objeto de datos 67668a2400494229c8f9dd64ec07ee302378a4cb y el objeto de datos 85c4f2db496bd7c17f558258f354744c3075c6a9 corresponden al contenido de los archivos newfile.txt y readme.txt que enviamos la última vez:
Usemos el comando git ls-files para ver el estado del área de almacenamiento temporal actual:
Como se puede ver en la figura anterior, el objeto de datos actualmente almacenado o señalado por el área de almacenamiento temporal es consistente con HEAD.
Supongamos que ahora queremos restaurar el área de preparación al estado de nuestra segunda confirmación:
Eche un vistazo al historial de confirmación:
Como se puede ver en la figura anterior, HEAD apunta al objeto de confirmación 68b21576f6d85e1a9eb8121e92a31fd87cdafa65 de la segunda confirmación.
Comprobemos de nuevo el estado del área de ensayo:
Como se puede ver en la figura anterior, el área de almacenamiento temporal ha vuelto al estado en que la enviamos por segunda vez.
Esto es lo mismo que demostramos en [Git] Explicación detallada del comando git reset (1) .
Antes de continuar, restablezcamos el repositorio al estado de nuestro último compromiso:
Supongamos que ahora queremos restaurar el archivo readme.txt en el área de almacenamiento temporal al estado de nuestro segundo envío, aún podemos usar el comando git reset para especificar el objeto de envío y el nombre del archivo, de la siguiente manera:
Eche un vistazo al historial de confirmación:
Como se puede ver en la figura anterior, ¡el objeto de confirmación señalado por HEAD no ha cambiado!
Comprobemos de nuevo el estado del área de ensayo:
Como se puede ver en la figura anterior, el archivo newfile.txt en el área de almacenamiento temporal es consistente con el archivo newfile.txt en el área de almacenamiento temporal en el momento del último envío, pero el archivo readme.txt en el almacenamiento temporal el área ha vuelto al almacenamiento temporal en el segundo envío La versión del archivo newfile.txt de la zona.
Abra el archivo readme.txtx en el directorio de trabajo, el contenido sigue siendo el siguiente:
Git is a distributed version control system.
Git is a free software.
Git has a mutable index called stage.
De los intentos anteriores, podemos concluir que git reset [<commit>] [–] <file> restaurará el archivo especificado por <file> en el área de almacenamiento temporal al estado del objeto de envío especificado por <commit>, mientras que No afectará a otros archivos en el área de almacenamiento temporal, ni cambiará el apuntamiento de HEAD.
¿Qué pasa si queremos restaurar un archivo en el directorio de trabajo? Supongamos que ahora queremos restaurar el archivo readme.txt en el directorio de trabajo al estado de nuestro segundo envío:
¡El resultado estuvo mal!
Probemos de nuevo con --soft:
¡Se informó el mismo error!
Resumir
git reset [<confirmar>] [–] <archivo>：
- Si no se especifica <commit>, por defecto es el objeto de confirmación apuntado por HEAD.
- Solo los archivos especificados por <file> en el área de almacenamiento temporal se verán afectados (git reset [–soft | --mixed [-N] | --hard ] [<commit>] afectará a todos los archivos en el área de almacenamiento temporal) .
- Los modos suave y duro no se pueden configurar, de lo contrario, se informará un error.
- No cambiará la orientación de HEAD (git reset [–soft | --mixed [-N] | --hard ] [<commit>] cambiará la orientación de HEAD).