Introducción a Git

Tabla de contenidos

Prólogo
1. Configurando git
.... 1.1 Archivos de configuración
.... 1.2 Configuración predeterminada
.... 1.3 Alias
2. Los fundamentos de git
.... 2.1 Crear un repositorio
.... 2.2 Estado del archivo
.... 2.3 Trabajando con el índice
.... 2.4 Trabajando con commits
.... 2.5 Ver historial
.... 2.6 Trabajar con un repositorio remoto
3. Ramificación en git
.... 3.1 Operaciones básicas
.... 3.2 Fusionar ramas
.... 3.3 Rerere
4. Punteros en git
.... 4.1 Punteros móviles
5. Lectura recomendada

Prólogo

Git es el sistema de control de versiones distribuido más popular. [1] [2]

El objetivo principal de Git es guardar instantáneas de las condiciones de mejoramiento sucesivas de su proyecto (Pro git, 2019).

Este artículo es para aquellos que tienen al menos conocimientos básicos y habilidades para trabajar con git y que desean expandir su conocimiento.

Aquí solo se consideran los aspectos técnicos de git, para una inmersión más detallada en la filosofía de git y su implementación interna, le aconsejo que lea varios libros útiles (consulte Lectura recomendada ).

1. Configurando git

¡Antes de comenzar a trabajar con git, debe configurarlo usted mismo!

1.1 Archivos de configuración

• / etc / gitconfig: configuración general para todos los usuarios y repositorios
• ~ / .gitconfig o ~ / .config / git / config - Configuraciones específicas del usuario
• .git / config - Configuraciones para un repositorio específico

Hay un equipo especial

git config [<>] 

lo que le permitirá cambiar el comportamiento estándar de git, si es necesario, pero puede editar los archivos de configuración manualmente (creo que es más rápido).

Según el parámetro que pase al comando git config (--system, --global, --local), la configuración se escribirá en uno de estos archivos. ¡Cada uno de estos "niveles" (sistema, global, local) redefine los valores del nivel anterior!

Para ver en qué archivo qué configuraciones están instaladas, use git config --list --show-origin.

Ignorando archivos
En git, usted decide qué archivos se incluirán en cada confirmación, pero tal vez desee que ciertos archivos nunca estén en el índice y en la confirmación, y ni siquiera aparezcan en la lista sin seguimiento. Para hacer esto, puede crear un archivo especial (.gitignore) en su repositorio y escribir allí la plantilla de archivos ignorados. Si no desea crear dicho archivo en cada repositorio, puede definirlo globalmente usando core.excludesfile (consulte Configuración útil ). También puede descargar el archivo .gitignore terminado para el lenguaje de programación en el que está trabajando.
Para personalizar .gitignore, use expresiones regulares bash .

1.2 Configuraciones predeterminadas

Hay un montón de configuraciones git tanto para el servidor como para el cliente, aquí solo se considerarán las configuraciones básicas del cliente.

Uso

 git config name value 

donde nombre es el nombre del parámetro y valor es su valor para establecer la configuración.
Un ejemplo:

 git config --global core.editor nano 

instalará el editor predeterminado nano.

Puede ver el valor de un parámetro existente con git config --get [name] donde name es el parámetro cuyo valor desea obtener.

Configuraciones útiles:

• user.name: el nombre que se usará al crear la confirmación
• user.email: correo electrónico para usar al crear la confirmación
• core.excludesfile: un archivo cuya plantilla se utilizará para ignorar archivos específicos a nivel mundial
• core.editor: el editor predeterminado
• commit.template: el archivo cuyo contenido se utilizará para el mensaje de confirmación predeterminado (consulte Trabajar con confirmaciones ).
• help.autocorrect: cuando se establece en 1, git ejecutará comandos escritos incorrectamente.
• credential.helper [mode]: establece el modo de almacenamiento de credenciales. [caché]: las credenciales se guardan durante un cierto período, las contraseñas no se guardan (- timeout [segundos] el número de segundos después de los cuales se eliminan los datos, el valor predeterminado es 15 minutos). [almacenar]: las credenciales se almacenan por tiempo ilimitado en claro (- el archivo [archivo] indica la ruta para almacenar datos, por defecto ~ / .git-credentials).

