Git tutorial – Nuestro primer proyecto

En este tutorial aprenderemos que es Git y para que nos va a servir a lo largo de nuestros proyectos como programadores.

Normalmente todas las empresas de desarrollo de software están utilizando algún gestor de control de versiones . Sea git o cualquier otra, aunque es la más común y es un requisito esencial que aprendas a utilizarla, tanto si te perfilas como empleado de alguna empresa, como si te ves futuro freelancer o emprendedor en el mundo del software!. Es por ello que considero que esta entrada es muy importante y marca de aquí en más un futuro también para futuras lecciones sea PyQt, Flask, etc. Si trabajamos con proyectos, es esencial aprendas Git.

Sobre este tutorial de git

Bueno por empezar quiero aclarar que Git es fácil de aprender. Pero algo confuso al comienzo, puede que te resulte un dolor de cabeza o no. Dependerá del tiempo que te tomes y la paciencia que estés dispuesto a sacrificar..

Mi idea es que salgas de aquí sabiendo lo básico para poder incorporarlo a tu vida diaria de programador, aún sea que estés aprendiendo todavía es un complemento que no debes dejar pasar.. Mejor aprender a programar mientras usas Git, que ser un gran programador que no sabe usar un software de control de versiones.. En fin, en esta primera parte aprenderás:

• Que es Git, obviamente.
• Cómo trabaja Git.
• Aprenderás a usar Git en tu proyecto.
• Aprenderás a crear Ramas y Commits a lo largo de ese proyecto.
• Aprenderás a moverte a través de las Ramas y commits y a eliminarlos/as.
• Aprenderás a alojar tu proyecto remotamente.
• Y a lo largo del post, vas a ir viendo los beneficios por ti mismo, no pienso ponerlos en una lista para chantajear de aprenderlo.

Luego de este tutorial de Git aprenderás a clonar proyectos de otras personas para trabajar en ellos (lo que normalmente se hace en empresas de software). Pero «primero lo primero», dijo el «mero mero». Aprende a trabajar un proyecto propio!

Sin más preámbulos, empecemos..

¿Qué es Git?

Git es un software de control de versiones (SVN) diseñado por Linus Tolvard (si, el de linux)

Como sabrás para desarrollar un sistema operativo como linux se dispone de miles de archivos de código fuente y una amplia comunidad de desarrolladores, lo que en gran medida dificulta llevar un «control» sobre los cambios en lo archivos y la coordinación entre varias personas modificando código todas a la vez.

Git es un Software cuyo propósito principal es llevar un registro de los cambios realizados en archivos de la computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos.

Utilizando este software podremos llevar un registro de los cambios de los archivos de un proyecto en el que estemos trabajando, independientemente el lenguaje y también nos permitirá trabajar junto a otras personas que quieran sumarse a nuestro proyecto. O nos permitirá sumarnos a trabajar en los proyectos de otros programadores de una manera muy sencilla.

Este software trabaja (podríamos decir para comprenderlo mejor) de dos maneras, en local y en remoto. Pero para comprender mejor esto debemos saber que es un repositorio. Puesto que lo Git hace en realidad es crearnos y administrar un repositorio local para trabajar o no en un repositorio remoto!

Aquí «estarás aprendiendo a utilizar un software de control de versiones para tus futuros proyectos a desarrollar«, claro, dilo de esa manera y aleja a todo el mundo de una vez!. Apaga las luces y vamos a ver el porno de los informáticos!

– ¿Qué es un repositorio de código?

Quienes utilizan linux están familiarizados con el concepto de «repositorio remoto«.

Un «repositorio de código» hace referencia a un lugar donde se almacena el código de una aplicación o programa y este es el caso de GitHub , donde podemos alojar archivos de código en un proyecto que es seguido mediante un Historial de modificaciones.

Si hablamos en términos menos específicos imaginemos que Git (el software de control de versiones) nos crea:

Un repositorio local con Archivos que incluyen código fuente de una aplicación + un registro de los cambios realizados. 

Que, al alojarlos remotamente (por ejemplo en GitHub) conforman un Repositorio remoto!

También, un repositorio de código en GitHub mediante Git puede permitir a varios desarrolladores realizar cambios o clonar el proyecto completo (archivos + historial de modificación)

Cada punto de este historial o registro donde se modifican lineas o se realizan cambios se llaman Commit’s. Y cada uno, es como una foto o instantánea de código que podría ser o no del mismo archivo a través de los cuales podemos movernos para ir viendo las modificaciones que realizaron hasta llegar a una versión final!. Como si se tratará de una linea de tiempo con hitos que nos permiten volver atrás o avanzar hacia adelante creando «checkpoints»

En resumen:

1. Git es un software de control de versiones que nos permite administrar «capturas» de código fuente (commits) de diversos archivos en un historial.
2. GitHub es un sistema de gestión de proyectos y control de versiones de código, así como una plataforma de red social diseñada para desarrolladores.

Y ojo que quede bien clara la diferencia!. Uno es un software (Git) y el otro es una plataforma tipo red social, donde podemos subir repositorios creados con (Git) para luego descargarlos y trabajar con ellos mediante Git.

Allí te dejo los enlaces para que los visites si deseas.

¿Cómo funciona Git al momento de administrar mi proyecto?

Entender el funcionamiento de Git normalmente es muy fácil, pero se vuelve confuso al momento de llevarle a la práctica. Para ello te explico con imágenes:

Primero; tanto al momento de crear nosotros un proyecto como de clonar uno tendremos 3 áreas de importancia que son parte del software Git:

• La carpeta o área de trabajo (Working Área)
• El área de ensayo (Stagin Área)
• Nuestro repositorio local («.git»)

Como decimos en mi país, un quilombo!. Pero tranquilo, ahora te explico bien!

El área de trabajo

Tu siempre que comienzas un proyecto obviamente vas a crear una carpeta para él. Me imagino no tendrás regados archivos por toda la pc. Pues esta carpeta que tu eliges o creas para los archivos de un proyecto es el área de trabajo, por ejemplo en mi caso («Mi proyecto Git»).

El área de ensayo (Stagin Área)

El área de ensayo es la que nos permite «seguir» los archivos que deseamos e implica una especie de historial donde podremos volver a atrás cualquier cambio realizado sobre un archivo. El área de ensayos es la forma de Git de seguir los archivos de tu proyecto y detectar cuando realizas una modificación. Este área es un intermedio entre el código que escribes, y la «confirmación posterior» llamada Commit.

Porque básicamente tu le dices a Git que siga los archivos y luego los abres con tu editor de código habitual (Geany, Atom, Sublime, etc) y te pones a trabajar, dando guardar como habitualmente lo haces en tu editor, Git detectará los cambios en los archivos. Cuando estás seguro de los cambios, luego de algún test puedes realizar una «captura del código» mediante un «commit» o simplemente volver atrás y eliminar los cambios.

Claro, pero ¿Qué carajos es el área de ensayo y que diablos es un commit?

Específicamente el área de ensayo es simplemente un historial de trabajo, algo así como un escritorio donde estamos trabajando y posteriormente a escribir código y realizar pruebas, decidimos sacarle una «foto o captura» lo que se llama Commit. Un commit representa un cambio y es identificado por una serie de números y caracteres llamado «Hash SHA-1«.

A su vez podemos imaginar nuestro proyecto como una linea de tiempo donde cada commit representa un hito que guarda una captura exacta del proyecto en ese momento y al que podemos volver para verlo, y continuar escribiendo código a partir de él. Cada commit es una potencial versión de tu software o proyecto a partir de la que tu o cualquier persona (si está alojado en remoto) puede continuar desarrollando!

Nuestro repositorio local («.git»)

Es una carpeta oculta que nos crea Git dentro de la carpeta del proyecto como puedes ver en la primer imagen. La existencia de esta carpeta «.git» dentro de una carpeta determina que la misma se trata de un repositorio o proyecto seguido con Git.

Allí se almacena el historial, y los datos necesarios como log’s y las posiciones del HEAD o Cabezal.

El head o cabezal es una referencia de donde nos encontramos posicionados en determinado momento, si nosotros avanzamos a lo largo de un proyecto normalmente se encontrará en el ultimo commit. Normalmente este HEAD está apuntando siempre al ultimo commit creado y es el que determinará en que versión de tu proyecto se encuentran los archivos.

Ejemplo del uso de Git para un proyecto básico en Local:

Si yo tengo dos commits, uno con la versión 1.0 de mi código del archivo Mayhem.py y en el otro commit tengo la versión 2.0 de Mayhem.py que posee unas mejoras buenísimas. Cuando mueva el HEAD al primer Commit, mi archivo «Mayhem.py» se verá como lo dejé al momento de la versión 1.0. Y cuando mueva el HEAD al último Commit mi archivo Mayhem.py se verá como la versión 2.0. Fíjate:

Había terminado de escribir la versión 2.0, pero quiero volver a ver el código de la versión 1.0 tal cual estaba:

Así que en la terminal escribo «git checkout <número de hash del primer commit>». (Tranquilo, solo ejemplifico el funcionamiento básico, aprenderás más adelante los comandos)

Ahora voy a ver cómo está la versión 2.0:

Así que en la terminal escribo «git checkout <número de hash del segundo commit>» .

Y a partir de aquí si quiero puedo seguir editando el archivo para crear la versión 3.0.

He creado dos versiones del mismo archivo, y me puedo mover a la 1.0 y Geany me muestra el código al momento de creada la 1.0. Luego me muevo a la 2.0 y me mostrará el código como lo dejé en la 2.0. Y si quiero vuelvo a la 1.0 y luego nuevamente a la 2.0 y el archivo es el mismo «Mayhem.py» pero tiene dos versiones diferentes. ¿Me entiendes?

Fíjate que cuando veo la 1.0 el HEAD está parado en el primer commit. Pero yo no puedo editar estos commits y guardarlos, así nomas.. Si yo quiero continuar a partir de una de estas dos versiones debo derivar en una nueva rama y/o en un nuevo commit. Porque el HEAD solo podrá escribir cambios que perduren hacia adelante, es decir, a partir del último commit hacia adelante.. 

YO NO PUEDO MODIFICAR EL PRIMER COMMIT (versión 1.0) Y GUARDARLO. Si ya está creado, está creado y punto. Para seguir editando a partir de ahí, hay que crear otro a partir de el.. Cada commit es un cambio confirmado, y solo se puede revertir o eliminar el último que se hizo.

En resumen:

Es bastante sencillo el funcionamiento para usar Git en nuestro proyecto:

1. Creamos una carpeta con archivos e iniciamos Git.
2. Los añadimos al Stagin área donde Git comienza a seguirlos.
3. Vamos escribiendo, guardando en el editor (lo de siempre) y «confirmando» los cambios creando capturas del código (commits) cuando queremos una versión nueva.

Lo que nos permitirá siempre volver en el tiempo hacia atrás para derivar de versiones antiguas o simplemente verlas, retomarlas, etc. Y la posibilidad de poder ver hacia atrás con seguridad, siempre nos dará la valentía para avanzar sin temor!

Diagrama cutre del funcionamiento de Git

Aquí te muestro superficialmente algunos comandos básicos y el funcionamiento de Git. En el primer área se encuentran tus archivos, vamos lo normal!, una carpeta con más carpetas dentro. Pero con la particularidad que dentro de la principal se encuentra una carpeta «.git» que la convierte en «repositorio«.

Al querer editar esos archivos con tu IDE debes añadirlos al Stage Área (área de ensayo) (flecha 1), simplemente desde la consola de git en windows o en la terminal en linux, le dices a git que siga los archivos que vas a editar, supongamos «test.py». Para añadirlo «git add test.py», significa que Git ahora registra cuando se hacen cambios en el archivo. Por tanto ahora ese archivo esta en el Área de ensayo (Stage Area)

Al registrar un cambio git nos da dos opciones que son las flechas (3 o 2) de la imagen, volver hacia atrás los cambios (2) o «confirmarlos y avanzar» (3). Si confirmamos y avanzamos se nos crea un «Commit» o «captura del código con un número de hash» (3). Caso contrario si volvemos atrás nuestro archivo se restaura tal cual estaba (2)..

A medida que creamos «Commits» y vamos avanzando en nuestro proyecto podremos crear ramificaciones, o volver hacia atrás PARA VER algún commit  o eliminar/revertir el último commit (4). También podremos movernos entre commits y nuestros archivos seguidos irán cambiando a como lo estaban en ese momento tal como te mostré con Mayhem.py más arriba!

¿Aún no entiendes Git?

Si aún no te queda claro, tranquilo lo hará cuando lo trabajes tu mismo en tu computador, solo trata de recordar los conceptos para ese momento!. La mejor manera de aprender Git es utilizándolo a menudo, así que a partir de esta guía cada vez que programes algo ponte en práctica con Git..

Las Ramas en Git

Sigamos con los conceptos sobre Git, estoy dándote primero una visión general de como funciona y luego procederemos a crear nuestro primer proyecto en local y a trabajar con el. Pero antes debes saber ¿Qué son las ramas en Git y para qué sirven?.

¿Habéis visto «grafos» alguna vez?. Pues los grafos son un conjunto de vértices o «nodos» unidos por «ramas» o aristas. Normalmente utilizados en la ciencia de la computación para definir la relación entre diferentes unidades que integran un sistema. Cualquier problema y solución puede ser representada a través de un grafo. Pero aquí justamente lo utilizaremos para hacernos un «mapa mental y/o gráfico» de como funciona Git y que nos será de utilidad para aprender esos conceptos que a la mayoría le suelen causar pesadillas.

La rama Master

Cuando trabajamos con un repositorio existe una rama principal normalmente llamada «Master». Esta rama es la rama central donde se avanza con el proyecto, así que podemos ver las ramas como lineas de tiempo donde sobre ellas existen «nodos» que son los «Commits». Cada commits representa una «captura de nuestro proyecto» y podremos crear ramas alternativas que deriven de la rama principal (master) o de otra rama que deriva a su vez de master. (Lo cual es una buena practica, para no cargarnos la rama principal de nuestro proyecto)

Por ejemplo, cada rama puede ser una funcionalidad de nuestro proyecto supongamos que tenemos la rama master y de ella derivan las ramas «chat» y «perfil». En cada rama tendremos commits sobre los que trabajamos estos aspectos. En la rama «chat» modificaremos código del chat y en la rama «perfil» modificaremos aspectos relacionados con un perfil de usuario..

Las ramas son como lineas de tiempo en nuestro proyecto, derivar en ramas permite realizar cambios sin aplicarlos directamente al proyecto original.

Claro que cada commit nuevo puede representar una nueva versión o una más actualizada que las anteriores independientemente de la rama en que se encuentre!

Un proyecto con varias ramas

Al trabajar con ramas normalmente un proyecto se divide en diferentes ramas de las cuales cada una tiene una utilidad en particular y de esa forma nos permite tener un proyecto organizado, para nosotros y para si en algún momento otro desarrollador se acopla a nuestro proyecto. Así podemos tener un proyecto por ejemplo dividido en 4 ramas. (Solo es un ejemplo)

• La rama Master
• La rama Desarrollo
• La rama Características
• La rama Fix

Así podemos dejar la rama «master» únicamente para las versiones finales.

En la rama desarrollo iremos unificando commits de lo que será una futura versión.

En características iremos agregando algunas nuevas características, nose por ejemplo «un chat».

Y usaremos la rama Fix para solucionar errores.

Vamos unificando las ramas en Desarrollo y finalmente cuando tenemos una versión lista, creamos un commit sobre master con esta nueva versión.

Trabajando de esta forma tenemos muchas ventajas, mantenibilidad del código, estamos organizados, no afectamos directamente a la rama master, etc.

Claro que cada círculo o «punto» que ves sobre las ramas es un Commit, y significa que hicimos cambios en el código fuente de nuestro proyecto. Esta práctica te permitirá por ejemplo modificar funcionalidades de tu aplicación sin que deje de ser funcional mientras lo haces, podrás incluso dividir tu proyecto en versiones estables, inestables o de prueba, etc.

Podemos tranquilamente ir creando ramas derivadas de master y al final unificarlas a todas en un solo commit para crear una versión. O aunque tengamos múltiples ramas de cada una de ellas podemos sacar una versión actualizada.

Puedes trabajar en múltiples ramas a la vez

Las ramas nos permiten trabajar en diferentes funcionalidades o bloques de código al mismo tiempo sin comprometer todo nuestro proyecto. A la vez que podemos solicitar que otros desarrolladores se acoplen a trabajar con nosotros, suponiendo que tienes un proyecto y tu quieres que otra persona trabaje en el entorno gráfico de tu aplicación. Pues creas una rama para ello y a medida que van realizando cambios los van unificando sobre otra rama (desarrollo por ejemplo). Así no comprometen todo el proyecto en caso de que halla un error. Si hubiera algún error en el desarrollo gráfico, no afectaría tu código sobre el desarrollo del código de la aplicación, por lo que solucionado el problema sobre la parte gráfica se pueden volver a unificar en un commit más adelante.

Además utilizando Git y organizando un proyecto de tu aplicación o software de esta manera te aseguras en un futuro que podrás ir incorporando a 200 desarrolladores más si crece o si quieres. Sin que sea todo un enredo de código que no les permita organizarse por ramas y funcionalidades a desarrollar cada uno.. ¿Se entienden las ventajas de trabajar con Git?

Bueno, vamos a crear un proyecto propio!. Adelante y sin miedo cabrón!. Que si te la pasas leyendo te me asustas, si lo llevas a la práctica verás que es muy sencillo 😛

Nuestro primer proyecto con Git

Vamos a crear un proyecto sencillo con Git en forma local para entender cómo funciona y los comandos básicos a utilizar. Para ello te sugiero que sigas mis pasos y trates de memorizar cada comando y para qué sirve. En cada comando dejaré un enlace con más información sobre el mismo en español (pero quiero que los leas luego de haber trabajado en tu primer proyecto, por ahora mantente volando bajo, no te generes una confusión enorme de comandos innecesarios). Y por cierto, también puede que sientas algunas nauseas trabajando en la consola, pero no te preocupes que existen aplicaciones gráficas para Git de forma que podrás trabajar de forma mas «intuitiva». Pero comienza aprendiendo los comandos con la consola y después te saltas al entorno gráfico, luego algún día me lo agradecerás!

Ha y no solo estarás aprendiendo comandos de Git a lo largo del proyecto, sino que estaré metiendo conceptos e información importante en tu cabeza como una máquina subliminal maligna.

Vamos a hacer un proyecto solo para aprender a usar Git, así que no voy a incluir ningún código ni lo más mínimo complicado porque quiero que incluso el novatillo que recién está aprendiendo a hacer un print pueda aprender a usar Git y no quiero que anden renegando que no les funciona algo en su código. A instalar Git cabrones!

Instalar Git en windows y linux

Es muy fácil de instalar, lo que si en Windows al momento de la instalación nos dará como 500 opciones a configurar. Puedes ir viendo una por una a que refiere o puedes dar «siguiente a todo» excepto en la parte que te pregunta si deseas integrar la shell.

Instalar Git en Linux

#Basados en Debian: sudo apt-get install git

#Opensuse: sudo zypper install git-core

#Fedora: sudo yum -y install git

#Arch/Manjaro: sudo pacman -S git

Como siempre varía según tu distribución. Pero una vez instalado vamos a corroborar su versión y a confirmar que se ha instalado correctamente:

git –version

Si todo ha ido bien obtendremos la versión de Git que tenemos instalada.

Instalar Git en Windows

Vamos a la página de Git:

https://git-scm.com/download/win

Y seleccionamos el instalador a descargar según nuestra arquitectura. Nada difícil!

Pero lo que si debemos tener en cuenta al momento de la instalación es la configuración. Puesto que nos hará algunas preguntas, todas ellas las recomiendo dejarlas como están excepto cuando nos pregunta si deseamos integrar el uso de Git desde la consola de Windows. En este caso yo recomiendo usar la consola de Git aparte.

Iniciar un proyecto con git

Habitualmente cuando nosotros vamos a crear un nuevo proyecto de programación lo primero es crear una carpeta en nuestro computador que contendrá los con los que vamos a trabajar. Pues hagamos eso y aprendamos a utilizar Git..

En mi caso tengo ambos sistemas operativos, tanto Linux como windows. Quienes me conocen saben que soy de Debian o Arch y habitualmente soy arisco y renegado de Microsoft. Pero voy a instalarlo también en windows para mostrar como abrir la consola de git. Luego los comandos de Git son los mismos!

Vamos al primer paso..

Crear una carpeta de trabajo

Vamos a crear una carpeta de trabajo, en mi caso lo haré en el escritorio. En este caso estoy en mi Debian 10 todo hacker..

Así que luego de crear nuestra carpeta vamos a ingresar a ella, «que esta tan vacía como su corazón» y vamos a crear o arrastrar algunos archivos sobre los que vamos a trabajar. Como este es un blog de Python voy a crear un archivo «.py» vacío para ejemplificar.. Para ello voy a ir a Geany que es mi IDE preferido.. Y en Archivo > Nuevo > Desde plantilla > Python creamos un nuevo archivo y lo guardamos en esta carpeta de nuestro proyecto.. Vamos, nada extraño, solo crea un jodido archivo.. No voy a enseñarte a prender la computadora también he!

Nos posicionamos en la carpeta de nuestro proyecto, que ahora ya tiene un archivo (en mi caso voy a llamarle «app.py»).

Así que tengo la carpeta «Mi proyecto Git» y dentro de ella cree el archivo «app.py«, casi vacío, solo tiene lo siguiente:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
#  app.py
# Proyecto para aprender Git

Ahora es momento de iniciar Git dentro de esta carpeta para convertirla en un repositorio. De lo contrario no podríamos trabajar con git, ¿Recuerdas que dentro de la carpeta debe haber otra carpeta oculta llamada «.git»?. Este será el primer comando que aprenderás!

Git init (inicializar git dentro de una carpeta de proyecto)

Antes de inicializar git en una carpeta debemos estar seguros de estar posicionados en ella y eso si depende de tu sistema operativo y la configuración de Git.

En el caso de windows lo más sencillo es posicionarnos en la carpeta de nuestro proyecto, es decir, abrir la carpeta donde vamos a trabajar con el navegador de archivos y dando clic derecho nos aparecerá en el menú :

Donde podremos abrir la consola de Git con la que trabajaremos!

En el caso de Linux simplemente podemos hacerlo desde la terminal, para ello debemos posicionarnos primero en la carpeta de nuestro proyecto normalmente utilizando los comandos de linux «cd y ls», podremos ir listando los archivos con «ls» y accediendo a las carpetas hasta llegar a la de nuestro proyecto con «cd». O bien abrir nuestro gestor de archivos y mediante un clic derecho «Abrir un terminal aquí» (dependerá tu Distro de linux y gestor de archivos)

Y a partir de aquí es igual en cualquier sistema operativo, para inicializar Git en una carpeta de tu proyecto debes usar el comando:

git init

# O bien si no quieres posicionarte en la carpeta puedes darle la dirección de la misma como argumento al comando

git init «directorio»

