portada

Versionado de Ideas con GIT PT 01

!Hola Geeks¡

 

Algo tardío, pero aquí venimos compartiendo más conocimiento (todo esto para ustedes nuestros preferidos Geeks C: ), ahora, como lo vimos en el memorable #DíaByte el contenido expuesto fue: “Control de Versiones con GIT”.

 

Nos preguntaremos, ¿para que nos sirve GIT?, bueno….., regresando a una definición antes de GIT, en todo desarrollo de una aplicación es necesario un Control de Versiones, y…,  ¿qué es Control de Versiones?, en resumen, es el sistema  que registra los cambios realizados a un documento a través del tiempo para posteriormente poder recuperar una versión pasada ( !Genial¡ 😀 ), bueno, esto se puede realizar por medio de varias aplicaciones que cumplen con mencionado propósito, menciono algunas: TFS (Team Fundation Server), Torsoise, CVS, entre otras, y entre los más populares GIT.

 

Respondiendo para que nos sirve GIT, imaginemos una linea de tiempo, donde vamos a realizar una página web a un cliente, empezando (izquierda a derecha ) tenemos las versiones de nuestro código  que aumentará en forma lineal a la derecha por los “breakpoint” que queremos hacer (comúnmente llamados Versiones 🙂 ).

 

Empezando con la V1, tenemos los recursos necesarios para empezar la Página Web (Jquery, Angular, Imágenes, logotipos, fuentes ….) y un pequeño prototipo (todo esto está en una carpeta en la dirección C:\V1), el segundo segundo cambio a realizar la página responsiva, para poder adaptar la página web en una vista desde celular  u otro dispositivo (un “must” de toda página web), la cual llamaremos V2, recordando la carpeta que tiene “V1” ahora la llamaremos V2 (carpeta nueva); pasando el tiempo registramos un cambio mayor  y hacemos otra carpeta en C:\XX llamada V3 (esto por que no queremos que lo realizado antes se perjudique con algún misterioso Bug que salga por ahí en lo que estamos mejorando la página), después de la 4° versión de varias mejoras y muchos cambios y pensando que ya estamos en la etapa final del proyecto, pero el cliente sale con muchos más requerimientos (muy común), y por eso empezamos con las carpetas Final, Versión final, Ahorita si la final, Final final y un sin  fin de versiones más que al paso del tiempo no sabemos la diferencia una con otra, quizá si, pero no con exactitud.

 

linea

 

GIT ayuda a gestionar esos cambios a través del tiempo de una manera muy sencilla, ahora les muestro.

Dependiendo del tipo de proyecto sea colaborativo o individual, existen 2 tipos de control de versiones: Centralizado y Local.

 

Local

Si solo queremos hacer el versionado de manera local sin subirlo remotamente a algún gestor de repositorios.
local

 

Centralizado

Si hay más de una persona incluida en el desarrollo en la cual por cada persona le toca un módulo del sistema/página o aplicación a desarrollar usando un gestor de repositorios remoto.

 

centralizado

 

Estos cambios están siendo guardados en repositorios locales o remotos dependiendo de la forma de trabajar deseada (individual  o colaborativa).

 

Actualmente para la mayoría de proyectos (que son de más de una persona), se usa un administrador de repositorios remotos llamado GITLAB, donde almacena los cambios que cada persona va realizando en el proyecto y que a través del administrador de repositorio pueden volverse a recuperar versiones pasadas.

 

 

repo

 

Ahora bien, ¿cómo se administran estos cambios?, bien, dentro del sistema de control de versiones GIT existen ramas “branches” que representa una línea de desarrollo, que es la cabecera donde has realizado los cambios a lo largo del tiempo, definidos como “commits”.

 

Estas ramas o “branch” las denominados regularmente como ambientes de trabajo, ejemplo, la rama master (rama de producción) donde estará la versión en productivo de nuestra aplicación ( la que no se debe de tocar 🙂 ), rama developer, regularmente donde tenemos una copia de lo que está en nuestra rama de productivo (master) y donde podemos hacer el Quality Assurance  (QA) o aseguramiento de calidad de la aplicación y la ramas features, que se usan comúnmente con GITFlow (habrà post de esto más adelante) para  realizar cambios o mejoras de la aplicación.

 

 

rama

 

Ahora bien el flujo básico para entender git se basa en lo siguiente:
flujo

 

 

Tenemos un directorio de trabajo, donde básicamente es donde estamos trabajando (carpeta donde se empezó el proyecto), seguido tenemos un área de “staging” donde git se encarga de llevar el track de lo que se se le ha realizado a cada archivo o un set de los mismos, en este caso GIT analizará si es un archivo nuevo, si se le agregaron líneas, quitaron  y otras modificaciones que indican si el archivo original ha sufrido algún cambio desde su estado inicial y por último tenemos el área “HEAD” o cabecera, ésta guarda todos los commits que ya fueron confirmados por uno por ejemplo “Se agregó el sidebar”, “se agregó el menú”, “se realizó el responsivo de la página” y que para cada nombre dado corresponden varios archivos que fueron modificados para llegar a alcanzar dicho objetivo.

 

Dentro de los comandos que se usarán en la práctica y llevarlos hasta el administrador de repositorios remoto GITLAB están los siguientes:
flujo

 

En el siguiente post veremos como usar el Control de Versiones GIT desde la consola de comandos y la herramienta GitKraken. Estate al pendiente 😀

Comments

comments

Leave a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *