path: root/es/2.md

---
title: GIT
subtitle: Uso avanzado
license: CC-BY-NC-SA 4.0
author: Ekaitz Zarraga - ElenQ Technology
links-as-notes: true
lang: spanish
polyglossia-lang:
    name: spanish
how-to: pandoc -f markdown+smart -t beamer % -o pdf/2.pdf --pdf-engine=xelatex --template=./template.tex
...

## Licencia

- CC-BY-SA 4.0
- El contenido del documento ha sido adaptado de [**Pro Git (Scott Chacon, Ben
  Straub)**](https://git-scm.com/book/en/v2).

# Git en el servidor

## Git en el servidor: introducción

Para compartir el trabajo con el resto del equipo de desarrollo suele
utilizarse un servidor: siempre está disponible, facilita la gestión, etc.

En los servidores suelen utilizarse lo que se conoce como *bare repository*.
Éstos no tienen *working directory*: sólo tienen directorio `.git`.

- `git init --bare` construye un *bare repository*

> Los *bare repository* suelen nombrarse `loquesea.git` porque sólo contienen
> la propia carpeta `.git`, pero siguen siendo directorios, a pesar de su
> extensión.

## Protocolos

- **Local**: un repositorio que está en otro lugar del sistema de archivos de
  la máquina: `git clone /path/to/file`
- **HTTP**: tiene modos *smart* o *dumb*, el primero siendo capaz de gestionar
  permisos.
- **SSH**: es uno de los modos más utilizados. Necesita unas credenciales:\
  `git clone ssh://[<user>@]<host>/<project>.git`\
  También se puede usar el modo corto de SCP: `[<user>@]<host>:<project>.git`
- **Git**: Similar a SSH pero sin autenticación

## Protocolos — Un ejemplo

Mi [servidor](https://git.elenq.tech/):

- Está accesible desde la Web mediante `cgit`. Hay otras interfaces web como
  `gitweb`, que viene con el propio Git.
- Los proyectos públicos se pueden clonar sin problema con el protocolo Git.
- Para escribir, aporto acceso mediante SSH para tener control de permisos.

*En el libro se cuenta cómo montarlos*

## Workflows con Git

Git es un sistema distribuido, lo que permite muchos workflows distintos. Sin
embargo, hoy en día se usa sobre todo el workflow *centralizado*, debido al
éxito de las plataformas web que integran muchas partes del proceso de
desarrollo de software (incidencias, releases, etc) junto al control de
versiones: GitHub, GitLab, Gitea...

![Los clientes se sincronizan con el servidor](img/centralized_workflow.png){ height=140px }

## Mediante email

Muchos proyectos de software libre se basan en el email:

- `git format-patch <selector-de-commits>` crea parches a partir de los commits
  seleccionados
- `git send-email <parches>` envía los parches por email (requiere de
  configuración adicional)
- `git am <parches>` aplica los parches en el proyectos mediante commits
- `git apply <parches>` aplica los cambios de los parches sin commitear


# Herramientas avanzadas de Git

## Selectores de commits

Se pueden aplicar de forma generalizada en muchísimos comandos de Git.

- `git show <selector de commits>` para mostrar los objetos seleccionados.

> Ver la ayuda de `git show`

> Ver la ayuda de `git rev-parse` para leer la sintaxis de los selectores

## Selectores de commits — I

- **Hash SHA-1** el propio identificador de un commit es un selector válido.
  Como son muy largos pueden abreviarse (ver `git log --abbrev-commit`)

- **Cabezas de Ramas** (también llamadas *head*), son el nombre de la rama y se
  resuelven al commit al que la rama apunta. Ejemplo `git show <rama>`. Para
  ver cuál es el commit subyacente `git rev-parse <rama>`. *Cuidado, a veces
  funcionan como cabeza y otras como la rama completa*

- **El Reflog** es un registro histórico de los cambios aplicados en Git
  (similar al undo/redo de cualquier programa). Las entradas del Reflog pueden
  usarse como selectores. Es interesante porque pueden usar el tiempo:
  `HEAD@{yesterday}`

  - `git reflog` para listar las entradas del *reflog*.


## Selectores de commits — II

- **Ancestros** de los commits:

  - El acento circunflejo (`^`) indica el padre del selector utilizado. Por
    ejemplo: `git show HEAD^`. Los *merge commits* tienen muchos padres, y se
    puede elegir cuál de ellos con un número después del símbolo `^`.

  - La vírgula (`~`) sirve para obtener los ancestros del selector. Es similar
    al anterior, pero al añadir un número se elige la generación, no cuál de
    sus padres. `git show HEAD~2` elige el padre del padre mientras que
    `git show HEAD^2` elige el segundo padre.

> Usados por separado, son equivalentes

## Selectores de commits  — III

- **Rango de commits** indicados mediante `..` seleccionan una lista de commits
  entre los dos selectores indicados en los extremos.
  ![](img/double-dot.png){width=350px}\
  - `git log master..experiment` => D C\
  - `git log experiment..master` => F E

## Selectores de commits  — IV

- Los **puntos triples** actúan como un rango pero seleccionan los commits a
  los que se puede llegar desde las dos cabezas indicadas pero que las dos
  ramas no tienen en común.
  ![](img/double-dot.png){width=350px}\
  - `git log master...experiment` => F E D C\
  - Para ver de dónde vienen, `--left-right`:
    ```
    git log master...experiment --left-right
    < F
    < E
    > D
    > C
    ```

## Selectores de commits  — V

- **Puntos múltiples** pueden seleccionarse mediante `--not` o `^` (por
  delante) para retirar commits de un selector:
  - Los siguientes comandos son equivalentes:
    ```
    git log refA..refB
    git log ^refA refB
    git log refB --not refA
    ```
  - Los siguientes comandos obtienen los commits de `refA` y `refB` pero
    descartan los de `refC`:
    ```
    git log refA refB ^refC
    git log refA refB --not refC
    ```

## Staging interactivo

- `git add --interactive|-i` para gestionar el *stash* de forma interactiva
- `git add --patch|-p` para seleccionar los cambios manualmente

> Se pueden aplicar en muchos comandos diferentes. Son muy útiles.


## El stash

El *stash* es un saco donde guardar cambios no guardados, así se pueden aplicar
otros cambios en el repositorio sin mezclarlos.

- `git stash [push]` introduce los cambios en el stash y limpia el directorio
  de trabajo
- `git stash list` muestra las entradas del stash
- `git stash apply [<entrada del stash>]` aplica los cambios de la entrada del
  stash seleccionada (por defecto la última) en el *working directory*.
- `git stash drop [<entrada del stash>]` borra la entrada del stash
  seleccionada
- `git stash pop` = `git stash apply` + `git stash drop` (sólo aplica el `drop`
  si el `apply` ha ido bien)

Se usan mensajes *push* y *pop* porque las entradas del stash funcionan como
una pila (*stack*)

## El stash — opciones interesantes

- `git stash apply --index` introduce los cambios en la *staging area* (también
  se llama *index*). Por defecto no lo hace.
- `git stash --keep-index` los archivos indexados (en el *staging area*) no se
  mandan al stash, se mantienen en el *index*
- `git stash --include-untracked|-u` los archivos no-trackeados también se
  mandan al *stash*.
- `git stash --all|-a` los archivos ignorados (`.gitignore`) también se envían
  al *stash*
- `git stash --patch|-p` para seleccionar los cambios a enviar al *stash* de
  forma interactiva
- `git stash branch <rama> [<entrada del stash>]` crea una rama nueva y aplica
  el *stash* en ella. Si todo va bien borra la entrada del *stash* más tarde.

## Para limpiar el directorio

- `git stash --all` limpia el directorio enviando todo al *stash*. Luego se
  puede eliminar haciendo `drop`

- `git clean` hace esto mismo, sin pasar por el *stash*.
  - `-f` (*force*) es necesario porque si no sólo aplica un *dry-run* (una
    muestra de lo que pasaría sin llegar a aplicarlo)

> CUIDADO: aplicar siempre el `--dry-run|-n` en `git clean` primero por si
> acaso.

## Firmas

Para evitar commits falsos, se pueden firmar por GPG.

> GPG (Gnu Privacy Guard), es una implementación de PGP (Pretty Good Privacy)

Hay que configurar `user.signkey`

- `git commit -S` para firmar el commit
- `git tag -s` para firmar etiquetas
- `git merge --verify-signatures` comprueba las firmas en el merge
- `git tag -v` comprueba las firmas en una etiqueta

Si se utilizan firmas, todo el equipo de desarrollo debe utilizarlas.

## Búsquedas

- `git grep` para hacer búsquedas mediante expresiones regulares. Similar al
  comando `grep`, pero es más rápido y busca en el index y el histórico
- `git log` es muy potente para buscar en el histórico
  - `-S` funciones *pickaxe*
  - `-L` para ver la evolución de una línea de código o una función

## Reescribir la historia

- `git commit --amend` es como un mini-rebase
- `git rebase -i|--interactive <selector>` cambia los commits necesarios para
  llegar al selector.\
  Abre un editor de texto con los commits seleccionados y permite manipularlos
  con diversos comandos (los explica en el propio editor) que sirven para
  fusionar commits, cambiar los mensajes, editar los contenidos... En algunos
  casos se pausa para editar el contexto, permite continuar mediante
  `git rebase --continue` o cancelar con `--abort`. El propio proceso es
  bastante explicativo.

- `git filter-branch` es mucho más poderoso pero menos utilizado. Permite
  cambiar todos los commits de una rama

## Reset y checkout en profundidad — I

Para entenderlos en detalle es necesario comprender los estados de los archivos
en profundidad. Hay tres secciones disponibles:

1. HEAD: el snapshot del último commit
2. Index: el *staging area*, la propuesta del próximo commit
3. Working directory: el lugar donde realizamos los cambios

![Egoren arteko trantsizioak](img/reset-workflow.png){height=150px}

## Reset y checkout en profundidad — II

- `git reset` tiene tres modos:
  - `--soft`: Mover la rama apuntada por HEAD
  - `--mixed`: `--soft` + pasar los cambios al index
  - `--hard`: `--mixed` + aplica los cambios también en tu *working directory*

## Reset y checkout en profundidad — III

Empezando con un repositorio vacío:

![&nbsp;](img/reset-ex1.png)

## Reset y checkout en profundidad — IV

Pasar un archivo al *index*:

![&nbsp;](img/reset-ex2.png)

## Reset y checkout en profundidad — V

Escribirlo en el repositorio:

![&nbsp;](img/reset-ex3.png)

## Reset y checkout en profundidad — VI

Cambiar un archivo:

![&nbsp;](img/reset-ex4.png)

## Reset y checkout en profundidad — VII

Mandar los cambios al *index*

![&nbsp;](img/reset-ex5.png)

## Reset y checkout en profundidad — VIII

Añadir un commit nuevo:

![&nbsp;](img/reset-ex6.png)

## Reset y checkout en profundidad — IX

Añadir otro commit

![&nbsp;](img/reset-start.png)

## Reset y checkout en profundidad — X

`--soft`:

![&nbsp;](img/reset-soft.png)

## Reset y checkout en profundidad — XI

`--mixed` (es el que se aplica por defecto):

![&nbsp;](img/reset-mixed.png)

## Reset y checkout en profundidad — XII

`--hard`:

![&nbsp;](img/reset-hard.png)

## Reset y checkout en profundidad — XIII

Además de las tres opciones, se le pueden entregar archivos a `git reset`.

En este caso, el primer paso (mover el HEAD) no puede aplicarse del todo[^head]
pero el resto pueden aplicarse sin problemas. Esto habilita funcionamientos
interesantes:

- `git reset <archivo>` realmente hace\
  `git reset --mixed HEAD <archivo>`\
  1. ~~Mueve el HEAD~~
  2. Coloca el estado del archivo en el index
\
  Esto es: **quita el archivo del staging area**

[^head]: El HEAD no se puede mover a medias, o se mueve el repositorio completo
    o no se mueve.

## Reset y checkout en profundidad — XIV

A nivel gráfico:

![&nbsp;](img/reset-path1.png)

## Reset y checkout en profundidad — XV

En un ejemplo más complejo: `git reset <commit> -- <file>`

1. El HEAD no se puede mover
2. Se mueve el estado que `<file>` tenía en `<commit>` al index (`--mixed`).

![&nbsp;](img/reset-path3.png){height=220px}

## Reset y checkout en profundidad — XVI

Puede usarse este concepto para hacer un *squash* (combinar muchos commits en
uno) fácilmente [^rebase-interactive].

- `git reset --soft HEAD~<N>` lleva HEAD hacia atrás, manteniendo los cambios
  en el *index*. Después, se puede hacer `git commit` para aplicar los cambios
  que quedaron en el *index*, todos de una vez. En **un solo commit**.

[^rebase-interactive]: También se puede hacer con `git rebase --interactive|-i`

## Reset y checkout en profundidad — XVII

Gráficamente:

![&nbsp;](img/reset-squash-r1.png)

## Reset y checkout en profundidad — XVIII

Mover el HEAD manteniendo los cambios en el index:

![&nbsp;](img/reset-squash-r2.png)

## Reset y checkout en profundidad — XIX

Añadir el commit con los cambios que quedaron en el index

![&nbsp;](img/reset-squash-r3.png)

## Reset y checkout en profundidad — XX

`checkout` y `reset` son similares pero no son iguales:

- `git checkout` no manipula el HEAD, sino que lo reasigna a la referencia que
  se le indique, sin transformar la rama subyacente.

- `git checkout <branch>` y `git reset --hard <branch>` son casi iguales, pero
  el checkout no pisa el directorio de trabajo directamente.

- `git checkout <archivo>` **pisa el estado del archivo** en el *working
  directory*, parecido a `git reset --hard`. CUIDADO

A ambos se les puede enviar `--patch` para realizarlos por partes.

## Reset y checkout en profundidad — XXI

Efecto en el HEAD:

![&nbsp;](img/reset-checkout.png)


## Merges avanzados, gestión de conflictos — I

Antes de hacer un *merge* es interesante limpiar el *working directory* (`git
stash`), de este modo, si algo falla es fácil volver atrás.

- `git merge --abort` deshace el merge en caso de conflicto.

  > CUIDADO: Si hay cambios en el directorio de trabajo, no sabrá abortar.

## Merges avanzados, gestión de conflictos — II

En los conflictos, Git aporta 3 archivos:

1. Stage 1: el *common ancestor* (*base*), el commit al que se puede acceder
   subiendo por ambas ramas. Para verlo puede usarse `git merge-base`
2. Stage 2: Nuestra (*ours*) versión, lo que está en nuestra rama
3. Stage 3: Su (*theirs*) versión, lo que está en la rama que estamos
   mergeando.

- `git show :<stageN>:<file>` para ver los archivos
  - `:<stageN>:<file>` obtiene el hash del blob señalado

- `git diff` muestra los cambios:
    - `git diff -1|--base`
    - `git diff -2|--ours`
    - `git diff -3|--theirs`

## Merges avanzados, gestión de conflictos — III

- `git show :<stageN>:<file>` se puede utilizar para obtener el contenido de
  los diferentes archivos y aplicarlos directamente.

- `git merge-file` puede utilizarse para aplicar el merge a mano. Aplica
  algoritmos de merging.

## Merges avanzados, gestión de conflictos — IV

Git tiene herramientas mejores:

- `git checkout --conflict` te devuelve al estado del conflicto, con los
  marcadores, para deshacer los cambios que se hayan podido realizar por error
  al tratar de corregir el conflicto

- `git checkout --ours/--theirs` para ver uno o otro estado

- `git log --oneline --left-right --merge` facilita mostrar el contexto

- `git diff` muestra un *combined diff* cuando se aplica en un conflicto

- `git show -p|--patch` junto con `--cc` muestra el *combined diff*

## Merges avanzados, gestión de conflictos — V

Este es el aspecto de un *combined diff*:

```
diff --cc hello.rb
index 0399cd5,59727f0..0000000
--- a/hello.rb
+++ b/hello.rb
@@@ -1,7 -1,7 +1,7 @@@
  #! /usr/bin/env ruby

  def hello
-   puts 'hola world'
 -  puts 'hello mundo'
++  puts 'hola mundo'
  end
```

Muestra dos columnas con símbolos `+` y `-`, mostrando qué ha ocurrido en cada
lado del merge.

## Merges avanzados, gestión de conflictos — VI

Puede ser interesante usar `diff3` para los conflictos. Por defecto se usa
`merge`. `diff3` muestra una parte adicional en el conflicto, que muestra la
*base*.

```
<<<<<<< ours
  puts 'hola world'
||||||| base
  puts 'hello world'
=======
  puts 'hello mundo'
>>>>>>> theirs
```

- `git checkout --conflict=diff3` para mostrar el conflicto en 3 partes

- `git config --global merge.conflictstyle diff3` recomiendo configurarlo para
  que funcione así siempre


## Deshaciendo merges — I

Dos modos:

1. `git rest --hard HEAD~` (sobreescribe el histórico)
2. `git revert -m 1 HEAD` añade un commit que deshace los cambios. Esto da
   problemas a la hora de volver a combinar la rama.


## Deshaciendo merges — II

`git revert -m 1 HEAD` añade un commit que deshace los cambios. `^M` y `C6`
tienen los mismos contenidos, pero los cambios en `topic` pueden accederse
desde `master`, para Git, ambas están mergeadas. CUIDADO

![](img/undomerge-revert.png)

## Deshaciendo merges — III

Lo que es peor, si se siguen añadiendo cambios en `topic` y se intenta hacer un
merge nuevo, Git no añadirá los cambios previos, pensando que ya fueron
combinados (y lo fueron) pero sin saber que se deshicieron. CUIDADO

![](img/undomerge-revert2.png)

## Deshaciendo merges — IV

Para evitar el problema, hay que deshacer de nuevo el commit que se deshizo.
Esto puede hacerse con un nuevo `revert`.

![](img/undomerge-revert3.png)

Ahora todos los cambios de `topic` se verán en `master`.

## Preferencias en los merges

`git merge` tiene muchas opciones y estrategias:

- `-X` añade opciones. Por ejemplo `-Xours` resuelve los cambios a nuestro
  favor.

- `-s` selecciona estrategias. Por ejemplo `-s ours` en lugar de hacer un merge
  sólo se queda con nuestros cambios. Es interesante para engañar a Git.

Las estrategias no son lo mismo que las opciones. Las estrategias *seleccionan*
qué algoritmo de merge utilizar. Las opciones *configuran* el algoritmo.

## Subtree

Los subtrees son un mecanismo para introducir otro proyecto dentro del actual.
Este sub-proyecto funciona como una rama independiente: se añade como un remoto
independiente en una rama suelta, que no tiene relación con las otras.

- `git read-tree` para leer el subproyecto e inicializarlo en una rama
  independiente
- `git merge -Xsubtree` para combinar (*merge*) la rama del subproyecto en el
  proyecto actual sin problemas
- `git diff-tree` para analizar cambios en el subproyecto, un `diff` normal no
  funcionaría

*No se utiliza mucho* porque hoy en día se usan los *submodules* en su lugar.
Pero es interesante para ver lo flexible de los métodos de merge.

## Rerere: Reuse Recorded Resolution — I

El rerere es un mecanismo para guardar soluciones a conflictos, y enseñar a Git
a resolverlos cuando vuelvan a darse. Por ejemplo:

1. Al mergear una rama de test aparecen conflictos
2. Se arreglan los conflictos
3. Los tests van mal
4. Se deshace el merge
5. Se arreglan los tests
6. Se vuelve a hacer el merge => los mismos conflictos reaparecen

Con el **rerere** se podía haber guardado la resolución en el paso 1, de esta
manera al aplicar el paso 6 Git podía haber recordado la solución del paso 1 y
volver a aplicarla sin necesitar interacción humana.

## Rerere: Reuse Recorded Resolution — II

- `git config --global rerere.enabled true`
- `git rerere status`
- `git rerere diff` para ver los cambios que aplicaría rerere
- `git add` + `git commit` guarda la resolución del conflicto:\
  `"Recorded resolution"`
- `git reset --hard HEAD^` volver atrás el en el tiempo, y volver a hacer el
  merge resuelve el conflicto automáticamente:\
  `"Resolved with previous resolution"`
- `git checkout --conflict=merge <file>` recupera el conflicto, desactivando el
  rerere
- `git rerere` se puede aplicar después el rerere automáticamente

## Debugging con Git

- `git blame|annotate` muestra qué commit introdujo las líneas del archivo
  indicado. Las líneas que empiezan con `^` fueron introducidas con la creación
  del archivo. Usar `-C` intenta buscar los bloques que han sido movidos[^move].

[^move]: Git no guarda record de los movimientos pero aplica algoritmos de
    búsqueda que pueden calcular este tipo de cambios.

- `git bisect` aplica el [método de la bisección][bisect] para buscar commits
  que introdujeron errores en el repositorio. Método:
  - Tomar dos commits: uno con error y otro sin él
  - Toma un commit en el centro de los dos: si tiene error, el commit que
    introdujo el error en el repositorio estará entre éste commit y el que no
    tenía error del paso anterior. Si no tiene error, será al revés.
  - Con el nuevo rango, repite el algoritmo tomando nuevos commits cada vez,
    hasta encontrar el commit que introdujo el fallo.

[bisect]: https://en.wikipedia.org/wiki/Bisection_method

## Debugging con Git: `git bisect`o

Pasos a aplicar:

1. `git bisect start` empezar
2. `git bisect bad` indicar commit actual como erróneo
3. `git bisect good <commit-id>` indicar último commit que se tiene constancia
   de que era correcto
4. `git bisect good/bad` Git elegirá commits y saltará a ellos para que los
   marquemos como `good` o `bad`:\
   `"Bisecting, N revisions left to test"`
5. `git bisect reset` volver al inicio

Se puede automatizar con `git bisect run <command>`. El comando debe retornar
`0` en casos de acierto y cualquier otro valor cuando falle.

## Submodule

Son un modo interesante para gestionar subproyectos en el repositorio.

- `git submodule add <URL>` crea un nuevo subproyecto e inicializa el archivo
  `.gitmodules`
- `.gitmodules` es un archivo que guarda los la información de los
  subproyectos: la URL, el nombre y el path.
- `git submodule add ...` seguido de `git diff --cached` muestra que el
  contenido de un submodulo no se gestiona como un archivo cualquiera:\
  `"Subproject commit ---"`
- `git diff --submodule --cached` muestra mejor el contenido
- `git push` añade el submódulo pero como una referencia a otro repositorio, no
  como archivo

## Clonar submódulos

- `git clone` **no** clona los submódulos automáticamente
- `git submodule init` inicializa el control de submódulos
- `git submodule update` para actualizar los archivos de los submódulos
- `git clone --recurse-submodule <URL>` descarga automáticamente todos los
  submódulos (recursivamente) al  hacer `clone`. Si no se hace, debe lanzarse
  `git submodule update --init` o `git submodule update --init --recursive` más
  tarde.

## Trabajar con submodulos

- `git config --global diff.submodule log` para no tener que añadir cada vez
  `--submodule` que se hace `git diff`
- `git submodule update --remote <submodule>` para actualizar los contenidos
  del submódulo. También se puede hacer `fetch` + `merge` dentro del submódulo.
- `git config -f .gitmodules submodule.<submodule>.branch <adarra>` para
  cambiar el submódulo de rama. Equivalente a editar el archivo `.gitmodules`
- `git config status.submodulesummary 1` para que `git status` muestre el
  estado de los submódulos.
- `git log --submodule` para mostrar el listado de cambios de los submódulos

## Publicar cambios de los submódulos

- `git push` dentro del submódulo publica sus cambios (son un repositorio
  normal)
- `git push --recurse-submodules=check|on-demand` hay dos estrategias. `check`
  comprueba si deben pushearse cambios, mientras que `on-demand` pushea
  automáticamente los submódulos si hay cambios en ellos.
  - `git config push.recurseSubmodules check|on-demand` para configurarlo por
    defecto

## Trucos con submódulos

- `git submodule foreach <command>` lanza un comando en cada submódulo.
  Ejemplo: `git submodule foreach 'git stash'`


## Bundle

Son archivos que guardan conjuntos de commits o repositorios completos de modo
que son fáciles de compartir.

- `git bundle create <file> [<commit selector>]` guarda los commits
  seleccionados en el archivo `<file>`. Normalmente es interesante introducir
  `HEAD` para que luego el bundle sepa dónde estaba el repositorio.

- `git clone <bundle-file>` para clonar desde un bundle. Necesita que el bundle
  contenga todos los commits del repositorio.

- `git bundle verify <bundle-file>` para comprobar si un bundle parcial se
  puede aplicar en el el repositorio actual

- `git bundle list-heads <bundle-file>` para ver las ramas en el archivo

- `git fetch/pull <bundle-file>` permite aplicar commits desde el archivo
  bundle

## Replace

La base de datos de Git no puede alterarse, pero con `git replace` puede
hacerse que parezca que ha cambiado.

- `git replace <object> <replacement>` hace que cuando se use `<object>`
  funcione como si se hubiese usado `<replacement>` en su lugar.

*No es común, investigar en el libro posibles casos de uso*

## Sistemas de credenciales

Al usar credenciales sobre HTTP Git necesita que todas las operaciones con el
servidor usen usuario y contraseña. Este comportamiento puede configurarse:

- `git config --global credential.helper <modo>`
    1. Pedir siempre (lo hace por defecto))
    2. `cache` mantener las credenciales en memoria 15 minutos
    3. `store` guardar las credenciales

Hay más opciones (`--timeout`, sistemas de credenciales a medida, etc.)


# Configuración avanzada

## Configuración

Ver documentación sobre la configuración `git help git-config`

- Editor y paginador: `core.editor` y `core.pager`
- Plantillas para commits: `commit.template`
- Herramientas de merge y diff: `merge.tool` y `diff.tool`
- Control de espacios en blanco: `core.autocrlf` y `core.whitespace`

## Git attributes — I

Dentro del proyecto, a nivel de archivo, se puede cambiar el comportamiento de
Git mediante los atributos (*attribute*).

- `.gitattributes` o `.git/info/attributes`, el primero se puede compartir en
  el repositorio, el segundo no.

El archivo `.gitattributes` es similar a `.gitignore`, además de las plantillas
que seleccionan los archivos se definen unos atributos para ellos. Muchas veces
se requiere de configuración adicional para los atributos mediante *drivers*.
Ver `git help attributes`

## Git attributes — II

Hay muchos atributos diferentes, los más interesantes:

- `binary` para tratar un archivo como binario
- `diff=<filtro>` pasa el archivo por el filtro indicado antes de hacer diff.
  Necesita configuración adicional:
  - `git config diff.<filtro>.textconv <programa>`
  - Por ejemplo: `*.png diff=exif`
    - `git config diff.exif.textconv exiftool`\
    para comparar los resultados de ejecutar `exiftool` sobre el archivo, en
    lugar de sus contenidos
- `ident` añade identificación. Sustituye el texto en `$Id$` por el SHA-1 del
  commit actual.

## Git attributes — III

- `filter` pasa los archivos por un filtro
    - `smudge` aplica el filtro cuando el archivo pasa del *index* al *working
      directory*
    - `clean` en el camino opuesto
    - Ejemplo: `*.c filter=ident`
        - `git config filter.ident.clean indent`\
          `git config filter.ident.smudge cat`\
          indenta los archivos automáticamente al hacer `git add` (a la vuelta
          no aplica nada)
- `export-ignore` ignora archivos al hacer un archivado del repositorio (`git
  archive`)
- `export-subst` aplica las expansiones que `git log` aplicaría y sustituye
  patrones en los archivos
- `merge` selecciona estrategias de merge por archivo

## Git hooks

Los hooks son programas que se ejecutan en momentos importantes del uso del
repositorio. Se usan muy a menudo.

- `.git/hooks` es el directorio donde se guardan, deben usar un nombre en
  particular y tener permisos de ejecución

Por defecto, se instalan varios hooks al hacer `git init` pero están
desactivados con `.sample` al final de su nombre. Se instalan para servir de
muestra.

## Hooks del lado del cliente

Para uso privado. **No se copian junto al repositorio**[^compartir-hooks]. Son
interesantes como alertas para quien use el repositorio: que los tests no
pasan, que hay un problema en los formatos, etc. Algunos interesantes:

- `pre-commit` se ejecuta antes de escribir el mensaje del commit. Se suele
  utilizar para comprobar si se ha olvidado algo.
- `prepare-commit-msg` procesa el mensaje de commit por defecto antes de
  mostrárselo al usuario. Sirve para añadir información adicional en el
  mensaje, cambiar la plantilla, etc.
- `commit-msg` procesa el contenido el mensaje del commit. Si el mensaje del
  commit no es correcto puede rechazarse. Se utiliza para asegurar que el
  mensaje de commit usa la forma adecuada.

[^compartir-hooks]: Hay herramientas que facilitan el intercambio de hooks,
    pero no están incluidas en Git.

## Hooks del lado del servidor

Son interesantes para imponer políticas de desarrollo, ya que pueden rechazar
`push`es si estas políticas no se cumplen. Algunos interesantes:

- `pre-receive` se lanza al recibir un `push`, recibe todas las referencias y
  si da error no se actualizarán los datos del servidor
- `update` similar al anterior, pero se ejecuta una vez por cada rama
- `post-receive` se ejecuta después de haber recibido todo bien, puede usarse
  como notificación


# Git por dentro

## Git por dentro: introducción

Git es una herramienta de bajo nivel y tiene comandos para trabajar a este
nivel conocidos como *plumbing*. Los que se han utilizado hasta ahora se
conocen como *porcelain*[^baño].

Git es una base de datos *content-addressed*. Sus elementos se guardan por
clave y valor (*key-value*) donde la clave se obtiene del valor. Hasta ahora se
ha visto: se usan los hashes SHA-1 de los contenidos del commit para
identificarlos.

El contenido de la base de datos se almacena en el directorio `.git`. Donde se
almacenan elementos de diferentes tipos.

[^baño]: En un baño, la porcelana está por fuera, las tuberías por dentro

## Tipos de datos

Hay dos tipos de dato principales en la base de datos de Git:

- Objetos: que tienen contenidos: commits, blobs, árboles, etc.
- Referencias: son elementos que apuntan a otros: ramas, etiquetas ligeras,
  etc.

## Objetos

Se almacenan en `.git/objects` usando sus hashes como identificador. Los
primeros dos caracteres como nombre de directorio.\
Por ejemplo: `.git/objects/cf/6cbb8a400c7cad0f7f93610366c3672f598cdd`

- `git hash-object -w` para escribir nuevos contenidos, devuelve el hash del
  objeto escrito
- `git cat-file` para leerlos, `-p` para mostrarlo bonito.

## Tipos de objetos

`git cat-file -t` muestra el tipo

- `blob` para guardar los contenidos de los archivos u otro tipo de datos
- `tree` para guardar directorios o los nombres de los archivos\
  Contienen entradas que apuntan a otros `tree`s o `blob`s identificándolos por
  su hash.
- `commit` para guardar los datos de los commits. Contiene: un `tree` con el
  snapshot, el mensaje, la autoría, etc.

## Tipos de objetos: tree

![](img/data-model-1.png)

## Tipos de objetos: commit

![](img/data-model-3.png)

## Referencias

Sólo contienen un identificador

- `git update-ref` puede actualizar su contenido. También se puede realizar
  manualmente

Hay diferentes tipos de referencias:

- Tag: Se guardan en `.git/refs/tag`. Cualquier objeto puede etiquetarse
  (normalmente sólo se hace con los commits). Hay dos tipos:
  - Lightweight tag: sólo son una referencia
  - Annotated tag: son un **objeto** y una referencia a éste
- Ramas: en `.git/refs/heads`. Hacen referencia a un commit
- Remotos: en `.git/refs/remotes` similares a las ramas pero no se pueden
  cambiar.
- HEAD: `.git/HEAD`. Apunta a una rama, pero puede apuntar a un commit
  (*detached HEAD*).

## Referencias: ramas

![](img/data-model-4.png)

## Ejercicio: notas

- `git notes` gestiona las notas

*Ver qué son, y cómo funcionan: `git help git-notes`*

## Packfiles

Para que el almacenamiento de archivos sea más eficiente Git utiliza sistemas
de compresión de archivos, pero no es suficiente.

Git se basa en snapshots, pero no guarda los archivos una y otra vez en cada
commit, sino que guarda sólo aquellos que han cambiado, y por partes.

Además, agrupa los archivos en *packfile*s para agilizar el proceso.

- `.git/objects/pack`
- `git gc` (*garbage colector*) agrupa los archivos y los comprime (git lo
  ejecuta automáticamente)
- `git verify-pack` comprueba el contenido de un packfile

## Mantenimiento y recuperación de datos

- `git gc --auto` reorganiza los packfiles
- `git reflog` almacena los cambios realizados en HEAD haciendo que los commits
  perdidos puedan recuperarse desde éste.
- `git fsck --full` muestra los elementos perdidos, permitiendo también la
  recuperación.

*EJERCICIO: si se añade un archivo grande por accidente, `git rm` no lo
elimina, por lo que se convierte en un problema. ¿Cómo se borra? ¿Por qué?*

## El refspec

Para gestionar el mapeo entre las ramas remotas y locales. Éste es el contenido
de `.git/config` tras hacer
`git remote add origin https://github.com/schacon/simplegit-progit`:

```
[remote "origin"]
	url = https://github.com/schacon/simplegit-progit
	fetch = +refs/heads/*:refs/remotes/origin/*
```

El bloque `fetch` indica mediante el refspec cómo se deben gestionar las ramas.
Puede haber muchas entradas, con diferentes reglas. Formato:

- Un `+` indica (opcional) si deben actualizarse incluso cuando no es
  *fast-forward*
- `<fuente>:<destino>` indica cómo mapear las ramas. Ambos son patrones. Puede
  usarse `*` para indicar «todo»

## El refspec manualmente

Pueden usarse patrones al hacer `fetch` o `push` para indicar este aquí y este
allá.

Git aplica expansiones basándose en el refspec:

- `git log origin/master`\
   => `git log remotes/origin/master`\
   => `git log refs/remotes/origin/master`

Antes, para borrar las ramas había que usar el refspec:

- `git push :<rama>` al añadir la fuente vacía, en el remoto se borra la rama
- Ahora puede usarse `git push --delete <rama>`