El primer commit

Untrached

Cuando creamos un repositorio en un folder, adicionamos los primeros archivos y posteriormente iniciamos git con el comando "git init", aquellos archivos están es su primera etapa untracked (algo así como "sin seguimiento"), lo podemos verificar con el comando:

git status

donde lista los archivos, folder (blobs) que no han sido "traqueados", es decir, los archivos nuevos y también los modificados en el caso de que ya se tengan algunos archivos creados anteriormente y se hayan modificado.

Staging

El proximo paso es cambiar de estación los archivos, staging es algo así como una plataforma de lanzamiento donde se pueden acumular los archivos que se está seguro que almacenaremos en el repositorio. Para cambiar de estación los archivos nuevos o modificados desde untracked se utiliza el comando:

git add menu.txt

en este caso se pasa a staging el archivo menu.txt.

git add recipes/

en este caso se pasa a staging el folder recipes con todo su contenido. Una vez se pasen todos los archivos a staging se puede consultar con "git status" que la lista de untracked ya no está.

git add .

El anterior comando envía a staging todos los archivos en que están untracked.

Commit

Cuando todos los cambios y nuevos archivos están en staging y se quiere pasar a la estación de confirmado se utiliza el comando:

git commit -m

el flag -m nos da la posibilidad de poner un comentario descriptivo de mi confirmación, el comentario debe describir los cambios o nuevas características del repositorio.

git log

el anterior comando lista los commits con su respectiva clave hash, autor, fecha de creación y comentario.

El commit se almacena de la misma forma que cualquier archivo en el folder .git

Comienza lo interesante

git cat-file -p 5447babb053bb740cbb507d15db2eda6aa232868

con el comando anterior se consulta el blob:

tree 6e1a5a802c1184d48cf8403736d5de39bce94561
author nameAuthor <[e-mail]> 1501534024 -0500
committer nameAuthor <[e-mail]> 1501534024 -0500

first commit

El campo interesante en esta consulta es el nuevo hash que se creó: tree 6e1a5a802c1184d48cf8403736d5de39bce94561

Es otro blob creado por git que esta apuntando a la raíz del proyecto, se puede comprobar si buscamos en la base de datos de git, es decir el folder objects que se ha creado el folder de nuestro árbol "6e" y por supuesto un blob dentro nombrado con el resto de hash de nuestro tree:

git cat-file -p 6e1a5a802c1184d48cf8403736d5de39bce94561

Consultando el tree

100644 blob bff758505dfec95aa12cbf596955c158744ae321    menu.txt
040000 tree dc581903caf37a56feade1de04c26d6eceffac5a    recipes

lista los archivos o blobs involucrados en commit, estos son hash familiares ya que son los mismos que tenemos en sistema de archivos (base de datos git) en el folder object, es decir ya existen y simplemente el tree apuntan a ellos. Esto toma mucha importancia a la hora de devolvernos entre commits.

Otro punto importante de git

Como se sabe git utiliza algoritmo de encrypt SAH1 lo que significa que para un mismo texto genera un mismo hash, para nuestro ejemplo menu.txt contiene "Apple Pie" y Recipes/apple_pie.txt también, git inteligentemente crea un hash para menu.txt y pone a apuntar apple_pie.txt al mismo hash. Por lo tanto en la base de datos git (folder objects) estos dos archivos equivalen a un solo hash, un folder con los dos primeros dígitos y un blob con el resto del hash.

Lo anterior no ocurre creando el hash del commit por que allí se tiene en cuenta el autor y la fecha, siempre se genera un diferente hash.

• un vistazo gráfico del primer commit:
• Rojos Commit

• Amarillo Tree (note que 3ee7 está apuntando a el mismo blob que menu.txt 2399, puesto que tienen exactamente el mismo contenido git no crea un nuevo blob)

• Azul blob (archivo binario)