En linux para ver las carpetas ocultas simplemente presionamos «Ctrl + h» y deberíamos poder verla, en windows te dejo aquí: Como ver carpetas ocultas en Windows

El hecho de que exista una carpeta «.git» en un directorio implica que este será tratado por Git como repositorio local del tipo entorno de desarrollo.

Lo siguiente es conocer el estado de nuestro repositorio!

Git status (conocer el estado del directorio y el entorno de ensayo, etc.)

El comando «git status» nos mostrará en un principio el estado del directorio de trabajo, es decir, de donde estamos posicionados trabajando y también aquellos archivos que Git está siguiendo. Recuerdas que te dije que Git llevaba algo así como un historial o cache llamado Stagin Area donde los Commits eran los cambios realizados y marcaban un punto de referencia en cada cambio del archivo.

Pues el comando «git status» nos mostrará aquellos archivos que están en el Stagin Area, es decir, que están siendo seguidos en el área de ensayo.

git status

En un principio si hacemos un «git status» obtendremos algo así:

Allí Git nos indica que estamos sobre la rama «master» que es la principal de los proyectos, ¿recuerdas?. Y que además no hemos realizado ningún Commit todavía, por lo que no hay un punto de referencia al que volver. No hemos realizado cambios, pero lo más importante es que nos muestra un archivo en letra rojas.  Y nos avisa que estos archivos no están siendo seguidos. Así que vamos a seguirlo! Usando el comando «git add«.

Git add (Seguimiento de archivos)

En Git el proceso de guardar tiene muchos matices, lo que resulta diferente a el clásico «guardar» al que estamos acostumbrados. En git podemos verlo como «ir confirmando cambios a distintos niveles», al estar editando y guardando un archivo con nuestro editor de códigos habitual estaremos confirmando los cambios y el siguiente nivel de confirmación sera un commit lo que podríamos verlo como tomar una «captura» de el archivo, que posteriormente podría ser enviado o almacenados de forma local, algo diferente al clásico «Guardar» que sobrescribe un archivo, al estilo de los editores de código o texto.

Al utilizar el comando «git add» seguido del nombre de un archivo o bien utilizando un comodín «.» para todos los archivos del directorio, estamos ordenando a Git realizar un seguimiento del mismo. Lo que significa que nos avisará cuando se hagan cambios.

Cada vez que modifiques el archivo con tu editor de código y des «guardar..» en el mismo. Git detectará que el archivo ha cambiado.. Y haciendo otro «git status» lograrás verlo en rojo nuevamente..

Recordando que estamos en el área de ensayo, cada vez que modifiques el archivo y des a «guardar» puedes volver a hacer un «git add» para que nuevamente este en verde, eso significa que estás de acuerdo con los cambios superficiales. O bien si no lo estás puedes hacer un «git checkout — app.py» (o tu nombre del archivo) y volverá al estado anterior, osea al último guardado.

Ahora cuando estás seguro que has terminado de editar el código y lo has probado. Finalmente quizás quieras crear un commit para generar una «captura» de ese código que será una nueva versión también..

¿Has entendido?. Sino aquí tienes un diagrama completo (Horrible, pero te servirá):

Como para ejemplificar  a continuación añadiremos el archivo nuestro a seguimiento:

git add app.py

# o bien podemos usar comodín para añadir todos los archivos #que se encuentren en el directorio

git add .

Al hacerlo simplemente Git no nos mostrará nada, excepto que coloquemos mal el nombre del archivo. Pero al volver a solicitar un «estado» mediante «git status» veremos lo siguiente:

Bien la idea ahora como primera instancia es generar un commit con el archivo tal cual esta al inicio!. Así que vamos a hacer un commit y luego seguiremos editando:

Git commit (Guardar una instantánea de los archivos seguidos)

El commit significa haber confirmado un cambio, como si sacaras una captura del código y no solo eso sino que es también un punto de referencia, un «nodo» en una rama. Al que podremos volver o derivar de el otra rama para realizar otro «cambio» y poder luego movernos entre esos cambios. Así nuestro archivo irá cambiando como al momento de hacer el commit sin perder ningún cambio que haya sido confirmado mediante «commit«.

RECUERDA: Los commits también tienen un «hash» único que se suele denominar SHA-1 que los identifica y al que el HEAD o cabezal apunta.

También algo que olvide aclarar es que los commits van acompañados siempre de una especie de «mensaje» o «comentario de referencia» para que luego nosotros sepamos que es lo que modificamos en dicho commit. Normalmente para hacerlo más fácil yo uso el comando:

git commit -m «mensaje del commit»

# O bien puedes hacer:

git commit

# Pero tendrás que editar el mensaje con tu editor por defecto, por ejemplo vim o nano.. etc.

En el mensaje del commit siempre debes tratar de escribir lo relevante del cambio, no cometas el error de escribir tonterías o «commit 1, commit2» porque luego no sabrás que carajos modificaste allí hasta que veas todo el código. En este caso yo:

git commit -m «Estado inicial del archivo app.py»

En tu caso si no has configurado tu identidad en git podrías obtener algo como lo siguiente:

Y claro, el momento ha llegado.. Git no sabe quien carajos somos.. No hemos realizado una configuración antes de trabajar con el. Y necesita asociar un autor a dicho commit, de lo contrario si otra persona comenzará a trabajar con nuestro proyecto no podríamos diferenciar quien hizo los cambios. Así que haciendo caso a los comandos sugeridos vamos a revelarle nuestra identidad, para luego poder hacer el jodido commit en paz.

git config –global user.email «you@example.com»
git config –global user.name «Tu Nombre»

Se nos pide un email y un nombre para una configuración global, es decir, para cada repositorio local que nosotros creemos o utilicemos.

Una vez ingresado cada comando con tus datos, podrás realizar el commit!

Realizado el commit nos muestra la información del mismo. Fíjate que nos está diciendo que ha sido creado sobre la rama master. En este caso está bien, porque es el primer commit que marca un «punto inicial» de nuestro proyecto, algo así como una versión 1.0. (a27a67f)

Pero más adelante tal vez deberíamos crear una rama para realizar los cambios sin afectar la rama master.

Ahora vamos a ver si realizamos algunos cambios en el archivo y procedemos a crear otro commit, como podremos movernos entre ellos.. Venga, a escribir algún código tonto de ejemplo!

Escribí algunos comentarios en el archivo y añadí un simple «print». Luego di a «guardar» en Geany como se hace tradicionalmente.. Nada de otro mundo.. Pero..

Si volvemos a hacer un «git status» veremos otra vez el archivo «app.py« en rojo. Porque ha «cambiado» y no lo hemos seguido nuevamente.. lo que te comenté más arriba y te explique con un diagrama.

Así que hay cambios sin aplicar en el área de ensayo o Stagin Área..

Lo normal es hacer un «git add app.py» para confirmar los cambios ¿no?.

Pero y.. ¿Si quisiéramos saber cuales son los cambios?

Basta con recurrir al comando «git diff»

Git diff (comprobar diferencias)

El ejecutar este comando seguido del archivo podremos ver las diferencias antes de confirmar los cambios, volver hacia atrás, continuar siguiendo el archivo y/o crear un segundo commit.

git diff app.py

En mi caso lanza lo siguiente:

Porque añadí esas líneas al archivo app.py. Tu añade lo que quieras..

Si quisieras volver atrás en el tiempo y volver a tener el archivo como el ultimo commit haces:

«git checkout — app.py»

Como estamos seguros de añadir estas lineas a un segundo commit, vamos a volver a seguir el archivo con un «git add app.py» y a crear un segundo commit:

git commit -m «mensaje»

Bien, pos ya tenemos dos commits sobre master!. Podríamos imaginarlos algo así:

Git log (Registro, log, historial de los cambios)

El comando «git log» nos va a mostrar la lista de «commits» con su respectivo autor, fecha y horario y además el mensaje que hemos establecido para cada commit. De esta manera podremos tener una referencia de cada cambio que vallamos realizando. Normalmente el listado de «commits» aparecerá listado al revés, es decir los últimos aparecerán primero. En este caso como solo tenemos dos vamos a lograr diferenciar fácilmente todo esto..

Ahora vamos a aprender a movernos al primero. Obviamente cuando lo hagamos nuestro archivo «app.py» volverá a estar como al principio, pero.. No es de preocuparnos porque si nos movemos nuevamente al segundo commit estará tal y cual lo dejamos!. Ves el enorme beneficio que es utilizar Git!

Como ves el HEAD está sobre el último commit!

Git checkout (Revisar, cambiar de.., volver a..)

El comando «git checkout» hace referencia a revisar o cambiar entre diferentes versiones de una entidad objetivo. El comando checkout actuará sobre tres entidades distintas: archivos, confirmaciones (commits) y ramas (branch). Generalmente checkout es muy utilizado a menudo para el cambio de ramas en Git y se asemejan mucho al cambio de confirmaciones.

En el caso de haber modificado un archivo y no haber «commiteado» o creado un commit, si queremos volver al último y borrar los cambios de nuestro archivo en el Stagin Area podemos hacer:

git checkout —

#Por ejemplo:

git checkout –test.py

#Devolverá el archivo a como estaba en el último commit creado.

Git checkout para cambiarse de commit

Vamos a verlo en acción, nosotros queremos volver al primer commit, para ello primero tenemos que obtener el «Hash» de este commit. Lo que obtenemos utilizando el comando «git log«. O bien para ver una versión más resumida podemos hacer:

git log –oneline

Y nos lanzará los commits en una sola linea:

Bastante mejor y menos confuso sin duda. Ahora utilizaremos el checkout con el «hash» de referencia del primer commit para movernos a el.

En este caso un simple (tu copia exactamente el num de identificación «hash SHA-1» de tu primer commit):

git checkout a27a67f

Instantáneamente nuestro archivo volverá a como estaba al primer commit!

Fíjate el resultado:

Nuestro archivo ha vuelto a como estaba al primer commit!. Así nada más!. En algunos casos algunos editores como Geany en este momento te van a preguntar «El archivo ha cambiado, ¿quieres recargarlo?».

Y es normal, porque Git ha restaurado el archivo mientras nosotros lo teníamos abierto por lo que editor interpreta un cambio del archivo fuente. Es obvio que si estabas realizando cambios mientras te mueves a un commit diferente y no los has guardado tanto en el editor, como luego mediante un «git add» y un posterior Commit vas a perderlos! Si vas a moverte a otro commit sin guardar cambios, asumes que vas a perderlos.

 

Aviso antes de moverte a editar commits anteriores debes leer acerca del HEAD y el estado DETACHED HEAD. Porque puede que luego Git borre los cambios que hagas.. Hablamos de ello más adelante..

Git reflog (registro completo de referencia para el Head)

Como nos hemos movido a un commit anterior, es decir, a nuestro primer commit si hacemos un «git log –oneline» no aparecerá nuestro segundo (ultimo commit en este caso). Claro podría pasarte que cierres el terminal, vallas al baño a hacer lo segundo y al volver te digas «como diablos vuelvo al ultimo commit»..

Para ello podemos utilizar el comando «git reflog» o «git log –all»

Y veremos allí un log completo de donde podrás tomar el «hash» para ir a cualquier commit que desees usando «git checkout y el número de commit». Pero recuerda que no puedes modificarlos y ya, eso no funciona así!. Siempre deberás optar por crear un nuevo commit.

Crear una nueva rama

Bien, a partir de este primer commit en el que ahora estamos parados vamos a proceder a crear una rama, ¿te parece?

Para ello simplemente bastará con utilizar el comando:

git checkout -b nombredelaRama

Hay distintas formas de crear ramas, pero utilizo la más sencilla y practica, en este caso git reconoce que debe crear una rama debido al argumento (-b) correspondiente a «branch» con el nombre que tu le des allí y seguido a ello deberá moverse para posicionarse en esta nueva rama! En mi caso la voy a llamar «rama1»..

