Versionamiento

Si se genera un nuevo cambio en este caso el archivo menu.txt adicionando el texto "chessecake", se procesa de la misma manera:

1. git status para ver la lista ya no de untracked si no de changes not staged

2. git add menu.txt para adicionar el cambio a la estación de staging

3. git commit -m "add cake" para confirmar el cambio y adicionar la descripción

git log

para ver la lista de los commit, deja de resultado:

commit 81e0c75578af8a2e38bbeb4d6ef68876c764368f (HEAD -> master)
Author: userName <[e-mail]>
Date:   Fri Sep 29 14:34:16 2017 -0500

    Add cake

commit fedd270e925e7c3f6d6e84974e86ee0f41df53ac
Author: userName <[e-mail]>
Date:   Mon Jul 31 16:37:53 2017 -0500

    add folder recipes

commit 5447babb053bb740cbb507d15db2eda6aa232868
Author: userName <[e-mail]>
Date:   Mon Jul 31 15:47:04 2017 -0500

en la lista de commits consultamos el último con:

git cat-file -p 81e0c75578af8a2e38bbeb4d6ef68876c764368f

y resulta:

tree 6a7ec9ab263924655bb0687297946378755b25f9
parent fedd270e925e7c3f6d6e84974e86ee0f41df53ac
author oswaldovision <[e-mail]> 1506713656 -0500
committer oswaldovision <[e-mail]> 1506713656 -0500

Add cake

interesante que este commit tiene un campo parent adicional al primer commit, este parent es el hash del commit inmediatamente anterior, probando que los commit están enlazados y que todos los commit tienen un parent excepto el primer commit. el campo tree del primer commit es diferente al del segundo commit, s apenas obvio por que se realizó un cambio sobre el archivo menu.txt, es decir que git creó un nuevo hash para el archivo por que cambio su contenido. los hash de los archivos que no cambiaron siguen siendo los mismos del commit anterior (git solo mantiene sus referencias y no crea nuevos hash si no han cambiado, por eso es muy eficiente git). Git no almacena la misma cosa mas de una vez.

Note que en el segundo commit, tree 6ee0 recipes apunta al mismo tree del primer commit 3ee7 puesto que su contenido no cambió, para el segundo commit solo cambió el contenido del archivo menu.txt por lo que git crea un nuevo blob.

Consultando el número de objetos creados en la base de datos git:

git count-objects

resulta:

10 objects, 40 kilobytes

note que también devuelve el tamaño de la base de datos git.

Obviamente git maneja otras capas de optimización en esta estructura de almacenamiento, como el poder comprimir varios blobs en uno solo, ser eficiente en los casos que se cambia una sola línea en los archivos grandes, etc. Pero este es el modelo que se debe dominar para empezar a comprender como trabaja realmente git.