1.3 Alias

Si no desea imprimir todos los comandos para Git en su totalidad, puede configurar fácilmente los alias. Para crear un alias use:

 git config alias.SHORT_NAME COMMAND 

donde SHORT_NAME es el nombre para abreviar, y COMANDO los comandos que se abreviarán. Un ejemplo:

 git config --global alias.last 'log -1 HEAD' 

después de ejecutar este comando, puede ver información sobre la última confirmación en la rama actual ejecutando git last.

Te aconsejo que uses las siguientes abreviaturas (también puedes definir las tuyas propias):

• st = estado
• ch = pago
• br = rama
• mg = fusionar
• cm = commit
• reb = rebase
• lg = "git log --pretty = formato: '% h -% ar:% s'”

Para ver las configuraciones, use: git config --list.

2. Los fundamentos de git

Aquí solo se enumeran los parámetros obligatorios y útiles (en mi opinión), porque enumerar todo es inapropiado. Para hacer esto, use el comando git -help o --help, donde comando es el nombre del comando para la ayuda que desea recibir.

2.1 Crear un repositorio

• git init [<options>] - Crea un repositorio git y un directorio .git en el directorio actual (o en el directorio especificado después de --separate-git-dir <raíz_git>, en cuyo caso el directorio .git estará en otro lugar);
• git clone [<options>] [-] <repository> [<folder>] [-o, --origin <name>] [-b, --branch <branch>] [--single-branch] [- -no-tags] [--separate-git-dir <raíz_git>] [-c, --config <clave = valor>] - Clona repositorios con el origen del nombre (o el que especifique -o <nombre> ), estar en la rama a la que apunta HEAD (o la que especifique -b <branch>). También puede clonar solo la rama HEAD necesaria (o la especificada en -b <branch>) especificando --single-branch. Por defecto, todas las etiquetas se clonan, pero al especificar --no-tags no puede clonarlas. Después de ejecutar el comando, el directorio .git se crea en el directorio actual (o en el directorio especificado después de --separate-git-dir <raíz_git>, en cuyo caso el directorio .git se ubicará en otro lugar);

2.2 Estado del archivo

Para ver el estado de los archivos en su repositorio, use:

 git status [<>] 

Este comando puede mostrarle: en qué rama se encuentra actualmente y el estado de todos los archivos. No hay opciones requeridas, solo se pueden distinguir -s de las útiles, que mostrarán una breve idea de los estados de los archivos.