Automáticamente ha creado una nueva rama y se ha cambiado a ella. Eso debería significar que ya no estamos en la rama «Master«, ¿verdad?. Vamos a comprobarlo!!

Git branch (Gestión de ramas en git)

El comando «git branch» es el que nos permitirá trabajar con las ramas, movernos de una a la otra, crearlas, eliminarlas, etc. Ahora puede que se generen confusiones, la «rama1» que yo he creado deriva del primer commit porque en el estábamos parados, por lo que la estructura de nuestro proyecto se podría proyectar algo así:

Para comprobar sobre que rama estamos posicionados debemos utilizar el comando «git branch«:

Que como ves nos muestra que estamos posicionados sobre la rama «rama1» mediante un asterisco!

Ahora podemos editar nuestro archivo «test.py«, hacer un «git add» para seguirlo y crear un commit en esta rama!

En este caso al derivar la rama del primer commit nuestro archivo estará como al inicio, voy a añadirle otro print sencillo y procederemos a crear el tercer commit!

Seguimos el proceso como debemos, guardamos, hacemos un «git add app.py» y luego creamos el tercer commit:

Ahora hacemos un «git log –oneline» para corroborar que fue creado el tercer commit y veremos que sobre la rama1 nos aparece el primer commit y este último (ae33396) que es el tercero.

Ver Ramas y Commit en git de forma Gráfica

Si quieres ver de una forma gráfica usando la terminal puedes hacerlo usando el siguiente comando:

git log –all –decorate –oneline –graph

En mi caso:

Allí podemos ver la estructura de nuestro proyecto..

Puede resultar algo confuso, pero para ello podemos instalar programas del tipo GUI para Git como GitKraken o «Giggle» para linux. En giggle mi proyecto se ve así:

En este caso a la izquierda tenemos la rama master y a la derecha la rama «rama1». Yo personalmente uso Giggle y GitKraken. Seguramente vamos a utilizar GitKraKen..

Movernos entre commits en diferentes ramas.

Bien como sabemos tenemos dos ramas, la rama Master creada automáticamente por Git al iniciar un proyecto y la rama que nosotros hemos creado anteriormente llamada «rama1«. Imagina que a lo largo del avance de un proyecto real se irán creando muchas ramas y esto podría prestar a una confusión enorme, lo que nos acarrearía una perdida de tiempo si estamos extraviados en un mapa de ramas y commits enorme. Para ello se han creado programas o aplicaciones que simplifican las cosas. Hasta ahora hemos trabajado en consola la clásica «Cli» que te mencione anteriormente, por ahora seguiremos así para que aprendas los comandos pero más tarde pasaremos a trabajar con una aplicación gráfica como las que te mostré anteriormente. Así que no temas, que no será siempre tan complicado como aquí lo parece!

Ahora vamos a aprender a movernos a los 3 commits, empezando por el ultimo (donde estamos posicionados HEAD) hasta el primero y para movernos a un commit que esta en un rama diferente deberemos cambiar de rama PRIMERO, y por supuesto para ello debemos visualizar todas las ramas y commits que tiene nuestro proyecto. Pero, vamos a movernos para verlos, para ir viendo los cambios en nuestro archivo «test.py», no para «editar commits anteriores o viejos, eso no se debe hacer en lo posible, más abajo te explico»

En mi caso he terminado aquí y ha pasado un día, por lo que debo volver a ir con la consola hasta la carpeta donde estábamos trabajando, y lanzar un comando de git. No volver a hacer «git init» hee!

Posicionado en ella entonces inserto los siguientes comandos:

Para conocer las ramas de nuestro proyecto y saber en cual está posicionado el HEAD:

git branch

Fíjate en este caso me ha devuelto que el HEAD esta desacoplado en el último commit. Lo que significa que estamos en un modo DETACHED HEAD y los cambios que hagamos no van a guardarse  definitivamente porque nuestro HEAD no está apuntando al Hash SHA1 de nuestro último commit. Para solucionarlo podemos hacer un checkout y posarnos en una rama, sea master o cualquier otra como lo hago en el ejemplo de la imagen.

Hacemos un «git log –oneline» y veremos que el HEAD está en nuestro ultimo commit sobre la rama «rama1«. Supongamos que queremos movernos al segundo commit que está sobre la rama «master«. Este no aparecerá en el «git log –oneline». Para ver el Hash de ese commit debemos hacer un log completo:

Puede ser «git log –all» y obtendremos lo siguiente:

Allí tenemos, el último commit donde se posiciona el HEAD sobre «rama1», el segundo sobre master y el primero que representa el estado inicial del archivo. Si deseamos movernos al segundo que está sobre master basta con hacer un checkout indicando el hash del commit:

Y nuestro archivo «app.py» estará tal y como lo capturamos en ese segundo commit!!

Así podemos movernos por ramas y commits tanto como queramos, pero como vemos nuestro HEAD entra en DETACHED MODE. 

El estado DETACHED HEAD

Si te fijas me ha salido un aviso que menciona el estado de lo que podríamos llamar cabeza o puntero (HEAD) que indica que está en modo DETACHED!. Esto normalmente pasa cuando te cambias de rama o volviendo de commit en commit.

Ojo, ojito, oje.. esto:

Significa que podemos hacer cambios y modificaciones sobre el código del momento en el que nos hemos situado y hacer los commits que necesitemos, pero si queremos que esos cambios se mantengan en Git y no sean eliminados por el proceso git garbage collection process (recolección de basura) tendremos que crear una nueva rama del último commit que hemos realizado.

Git nos avisará de esta situación si cambiamos a otra rama para evitar que perdamos las modificaciones realizadas.

Para ello es recomendable si deseamos «modificar un commit anterior y que los datos permanezcan» derivar en una nueva rama a partir de nuestro último commit y crear un nuevo «commit».

Porque verás si ya tienes un commit anterior y lo editas es como si estuviéramos modificando el pasado «de una mala manera», porque podrías borrar algo importante del código, cuando la idea de Git es ir creando nuevos commits, no modificando los anteriores que luego podríamos necesitar como referencia de alguna linea importante. Para mi volver hacia atrás y modificar commits anteriores es como «viajar al pasado y matar a tus padres» ¿Quien haría eso si pudiera?.

Ve hacia adelante!, no le temas al futuro! Que tienes una buena base a la que volver cuando te equivoques! Y si te equivocaste antes, crea un nexo al futuro a partir de ese error. Corrijelo pero en el futuro, no te la pases modificando commits  anteriores porque lo echarás a perder!

Cuando alguien hace commits es porque esta «casi seguro al menos» de que el código está bien.. Para ello tienes el Área de ensayo donde haces las pruebas, cada commits es un paso hacia adelante!

Entonces si te paras en un commit anterior y deseas editarlo, vas a primeramente añadir el archivo al Stagin Área nuevamente, haces los cambios, creas una nueva rama y haces un commit nuevo.

Normalmente también si haces un «git log –oneline» y te muestra el HEAD desacoplado en commit es que no está apuntando a ningún lado. Normalmente el HEAD debe apuntar al SHA-1 del último commit creado..

En estos casos puedes hacer un «git checkout «rama o último commit».

Para volver a posicionarlo apuntando al hash del último commit

Borrar o eliminar commits

Bien, puede que nos hayamos equivocado en un commit. La diferencia siempre estará en si el commit en el que hemos cometido un error de código es el último o es un commit antiguo. En el caso de que sea el último commit existen algunos comandos que nos pueden ayudar reset y revert.

Como aquí solo estamos trabajando en un proyecto nuestro y local suponemos que los commits no son subidos a un repositorio remoto. Eso lo veremos en la siguiente entrada o post sobre Git.

Git reset HEAD

Usando este comando tendremos dos opciones «–hard» y «–soft«.

Debemos primero saber en que commit estamos parados, o mejor dicho donde esta apuntando el HEAD. Para ello basta con un simple «git log –oneline»

Luego entonces, ingresamos el comando:

git reset –hard HEAD~1

–head: Con esta opción estamos indicando que retrocedemos a el comit HEAD~1 y perdemos todas las confirmaciones posteriores. HEAD~1 es un atajo para apuntar al commit anterior al que nos encontramos. CUIDADO, con la opción –head, ya que como he dicho se borran todos los commits posteriores al commit al que indicamos.

Si estamos apuntando a un commit entre medio de otros supongamos al commit 2 de 3 y ejecutamos este comando nuestro commit 2 se va a eliminar y quedaremos en el commit 1 pero también habrá de borrarse el commit 3. No es ideal borrar commits con este comando, excepto sea el último!

–soft: con esta opción estamos indicando que retrocedemos a el commit HEAD~1 y no perdemos los cambios de los commits posteriores. Todos los cambios aparecerán como pendientes para realizar un commit.

Así que utilizando este comando si estamos parados en el commit 2 de 3 y lo borramos el HEAD va a posicionarse en el commit 1 pero no habrá de borrar el commit 3 que es el último. Para mi antes de borrar este commit erróneo es mejor crear una rama derivando del commit 1 y allí subir el que queramos sea el commit 2 sin errores. Luego entonces si, procedemos a borrar el commit 2 erroneo.

Lo mejor es no borrar los commits, simplemente editar el mensaje e indicar que es erróneo, crear una rama a partir de ellos y en ella subir el commit correcto.

Borrar o eliminar ramas

Eliminar una rama es muy sencillo, pero debes pensar si esa rama no fue «Fusionada» con otra. Si no lo fue podrías perder los cambios que realizaste en ella. Para conocer las ramas que tienen commits o cambios sin fusionar:

git branch –no-merged

En mi ejemplo:

Tampoco podremos eliminar una rama si estamos parados en ella.. Para ello debemos cambiar de rama como vimos anteriormente usando «git checkout nombredeotrarama». Y entonces si se nos permitirá eliminarla con el siguiente comando!

git branch -d nombredelarama

#O en caso de que sea una rama no fusionada deberemos forzarlo colocando el argumento «-D» en mayúsculas (delete):

git branch -D nombredelarama

Ramificación y fusionado de ramas en Git

Hablamos anteriormente de las ramas y dijimos que siempre es mejor ir ramificando nuestro proyecto, sobre todo para evitar trabajar directamente sobre la rama «master». Así podemos tener diversas ramas para cada aspecto a modificar o bien podemos ir creando ramas en el momento de trabajar con una característica o fixear algún bug o error del código. Pero finalmente luego de terminar de agregar una característica o fixear un bug puede que queramos «fusionar» esa rama con «master» o con alguna otra en un mismo commit!

Sin duda las ramificaciones muchas veces nos causan una enorme confusión. Se que al ver commits y ramas por todos lados como en la imagen no vas a comprender muy fácilmente. Pero para ello simplemente basta con incorporar git a tu uso diario al momento de programar y verás que sencillo se te irá haciendo.

Vamos a continuar con nuestro proyecto creando algunas ramas para trabajar sobre ellas e ir creando commits. Luego vamos a fusionarlas en un commit sobre master para tener una versión final de nuestro «proyecto» , que como sabes, serán puros print’s. No quiero que quien este leyendo se concentre demasiado en el código en vez de en Git.

Para esto será mejor que utilicemos algún entorno gráfico de Git, en mi caso para este tutorial utilizaré GitKraKen. Es un excelente Gui para trabajar con Git, pero no nos permite múltiples cuentas, ya sabes tiene una versión gratuita y una de pago.

Si quieres aprender a utilizar GitKraken sigue a la siguiente entrada -> Utilizar GitKraken

Esto ha sido todo por ahora y nos vemos en la siguiente entrada!!