Git
Conceptos básicos
Un sistema de control de versiones como Git nos ayuda a guardar el historial de
cambios y crecimiento de los archivos de nuestro proyecto.
En realidad, los cambios y diferencias entre las versiones de nuestros proyectos pueden
tener similitudes, algunas veces los cambios pueden ser solo una palabra o una parte
específica de un archivo específico. Git está optimizado para guardar todos estos cambios
de forma atómica e incremental, o sea, aplicando cambios sobre los últimos cambios, estos
sobre los cambios anteriores y así hasta el inicio de nuestro proyecto.
● El comando para iniciar nuestro repositorio, o sea, indicarle a Git que queremos usar
su sistema de control de versiones en nuestro proyecto, es git init.
● El comando para que nuestro repositorio sepa de la existencia de un archivo o sus
últimos cambios
● es git add. Este comando no almacena las actualizaciones de forma definitiva, solo
las guarda en algo que conocemos como “Staging Area”
● El comando para almacenar definitivamente todos los cambios que por ahora viven
en el staging area es git commit. También podemos guardar un mensaje para
recordar muy bien qué cambios hicimos en este commit con el argumento -m
"Mensaje del commit".
● Por último, si queremos mandar nuestros commits a un servidor remoto, un lugar
donde todos podamos conectar nuestros proyectos, usamos el comando git push.
Las áreas de git
Git trabaja en distintas áreas para llevar a cabo sus funciones. La primera es el
working directory o working area, que es el área donde se está trabajando, es decir la
carpeta donde se inicializó el repositorio. Todos los archivos y carpetas que estén dentro de
esta pertenecen al working directory aunque esto no significa que estén siendo
“trackeados”. Para que un archivo este “trackeado” debe estar en la staging area. Para
mover archivos o carpetas del working directory al staging area utilizamos el comando git
add.
Git está pendiente de los cambios y modificaciones que se hacen sobre los archivos
que se encuentran en la staging area, pero esos cambios se deben guardar en el
localrepo(repositorio local). El comando que utilizamos para guardar esos cambios es git
commit -m “mensaje”, que es lo que nos permite mover los cambios del staging area al
localrepo. A modo de buena práctica, el mensaje del commit debe describir los cambios que
se realizaron en el código.
Si bien el área Local y el área Remota no están en el mismo espacio físico en
general se necesitan la una a la otra. El remote repo no es más que un almacenamiento en
la nube del repositorio local, aunque no es estrictamente necesario usar un repositorio
remoto debido a que git es una herramienta que funciona de manera local. Pero cuando se
está utilizando el repositorio local, el punto de referencia que utiliza git va a ser el último
commit que se subió al repositorio local.
Rama o Branch
Git funciona con un sistema de ramas. Al realizar el primer commit que se hace,
automáticamente se crea la rama “Master”, que será la rama principal del repositorio y
donde se alojarán los cambios permanentes y definitivos del proyecto que se esté
desarrollando.
Con el comando git branch <branchName> se puede crear una nueva rama. En git
una rama es un nuevo espacio de trabajo que está separado de la rama principal del
repositorio(Master o main) y esta contiene todos los commits que se hicieron en la rama
master hasta el momento de la creación de la rama. No existe un límite en la cantidad de
ramas se pueden crear en git.
Las ramas que creamos se separan de la rama principal, por lo que los commits que
se hagan a la rama master no se verán reflejados en las ramas ya existentes. Para poder
manejar las ramas git utiliza un puntero llamado HEAD. Por defecto el puntero de nuestro
repositorio apunta a la rama principal y al último commit realizado, para cambiar la rama a la
que apunta utilizamos el comando git checkout <branchName>. También podemos crear
una rama y apuntar el puntero a dicha rama con el comando git checkout -b
<branchName>.
Nota: El comando git branch se pueden listar todas las ramas del repositorio y con git
branch -v muestra un listado de las ramas con el último commit realizado en cada una.
Fetch, Pull y Merge
Es muy común que cuando se trabaja en equipo cada uno trabaje en una tarea o en
un área del proyecto diferente y en simultáneo, por lo que se suele dar que algunas ramas
contengan partes del proyecto que otro programador necesita para seguir con sus tareas.
Como las ramas existen de forma paralela las unas de las otras, existen formas de fusionar
las ramas para que todos los cambios que se hicieron converjan en la rama principal o bien
traer los cambios de una rama específica a la rama en la que se está trabajando.
El comando git fetch descarga los cambios de un repositorio remoto a un repositorio
local.
● git fetch <repositorioRemoto>: Trae todos los cambios de todas las ramas del
repositorio.
● git fetch <repositorioRemoto> <rama>: Trae todos los cambios de una rama.
Al ejecutar este comando, git trae los cambios del repositorio remoto pero lo aísla de
lo que está pasando en el repositorio local. De esta manera se pueden ver los cambios
antes de que sean integrados en el repositorio local con el comando git checkout.
Una vez obtenemos los cambios, debemos fusionarlos con el repositorio local para
que se hagan efectivos. Para esto usamos el comando git merge para fusionar ramas.
Fusionar se refiere a “actualizar” la rama principal(aunque funciona con cualquier rama) con
los cambios que se realizaron en otra rama, es decir, que todo lo que se hizo en una rama X
pase a estar en la rama principal.
Por ejemplo, en esta situacion, se ha programado una feature del programa pero
esta en una rama que no es la principal.
Para que estas se unan y todo lo programado en la rama Feature pase a estar en la
rama Main, primero debemos mover el puntero a la rama main y luego ejecutar git merge
<ramaDestino> <ramaOrigen>. Donde la ramaDestino es la rama donde se fusionaran los
cambios y la ramaOrigen es la rama donde están los cambios que se quieren fusionar.
Luego del merge, nos encontramos en la siguiente situación, donde se han unido las dos
ramas.
El comando git pull combina los comandos mencionados anteriormente. En primera
instancia ejecuta un git fetch sobre la rama a la que está apuntando HEAD, una vez se traen
los cambios se ejecuta git merge, se hace un nuevo commit y se apunta HEAD al nuevo
commit.
En el caso de este ejemplo se puede ver que la rama main del repositorio local y del
repositorio remoto se separaron. Esto sucede cuando otra persona subio cambios a la rama
main del repositorio remoto y nosotros todavía no lo hemos hecho o no actualizamos
nuestro repositorio. En este caso git pull traerá todos los cambios desde el punto en el que
se separan las ramas y durante el proceso de merge cuando se fusionan las ramas se
creará un nuevo commit H en el repositorio local.
En el ejemplo podemos ver el commit H que tiene todos los cambios hechos en el
código de los commits A, B, C, E, F y G fusionados.
Nótese que todo lo hablado hasta ahora en esta sección se refiere al repositorio
local.