Ciclo de vida del archivo
Como puede ver en la imagen, los archivos pueden ser rastreados y rastreados. Los archivos monitoreados pueden estar en 3 estados: No modificado (Sin modificar), modificado (Modificado), preparado (En etapas).
Si agrega (usando git add) un archivo "No supervisado", pasa al estado "Preparado".
Si cambia el archivo al estado "No cambiado", pasa al estado "Cambiado". Si guarda el archivo modificado (es decir, en el estado "Modificado"), pasa al estado "Preparado". Si confirma un archivo (es decir, en el estado "Preparado"), entra en el estado "No modificado".
Si las versiones del archivo en HEAD y el directorio de trabajo son diferentes, entonces el archivo estará en los estados "Modificado", de lo contrario (si la versión en el HEAD y el directorio de trabajo es el mismo "), el archivo estará en los estados" No cambiado ".
Si la versión del archivo en HEAD difiere del directorio de trabajo, pero no difiere de la versión en el índice, el archivo estará en el estado "Preparado".

Este ciclo se puede representar de la siguiente manera:
Sin modificar -> Modificado -> En etapas -> Sin modificar
Es decir, modifica el archivo, lo guarda en el índice y realiza una confirmación, y luego nuevamente.

2.3 Trabajando con el índice

Espero que entiendas cómo es el ciclo de vida del repositorio git. Ahora veamos cómo puede administrar el índice y los archivos en su repositorio git.

Un índice es un lugar intermedio entre su último compromiso y el siguiente. Puede agregar o eliminar archivos del índice. Cuando confirma, obtiene datos del índice, y no del espacio de trabajo.

Para ver el índice, use el estado de git.

Para agregar archivos al índice use

 git add [<>] 

Opciones útiles de comando git add:

• -f, --force - agrega archivos ignorados también
• -u, --update - actualizar archivos rastreados

Para eliminar archivos del índice, puede usar los comandos 2 git reset y git restore.
git-restore: restaura los archivos del árbol de trabajo.
git-reset: restablece el HEAD actual al estado especificado.
De hecho, puede lograr lo mismo con ambos comandos.

Para eliminar algunos archivos del índice, use:

 git restore --staged <file> 

de esta manera restaurará su índice (o más bien, eliminará archivos específicos del índice), como si git add no se hubiera ejecutado desde la última confirmación. Con este comando puede restaurar el directorio de trabajo para que parezca que no se realizaron cambios después de la confirmación. Pero este comando tiene un comportamiento un poco extraño: si agrega una nueva versión de su archivo al índice, no puede cambiar su directorio de trabajo hasta que el índice sea diferente de HEAD. Por lo tanto, primero debe restaurar su índice y solo luego el directorio de trabajo. Desafortunadamente, no es posible hacer esto con un comando, ya que al pasar ambos argumentos (git restore -SW) no sucede nada. Y de todos modos, cuando se pasa -W, no pasará nada si el archivo en el índice y HEAD son diferentes. Probablemente, lo hicieron por protección para que no cambie accidentalmente su directorio de trabajo. Pero en este caso, ¿por qué se pasa el argumento -W por defecto? En general, no entiendo por qué se hizo esto y por qué se agregó este comando. Para mí, restablecer hace frente a esta tarea mucho mejor, y también tiene una funcionalidad más rica, ya que puede mover el índice y el directorio de trabajo no solo a la última confirmación, sino también a cualquier otra.

Pero los propios desarrolladores recomiendan usar git restore -S para restablecer el índice. En lugar de git reset HEAD.

Usando el estado de git puede ver qué archivos han cambiado, pero si también desea saber qué ha cambiado exactamente en los archivos, use el comando:

 git diff [<options>] 

así, ejecutando el comando sin argumentos, puede comparar su índice con el directorio de trabajo. Si ya ha agregado archivos al índice, use git diff --cached para ver las diferencias entre la última confirmación (o la que especifique) y el directorio de trabajo. También puede ver las diferencias entre dos confirmaciones o ramas pasándolas como argumento. Ejemplo: git diff 00656c 3d5119 muestra las diferencias entre commit 00656c y 3d5119.

2.4 Trabajando con commits

Ahora que su índice está en el estado correcto, es hora de confirmar sus cambios. Recuerde que todos los archivos para los que no ejecutó git add después de la edición no están incluidos en esta confirmación. De hecho, habrá archivos en él, pero solo su versión anterior (si la hay).

Para confirmar sus cambios, use:

 git commit [<>] 

Opciones útiles para el comando git commit:

• -F, --file [archivo] - Escribe un mensaje de confirmación del archivo especificado
• --author [author] - Reemplazar autor de confirmación
• --date [date] - Cambia la fecha de confirmación
• -m, --mesage [mensaje] - Confirmación de mensaje
• -a, --all - Confirma todos los cambios en los archivos
• -i, --include [archivos ...] - Agrega los archivos especificados al índice para la próxima confirmación
• -o, --only [files ...] - Confirma solo los archivos especificados
• --amend - Sobrescribir confirmación anterior

Puede definir un mensaje de confirmación predeterminado mediante commit.template. Esta directiva en el archivo de configuración es responsable del archivo cuyo contenido se utilizará para la confirmación predeterminada. Ejemplo: git config --global commit.template ~ / .gitmessage.txt.

También puede cambiar, eliminar, fusionar cualquier confirmación.
Como habrás notado, puedes sobrescribir rápidamente la última confirmación con git commit --amend.
Para cambiar la confirmación en su historia, use

 git rebase -i <commit> 

donde commit es el commit principal de tu cadena desde el cual te gustaría cambiar cualquier cosa.

Después de ejecutar git rebase -i en el menú interactivo, seleccione lo que desea hacer.

• seleccione <commitir> = usar confirmación
• reword <commit> = use commit, pero cambie el mensaje de confirmación
• edit <commit> = use commit, pero pare para arreglar
• squash <commit> = usar commit, pero fusionar con commit anterior
• Fixup <commit> = como "squash", pero omita el mensaje de confirmación
• exec <comando> = ejecuta el comando (resto de la línea) usando el shell
• break = detente aquí (continúa con "git rebase --continue")
• drop <commit> = eliminar commit
• etiqueta <label> = dar nombre al HEAD actual
• reset <label> = restablecer HEAD a la etiqueta especificada

Para cambiar el mensaje de una confirmación específica.
Debe cambiar la selección para editar sobre la confirmación que desea cambiar.
Ejemplo: desea cambiar el mensaje de confirmación 750f5ae.

recoger 2748cb4 primer compromiso
editar 750f5ae segunda confirmación
recoger 716eb99 tercer commit

Después de guardar el script, volverá a la línea de comando y git le dirá qué hacer a continuación:

Se detuvo en 750f5ae ... segunda confirmación
Puede modificar la confirmación ahora, con

git commit --amend

Una vez que esté satisfecho con sus cambios, ejecute

git rebase --continuar

Como se indicó anteriormente, debe ejecutar git commit --amend para cambiar el mensaje de confirmación. Luego ejecute git rebase --continue. Si ha seleccionado varias confirmaciones para cambiar el nombre, estas operaciones deberán realizarse en cada confirmación.

Para eliminar una confirmación
Debe eliminar la línea con la confirmación.
Ejemplo: desea eliminar el commit 750f5ae
Necesita cambiar el script de esto:
recoger 2748cb4 tercera confirmación
recoger 750f5ae segunda confirmación
recoger 716eb99 primer compromiso
en esto:
recoger 2748cb4 primer compromiso
recoger 716eb99 tercer commit

Para fusionar commits
Debe cambiar la selección para aplastar las confirmaciones que desea fusionar.
Ejemplo: desea combinar los commits 750f5ae y 716eb99.
Necesita cambiar el script de esto:
recoger 2748cb4 tercera confirmación
recoger 750f5ae segunda confirmación
recoger 716eb99 primer compromiso
En tal
recoger 2748cb4 tercera confirmación
squash 750f5ae segunda confirmación
squash 716eb99 primer commit

Observe que en la secuencia de comandos interactiva, las confirmaciones se muestran en orden inverso que en git log. Usando squash, combina el commit 750f5ae con 716eb99 y el commit 750f5ae con 2748cb4. Como resultado, obtener una confirmación que contenga cambios en los tres.

2.5 Ver historial

Usando el comando

 git log [<>] [<->] 

Puede ver el historial de confirmación de su repositorio. También hay toneladas de opciones para ordenar y buscar una confirmación específica.

Opciones útiles del comando git log:

• -p: muestra la diferencia para cada confirmación.
• --stat: muestra estadísticas de archivos modificados para cada confirmación.
• --graph: muestra un gráfico ASCII con ramas e historial de fusión.

También puede ordenar las confirmaciones por tiempo, cantidad, etc.

• - (n) Muestra solo los últimos n commits.
• --since, --after - Muestra las confirmaciones realizadas después de la fecha especificada.
• --until, --before - Muestra las confirmaciones realizadas antes de la fecha especificada.
• --author: muestra solo las confirmaciones en las que la entrada del autor coincide con la cadena especificada.
• --committer: muestra solo los commits en los que la entrada del committer coincide con la cadena especificada.
• --grep: muestra solo confirmaciones cuyo mensaje contiene la cadena especificada.
• -S: muestra solo confirmaciones en las que un cambio en el código resultó en la adición o eliminación de la línea especificada.

Aquí hay algunos ejemplos:
git log --since = 3.weeks - Mostrar confirmaciones en las últimas 2 semanas
git log --since = "2019-01-14" - Muestra las confirmaciones realizadas en 2019-01-14
git log --since = "Hace 2 años y 1 día" - Muestra los compromisos realizados hace 2 años y un día.

También puede personalizar su formato de salida de confirmaciones con

 git log --format:["format"] 

Opciones de formato para git log --format.

• % H - Cometer hash
• % h: hash de confirmación acortado
• % T - Hash de árbol
• % t - Hash de árbol acortado
• % P - Hash principal
• % p: hash principal abreviado
• % an - Nombre del autor -% ae - Correo electrónico del autor
• % ad - Fecha del autor (el formato de fecha se puede configurar con la opción --date = opción)
• % ar - Fecha relativa del autor
• % cn - Nombre del confirmador
• % ce - Correo electrónico de confirmación
• % cd - Fecha de compromiso
• % cr - Fecha de confirmación relativa
• % s - Contenido

Un ejemplo:

 git log --pretty=format:"%h - %ar : %s" 

mostrará una lista de confirmaciones que consta de un hash de tiempo y un mensaje de confirmación.

2.6 Trabajar con un repositorio remoto

Dado que git es una moneda fuerte distribuida, puede trabajar no solo con repositorios locales sino también externos.

Los repositorios remotos son versiones de su proyecto almacenadas en un servidor externo.

Para trabajar con repositorios externos, use:

 git remote [<options>] 

Si clonaste los repositorios a través de la URL http, entonces ya tienes un enlace al externo. De lo contrario, puede agregarlo con

 git remote add [<options>] <name> <adres> 

Puede extraer inmediatamente las ramas externas usando -f, --fetch (obtiene los nombres y el estado de las ramas del repositorio externo). Solo puede configurar repositorios para enviar o recibir datos usando --mirror [= (push | fetch)]. Para obtener etiquetas, especifique --tags.

Para ver los repositorios externos conectados, use git remote sin argumentos o git remote -v para ver las direcciones para enviar y recibir datos del repositorio.

Para rastrear ramas, use git branch -u <rep / br> donde rep es el nombre del repositorio, br es el nombre de la rama externa y branch es el nombre de la rama local. O git branch --set-upstream local_br origin / br para indicar qué rama local supervisará la rama externa.

Cuando su rama realiza un seguimiento de una externa, puede averiguar qué rama (local o externa) está detrás o por delante y por cuántas confirmaciones. Por ejemplo, si después de una confirmación no realizó git push, entonces su rama estará por delante de la externa en 1 confirmación. Puede averiguar sobre esto ejecutando git branch -vv, pero primero haga git fetch [nombre-remoto] (--todos para obtener actualizaciones de todos los repositorios) para obtener los últimos datos de un repositorio externo. Para cancelar el rastreo de rama, use git branch --unset-upstream [<local_branch>].

Para descargar datos de un repositorio externo, use git pull [rep] [branch]. Si sus ramas rastrean externas, entonces no puede especificarlas cuando realiza git pull. Por defecto, recibirá datos de todas las sucursales monitoreadas.

Para cargar sucursales en una nueva sucursal, use git checkout -b <nuevo_nombre_de_rango> <rep / branch>.

Para enviar datos al servidor, use

 git push [<rep>] [<br>] 

donde rep es el nombre del repositorio externo y br es la rama local que desea enviar. También puede usar esta entrada git push origin master: dev. Por lo tanto, carga su rama maestra local al origen (pero allí se llamará dev). No podrá enviar datos a un repositorio externo si no tiene permiso para hacerlo. Además, no podrá enviar datos a una sucursal externa si está por delante de la suya (en general, puede enviar utilizando -f, --por lo tanto, en este caso, reescribirá el historial en el repositorio externo). Puede omitir el nombre de la sucursal si su sucursal está rastreando el exterior.

Para eliminar ramas externas use

 git push origin --delete branch_name 

Para obtener información detallada sobre el repositorio externo (direcciones para enviar y recibir, según lo indicado por HEAD, ramas externas, ramas locales configuradas para git pull y enlaces locales configurados para git push)

 git remote show <remote_name> 

Para cambiar el nombre del repositorio externo, use

 git remote rename <last_name> <new_name> 

Para eliminar enlaces a un repositorio externo, use

 git remote rm <name> 

3. Ramificación en git

Branching es una herramienta poderosa y una de las principales características de git, ya que le permite crear y cambiar rápidamente entre diferentes ramas de su repositorio. El concepto principal de ramificación es que puede despegar de la línea principal de desarrollo y continuar trabajando independientemente de ella, sin interferir con la línea principal. Una rama siempre apunta al último commit en ella, y HEAD apunta a la rama actual (ver Punteros en git ).

3.1 Operaciones básicas

Para crear una rama, use

 git branch <branch_name> [<start_commit>] 

Aquí branch_name es el nombre de la nueva rama, y ​​start_commit es el commit al que apuntará la rama (es decir, el último commit en ella). Por defecto, la rama estará en la última confirmación de la rama principal.

Opciones de rama de Git:

• -r | -a [- combinado | --no-merged] — -r. -a. --merged. --no-merged.
• -l, -f <-> [<->] — -l. , -f. < >.
• -r (-d | -D) — -r. -d. ( ) -D.
• -m | -M [< >] < > — / (-m). / , -M.
• (- | -) [<->] <-> — -c. , -C.
• -v, -vv: lista de ramas con la última confirmación en la rama -v. Lista y estado de las sucursales monitoreadas con el último compromiso con ellas.

Ver git branch -h para más información | --ayuda

Para cambiar a una rama, use git checkout. También puede crear una rama ejecutando git checkout -b <branch>.

3.2 Fusión de sucursales

Para fusionar 2 ramas de un repositorio git, use git merge.

Opciones útiles para git merge:

• --squash: crea una confirmación en lugar de fusionarla. Si tiene un conflicto en las ramas, luego de resolverlo, tendrá 2 confirmaciones agregadas en la rama (confirmación de la rama fusionada + confirmación de fusión), pero al especificar este argumento solo agregará una confirmación (confirmación fusionada).
• --ff-only - No fusionar si hay un conflicto. Deje que alguien más resuelva conflictos: D
• -X [estrategia]: utiliza la estrategia de combinación seleccionada.
• --abort - Cancele la fusión.

El proceso de fusión.
Si no ejecutó nuevas confirmaciones en la rama principal, entonces la fusión se reduce a avance rápido rápido, como si no estuviera creando una nueva rama, y ​​todos los cambios ocurrieron aquí (en la rama principal).

Si realizó confirmaciones en ambas ramas, pero no creó un conflicto, la fusión tendrá lugar en la "estrategia recursiva", es decir, solo necesita crear una confirmación de fusión para aplicar los cambios (use la opción --squash para evitar crear una confirmación adicional) .
Si realizó confirmaciones en ambas ramas que realizaron cambios diferentes en la misma parte del mismo archivo, entonces tendrá que resolver el conflicto y confirmar la confirmación de fusión.

Al resolver el conflicto, debe elegir qué parte de los cambios de las dos ramas desea dejar. Cuando abra un archivo en conflicto, contendrá lo siguiente:
<<<<<<< HEAD
Habrá una versión de la última confirmación de la rama actual
======
Habrá una versión de la última confirmación de la rama combinada
>>>>>>> Aquí el nombre ramas con las que nos fusionamos

Una vez resuelto el conflicto, debe completar la fusión al comprometerse.

Durante un conflicto, puede ver qué diferencias existen en qué archivos.
git diff --ours - Diferencia antes de fusionar y después de
git diff --theirs - Diferencia de rama fusionada antes de fusionar y después de
git diff --base - Diferencia con ambas ramas antes de fusionar y después

Si no desea permitir la fusión, utilice varias estrategias de fusión, ya sea eligiendo "nuestra" versión (es decir, la que se encuentra en la rama actual) o eligiendo la versión "su" ubicada en la rama fusionada sin solucionar el conflicto. Ejecute git merge --Xours o git merge --Xtheirs respectivamente.

3.3 Rerere

Rerere - "reutilizar la resolución grabada" - "reutilizar las resoluciones de conflicto guardadas". El mecanismo de recuperación puede recordar cómo resolvió cierta parte del conflicto en el pasado y corregirlo automáticamente la próxima vez que ocurra.

Para habilitar rerere do

 git config --global rerere.enabled true 

También puede habilitar rerere creando el directorio .git / rr-cache en el repositorio deseado.

Use el estado de git rerere para ver qué archivos ha guardado instantáneas antes de fusionar.

Use git rerere diff para ver el estado actual del conflicto.

Si durante la fusión dice: Resuelto 'nombreArchivo' usando resolución anterior. Así que rerere ya resolvió el conflicto utilizando el caché.

Para cancelar la resolución automática de conflictos, use git checkout --conflict = merge para cancelar la resolución automática de conflictos y devolver los archivos al estado de conflicto para resolución manual.

4. Punteros en git

git tiene punteros como la rama HEAD. De hecho, todo es muy simple HEAD apunta a la rama actual, y la rama apunta a la última confirmación. Pero para entenderlo es mejor imaginar que HEAD indica la última confirmación.

4.1 Punteros móviles

El libro Pro git proporciona un muy buen ejemplo de cómo puede administrar su repositorio, por lo que también me quedaré con él. Imagina a Git administrando el contenido de tres árboles diferentes. Aquí, "árbol" se refiere a un "conjunto de archivos".
En sus operaciones habituales, Git maneja tres árboles:

• HEAD - Instantánea del último commit, padre del siguiente
• Índice - Instantánea de la próxima confirmación próxima
• Directorio de trabajo - Sandbox

En realidad, git proporciona herramientas para manipular los tres árboles. A continuación, se discutirá el comando git reset, que le permite trabajar con tres árboles de su repositorio.

Usando las diversas opciones de este comando puedes:

• --soft - Restablecer solo HEAD
• --mixed - Restablecer HEAD e índice
• --hard - Restablecer HEAD, índice y directorio de trabajo

Restablecer significa pasar a la confirmación especificada. El valor predeterminado es --mixed.

Ejemplo 1. Ha realizado 3 confirmaciones adicionales, cada una de las cuales trae pequeños cambios y desea hacer una de ellas, por lo que puede usar git reset --soft para mover el puntero HEAD mientras deja el índice y el directorio de trabajo sin tocar y confirmar. Como resultado, su historia se verá como todos los cambios ocurridos en una confirmación.

Ejemplo 2. Agregó archivos adicionales al índice y desea eliminarlos de allí. Puede usar git reset HEAD <archivos ...> para esto. ¿O desea que los archivos de confirmación se vean como un par de confirmaciones? Como dije anteriormente, puede restablecer el índice a cualquier confirmación, a diferencia de git restore, que se restablece solo hasta la última confirmación. ¡Solo con la opción mixta puede aplicar una acción al archivo especificado!

Ejemplo 3. Comenzaste a trabajar en una nueva característica en tu proyecto, pero de repente el empleador dice que ya no es necesario y estás en un ataque de ira al hacer git reset: devolver tu índice, archivos y HEAD para cuando no hayas comenzado a trabajar. características. Y al día siguiente se le dice que la función aún debe eliminarse. Pero que hacer? Cómo avanzar, porque retrocediste los 3 árboles y ahora no puedes encontrarlos en el historial usando git log. Y hay una salida: este es el registro de enlace de git reflog. Con este comando puede ver hacia dónde apunta HEAD y se moverá no solo hacia abajo en el historial de confirmaciones, sino también hacia arriba. Este registro es local para cada usuario.

En general, creo que puedes encontrar muchos más ejemplos que yo. En conclusión, puedo decir que con git reset puedes hacer magia ...

5.

1. Pro git — Scott Chacon
2. Git — . , ,
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Git (2016) — .
14. A Hacker's Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby