Tabla de Contenidos
Fundamentos y arquitectura interna de Git
Sección perteneciente al curso Control de versiones con Git Avanzado.
Introducción
Veremos en qué consiste un commit, cómo hacerlo. Las zonas con las que trabaja Git.
Veremos también las referencias en Git, ya que las ramas son en realidad referencias.
Por último, veremos cómo dejar archivos fuera de la vigilancia de Git.
Working directory y repositorio
Al trabajar con Git, estaremos trabajando con diferentes zonas por las que pasarán nuestros ficheros. Dos de estas zonas son:
- Working directory
- Repositorio
Working directory es nuestra carpeta de trabajo (lo que podemos ver desde nuestro navegador de archivos, por ejemplo). Cuando lo gestiona Git, se crea una carpeta llamada .git,
El repositorio es donde se almacenan los commits. El repositorio está dentro de la carpeta .git.
Cuando se represetan los commits, las flechas indican parentesco, es decir, la flecha sale de un commit y apunta al commit padre.
La representación de los commits y sus relaciones es lo que se conoce como log (listado de commits).
Commits
Un commit es una captura (snapshot) de cómo está nuestra carpeta de trabajo en un momento determinado.
Cuando hacemos una captura de la carpeta de nuestro proyecto, esa captura se almacena en el repositorio local (.git).
Stage
Otra zona que usa Git es stage. Se trata de una zona intermedia entre el working directory y el repositorio local.
stage significa escenario.
Git no realiza las capturas al repositorio local directamente. Primero debemos pasar los cambios a stage. La “foto” se hace a lo que haya en el stage. Esta forma de trabajar nos da la posibilidad de preparar el commit decidiendo “qué subimos al escenario para la foto”.
Los archivos que pasan de stage al repositorio local, se siguen manteniendo en el stage porque en sucesivos commits debe aparecer, salvo que en algún momento desaparezca de nuestro working directory.
Referencias: ramas, tags y HEAD
Una referencia es un puntero a un commit.
Hay 3 tipos de referencias en Git:
- HEAD
- Ramas
- Tags
Los commits se identifican por un nombre que es un hash de 40 caracteres. A la hora de verlos por pantalla, suelen mostrarse los 7 primeros.
HEAD
La referencia HEAD, que apunta a un commit, nos dice en qué commit estamos. Si estamos en el commit C4, el working directory reflejará cómo está en ese estado. Si queremos “viajar” a C2 (otro commit), HEAD apuntará a C2 y mi working directory se transformará para reflejar cómo estaba el proyecto en C2.
Cuando generamos un commit nuevo, HEAD avanza automáticamente al nuevo commit.
Ramas
Las ramas se guardan en el directorio .git/refs/heads. Es otra referencia que apunta a un commit.
HEAD puede apuntar a una rama. En este caso, si creamos commits, al avanzar HEAD, se lleva consigo la rama, es decir, avanzan las dos a la vez.
Si nos movemos a un commit anterior, fuera de la rama a la que apuntaba HEAD, git nos avisará con un mensaje de Detached HEAD para advertirnos.
git log --oneline --branches
Para movernos a cierto commit:
git checkout hash
Para volver a la rama “master”:
git checkout master
Tags
Las etiquetas (tags) son otro tipo de referencias que tendrán un texto que digamos. Las etiquetas no se mueven. Es una manera de etiquetar un commit. Se suelen utilizar para etiquetar las diferentes releases o liberaciones de código.
Para borrar una tag:
git tag -d NOMBRE_TAG
Hay 2 tipos de tags:
- Ligera: un texto que apunta a un commit.
- Anotada: además de un texto, requiere un mensaje.
git tag NOMBRE_TAG [commit]
Si no indicamos el commit, la tag se creará en el commit al que esté apuntando HEAD.
Para una etiqueta anotada:
git tag -a MOMBRE_TAG -m "Mensaje de la tag" [commit]
git show NOMBRE_ETIQUETA
En una etiqueta anotada, al ejecutar el comando anterior, veremos también el mensaje de la tag.
Ignorar archivos y carpetas
Para decirle a Git que ignore ciertos archivos y carpetas creamos un fichero llamado .gitignore.
Si queremos ignorar la carpeta js y todos los archivos .html, añadiremos a ese fichero:
js/ *.html
Git ignorará lo que le hayamos dicho recursivamente, es decir, no solo mirará en el directorio actual, sino en todos los hijos.
Esta posibilidad de ignorar ficheros se hace muy útil cuando estamos trabajando con otros desarrolladores y no queremos que se mezclen ficheros de configuración personales, por ejemplo.
Conclusión
Recursos
- Capítulo del libro Pro Git sobre etiquetas:
