Curso Git: 01 - Iniciar un seguimiento, commit y ramas en local

Hola buenas tardes, esto tiene complicación por la cantidad de palabras nuevas que solo existen en inglés y al traducirlas son bastante incómodas de entender, asi que lo mas conveniente es comprender como funciona Git y su vocabulario sin más, sobre todo aprender sobre la marcha, la mayor parte de git no está creado para el uso diario, si no como respuesta a problemas muy específicos que deben tener soluciones excepcionales, casi nunca se necesita una rama cuando se utilizan repositorios locales, aun así es conveniente saber como utilizar ramas en local, principalmente para evitar que surjan problemas al trabajar en remoto, especialmente con equipos de desarrollo de por medio, lo primero es instalar git.

El gestor oficial lo podemos encontrar en este enlace, viene empaquetado para varios sistemas operativos, algunas veces las suit de programacion como visual studio nos instalan git automaticamente o lo hacen al tocar un check, si alguien tiene dudas, podemos tener garantía de la instalación de git con el comando version:

> git --version

 

Si el resultado es distinto a "No se reconoce el comando", sabemos que existe una version de git ya instalada, si vamos desde la consola a cualquier carpeta con archivos existentes podemos iniciar un repositorio de git con el comando init:

> git init

Esto tendrá como resultado la creación de esta "base de datos" que utiliza para llevar el seguimiento de versiones, archivos, ramas locales y cosas de configuración que se salen de esta entrada. Para saber el estado actual del repositorio basta con el comando status, por que todo debe tener sentido logico y debería ser bastante obvio.

> git status

 

Aqui tenemos algo que no es tan obvio, los archivos no se les da seguimiento automático, lo mencioné pero igual lo repito, hay que añadir el archivo cada vez que se le haga un cambio, todas las veces, añadir un archivo al seguimiento no implica que esté respaldado, simplemente es el paso previo a realizar un respaldo, entre respaldos no hay nada seguro, simplemente un archivo esta en pila de seguimiento o no, añadimos todos los archivos utilizando add y un asterisco, podríamos añadir independientemente cada archivo, pero lo normal es colocar solo los archivos a seguir en una carpeta y sub carpetas para darle seguimiento al lote completo:

> git add *

 

Una vez añadido todo a nuestra pila de seguimiento, podemos ver que el estado del repositorio ha cambiado: 

 

 

 Por ultimo confirmamos el respaldo, recordemos que esto es solo la pila de seguimiento, si alteramos el archivo antes de confirmarlo, no podremos volverlo a un estado anterior, ya que no está confirmada nuestra pila de seguimiento y por tanto no tenemos un historial de cambios con el cual comparar o al cual regresar:

> git commit -m "Esto es el primer commit de nuestro repositorio"

 

El procedimiento de confirmar los cambios pasa por crear un hash de los archivos existentes, estoy seguro que no es tan fácil recordar 29ad2f0, pero este código es el que utilizaremos bajo condiciones normales para volver a un estado anterior, también podemos crear nuestras propias etiquetas o utilizar las que el propio git utiliza, por ejemplo, estamos utilizando la rama por defecto llamada master, esta rama si la movemos hacia atrás, tendremos una regresión de nuestros cambios, equivalente a restaurar el código que estamos utilizando, nuestro cursor se llama HEAD, donde estemos trabajando estará HEAD, pero todo esto no es tan interesante hasta que hagamos nuestra primera rama, que significa dejar el master como está y movernos hacia una nueva rama.

Añadir un comentario es importante, aunque podríamos enviar un commit sin comentarios o con el comentario en blanco, es una buena practica señalar exactamente que se ha modificado en el archivo y la razón del cambio si lo vemos necesario, mas información implica mayor facilidad para movernos entre cambios, haciendo el commit con un comentario podríamos hacer pruebas con regresión, esto es probar si el código antiguo funciona mejor o peor que el nuevo, no siempre se hace, pero siempre es interesante ver como nuestros proyectos evolucionan y si estamos haciendo un mejor o peor trabajo.

Creamos nuestra nueva rama(branch), para evitar que el master sufra cualquier cambio, se llamará desarrollo, por que la utilizaremos para hacer cosas :3

> git branch desarrollo

Ahora existe una nueva rama(branch) llamada desarrollo y nosotros estamos en una rama llamada master, recordemos que nosotros somos head y mas comúnmente veremos sobre el nombre de la rama un asterisco que identifica donde está head, podemos ver en cual rama estamos con el comando --list

> git branch --list

Revisamos otras ramas con el comando git checkout, que nos sirve para mover HEAD a esa rama, podemos usar el comando git log para ver el registro de nuestro repositorio.

 

Ahora bien, vamos a modificar nuestro archivo, esto da igual, es lo que vamos a hacer con frecuencia, el punto importante es repetir el procedimiento:

> git status

> git add *

> git commit -m "actualizacion en desarrollo"

Ahora si dibujáramos esto, tendríamos una rama master que es nuestra base, una rama desarrollo que tiene dos commit, por tanto está por delante del master, si creemos que esta característica añadida es correcta y todo esta bien, podemos tener el atrevimiento de mover el contenido de la rama desarrollo hacia la rama master, primero nos vamos con git checkout master, una vez ahí, git merge desarrollo, por que vamos a tomar lo que hay en desarrollo e incorporarlo hacia la rama master, si nadie ha tocado master no hay posibilidad de que ocurran errores, si los hubiera, habrá que ir a mano solucionando cada uno, para ello existe diff que se activa sola en cuanto hay conflictos:

> git checkout master

> git merge desarrollo

Ahora sabemos como añadir archivos, hacer confirmaciones, crear ramas y fusionar ramas locales, en la próxima entrada vamos a hacer exactamente lo mismo pero con proyectos remotos, a ver cual de mis proyectos existentes voy a destrozar :3