Tras haber empezado nuestro repositorio usando git init en la clase anterior, vamos a empezar a ver los conceptos básico para saber como funciona GIT.
Ya tenemos creada la carpeta .git dentro de la carpeta donde corrimos git init, en esta carpeta .git se guardará la base de datos con cambios atómicos de nuestro proyecto y además, crea una área que conocemos como Staging, donde guardará temporalmente nuestros archivos.
Ciclo de vida de los archivos en Git
Trabajando con Git, nuestros archivos pueden estar en 4 diferentes estados (pueden ser más, ya lo iremos viendo)
- Archivos Tracked: son los archivos que viven dentro de Git, no tienen cambios pendientes y sus últimas actualizaciones han sido guardadas en el repositorio gracias a los comandos
git add
ygit commit
. - Archivos Staged: Viven dentro de Git y hay registro de ellos porque han sido afectados por el comando
git add
. Git ya sabe de la existencia de estos últimos cambios, pero todavía no han sido guardados definitivamente en el repositorio porque falta ejecutar el comandogit commit
. - Archivos Unstaged: Archivos “Tracked pero Unstaged”. Son archivos que viven dentro de Git pero no han sido afectados por el comando
git add
. Git tiene un registro de estos archivos, pero está desactualizado, sus últimas versiones solo están guardadas en el disco duro. - Archivos Untracked: son archivos que NO viven dentro de Git, solo en el disco duro. Nunca han sido afectados por
git add
, así que Git no tiene registros de su existencia.
¿Qué es una rama?
Los commits son la única forma de tener un registro de los cambios. Pero las ramas amplifican mucho más el potencial de Git.
Todos los commits se aplican sobre una rama. Por defecto, empezamos trabajando sobre la rama master y creamos nuevas ramas, a partir de esta, para crear flujos de trabajo independientes.
Crear una nueva rama se trata de copiar un commit de una rama, pasarlo a otra rama y continuar el trabajo desde ahí en esa parte de nuestro proyecto sin afectar el flujo de trabajo principal (que continúa en la rama master o la rama principal).
Los equipos de desarrollo tienen un estándar: Todo lo que esté en la rama master va a producción, las nuevas features, características y experimentos van en una rama “development” (para unirse a master cuando estén definitivamente listas) y los issues o errores se solucionan en una rama “hotfix” para unirse a master tan pronto como sea posible.
Crear una nueva rama lo conocemos como Checkout. Unir dos ramas lo conocemos como Merge.