Mira cómo usar git y aplicar el control de versiones a sus proyectos.Estoy en un proyecto para un pequeño mercado y ahora estoy desarrollando una página web en HTML para listar todos los productos del mercado. Al principio obtuve el siguiente resultado:Al mostrarle al cliente esta primera versión, dijo lo siguiente:
"Es genial, sin embargo, sería mejor si al pulsar en un producto, apareciera una descripción y una cantidad".
Según la necesidad del cliente, hice algunos ajustes en la página que enumera todos los productos, mira cómo se ve:
"¡Está sirviendo muy bien para lo que necesito! Sin embargo, todavía es difícil saber qué es el producto con solo leerlo ... En otras palabras, quiero que también agregue una imagen del producto dentro de esta casilla de descripción y cantidad.
Teniendo en cuenta esta nueva necesidad del cliente, hice los ajustes y obtuve este resultado:
Se lo mostré nuevamente al cliente, y él respondió lo siguiente:
"Quedó genial la lista de productos con descripción, imagen y cantidad. Pero empecé a darme cuenta de que tiende a quedar con demasiada información visual, es decir, es mejor dejar la lista como estaba desde la primera vez que me mostraste, luego crea una nueva página que contiene la información del producto: imagen, descripción y cantidad ... "
Ten en cuenta que desde el inicio del proyecto,estamos sujetos a cambios constantes. Por lo tanto, incluso si le entregamos la feature a nuestro cliente de la manera que solicita, todavía existe el riesgo de que quiera algo más.Además, ten en cuenta que también corremos el riesgo de que nuestro cliente simplemente nos diga que quería el proyecto como estaba antes, algo que hicimos hace mucho tiempo y que, dependiendo de la cantidad de cambios, es muy difícil revertir...
Pensando en todos estos detalles, ¿qué podemos hacer para evitar este tipo de situación?
Básicamente, necesitamos, de alguna manera, guardar los estados de nuestro proyecto, es decir, hacer con que cada cambio que entregamos sea una versión, por ejemplo, dividiendo en diferentes carpetas. Entonces tendríamos:
01-lista-sencilla: primera entrega con una lista sencilla.
02-lista-con-descripción-y-cantidad: segunda entrega con una lista que contiene la descripción y la cantidad de cada producto
03-lista-con-imagen-descripción-y-cantidad: Tercera entrega con una lista que contiene la imagen, descripción y cantidad de cada producto.
De hecho, este tipo de abordaje funciona, sin embargo, tenga en cuenta que para cada una de las versiones que surjan tendremos que realizar este proceso manual varias veces. Si observamos bien, este abordaje tiende a ser muy laborioso y está repleto de riesgos, tales como:
Control: para cada cambio de proyecto, tendremos que recordar crear una carpeta de proyecto actual.
Historial: Es muy difícil tener una visión amplia y objetiva de lo que se hizo y cuándo se hizo, así como de lo que cambió de una versión a otra.
Reversión: si necesitamos volver solo una parte de lo que se ha hecho hace mucho tiempo, manteniendo las otras cosas nuevas que se han implementado, probablemente vamos a tener un enorme trabajo.
¿Existe una forma más sencilla y objetiva de afrontar este tipo de situación?
Para hacer frente a estas situaciones de forma más eficaz, podemos utilizar sistemas de control de versión, también conocido como VCS del inglés Version Control System, o traducido como, Sistema de Control de Versión.
Un VCS ampliamente utilizado es el Git. Una herramienta muy común en la comunidad para versionar proyectos que mantienen archivos fuentes como el nuestro:
"Genial, pero ¿cómo puedo usar Git?"
El primer paso de todo es instalarlo en tu computadora, puedes hacer esto en esta página de descargas.
Es posible instalar a través del administrador de paquetes, como Apt, Brew, Scoop, etc.
Después de la instalación, ¡ya podemos hacer el control de versión de nuestro proyecto! Para ello, por el terminal o prompt, nos dirigimos al directorio donde está el proyecto, en mi caso está /home/alex/meus-projetos/mercadinho.
Luego le decimos a Git que comience (init
) la gestión del proyecto:git init
Observa que se exhibe un mensaje que indica que se ha iniciado un repositorio de Git vacío.
En otras palabras, ahora mismo creamos un repositorio local de Git dentro de nuestro proyecto, por lo que comenzó a gestionarlo.
"Genial, pero ¿qué vamos a hacer ahora?"
Primero, volveremos a nuestro proyecto a la primera versión que se entregó al cliente, luego, comenzaremos a crear las versiones que surgieron según la necesidad del cliente. ¡Entonces usaremos Git para que nos gestione eso!
Volvemos a lo que teníamos desde el principio, así que primero debemos pedir a Git que marque todos los archivos que queremos guardar en esta primera versión.
Siguiendo los archivos que tenemos en el proyecto:
Entonces podemos pedir a Git que agregue (add) nuestro archivo productos.html para guardarlo:
git add productos.html
¡Listo! Con eso, nuestro archivo fue marcado por Git, sin embargo, aún necesitamos marcar los archivos que están en el directorio css
y js
. Pero para hacer esto ¿necesito agregar todos los archivos contenidos en ellos uno por uno?
No necesariamente, puede agregar un archivo a la vez informando la ruta, pero si desea agregar todos los archivos de un directorio, simplemente dígale esto a Git:
git add css/
De esta forma, todos los archivos dentro de la carpeta css
/ se han agregado a Git. Pero si en mi proyecto tengo muchos archivos y directorios, ¿necesito agregarlos cada uno a la vez?
Considerando que necesitamos hacer eso en todos, podemos decirle a Git que agregue (add
) todos los archivos modificados (.):git add
.
Ahora que hemos agregado todos los archivos que queremos guardar, debemos pedirle a Git que guarde el estado actual de nuestro proyecto, es decir, ¡nuestra primera versión!
En otras palabras, le indicaremos a Git que todo lo que le pedimos que guarde representa nuestra primera versión. Para esto usamos el comando git commit
.Sin embargo, este comando requiere que enviemos un mensaje (-m
) indicando lo que significa este estado.
git commit -m "primera entrega con una lista sencilla"
Si no usamos este parámetro con un mensaje específico, Git solicita al sistema que abra un editor de texto estándar para que el mensaje se asocie de la misma manera.
¡Note que Git mostró todos los archivos que se agregaron en esta versión que guardamos!
Ahora que tenemos nuestra primera versión, ajustemos el proyecto y coloquemos las otras versiones que solicitó el cliente y hagamos el mismo procedimiento, es decir, marquemos los archivos a guardar con el add y luego guardemos la versión con el commit
.
En la segunda versión modifiqué el HTML para que contara con las listas con descripción, por lo que tenemos el siguiente resultado al comitar (no se sorprenda, es común que hablemos así):
Ves que ahora solo notificó que hubo un cambio en 2 archivos, también esta vez no mostró que el archivo fue agregado, ¡solo registró lo que lo cambió! Es decir, 63 líneas insertadas y 14 eliminadas.
Además, observe que incluso con 9 archivos dentro del proyecto como vimos inicialmente, Git ya es lo suficientemente inteligente como para saber que cuando lo hicimos git add. necesitaba agregar solo los archivos que se modificaron :)
Por fin, agregaré la imagen al producto y realizaré el mismo procedimiento:
Ves ahora, además de editar los archivos que ya se habían agregado una vez, también agregamos la imagen que no existía hasta ahora y Git indicó que se insertó específicamente en esa versión. En este punto, es posible que se esté preguntando:
Genial, pero ¿cómo puedo ver si mis estados, o más bien mis commits, realmente fueron registrados?
Para ver todos los commits que hemos realizado hasta ahora en el repositorio Git, simplemente use el comando git log:
Ten en cuenta que Git muestra tanto el autor como la fecha de creación de la versión, por lo que tenemos la capacidad de ver el historial de cambios que se realizaron en el proyecto, como quién lo hizo y cuándo se realizó.
Además, observe que cada commit tiene un hash para identificarlo, en otras palabras, ¡es a través de estos hash que tenemos la capacidad de saber qué ha hecho un determinado commit o incluso navegar entre los commits!
Por ejemplo, para volver ahora a la primera versión usamos el comando git checkout 631123e4d6276b49059a7ae96b1de86c928f71c2
, mira esto:
Usamos este hash porque se refiere al primer commit que guardamos, es decir, nuestra primera versión.
Si revisamos nuestro directorio:
Mira, ya no tenemos la imagen que se agregó con el directorio.img. En este punto, podrías estar pensando:
"¿Pero cómo vuelvo al commit que tenía la imagen con las descripciones?"
¡Sencillo! Solo ejecutas el comando git checkout master
:
¡Fíjate que ahora volvió la imagen! En otras palabras, volvemos al último estado que se guardó, es decir, el último commit.
Vale la pena señalar que hicimos uso de este master, que al principio no tiene mucho significado para nosotros. Sin embargo, es un tema que va un poco más allá de nuestro primer contacto con Git, tal vez en una próxima publicación :)
Además de un VCS, Git también se conoce como un SCM del inglés, Source Code Management o gestión de código fuente. Además de él, también existen algunas alternativas con el mismo objetivo:
Básicamente, estas herramientas son capaces de aplicar todos los conceptos que vimos durante el texto, sin embargo, uno acaba teniendo alguna ventaja sobre el otro, así como la adopción de la comunidad de desarrolladores.
Genial, pero ¿sobre cuál de estas herramientas vale la pena aprender?
Una de las formas en que podemos verificar es exactamente qué tanto más se usa una herramienta en relación con otra. Para ello, tenemos la posibilidad de ver la popularidad de cada una de ellas en esta encuesta realizada por RhodeCode en 2016.
Además de los temas que vimos anteriormente, un uso muy común en herramientas como Git es precisamente mantener nuestro proyecto disponible de forma remota para cualquier desarrollador que participe en el proyecto.
En otras palabras, dejar nuestro proyecto en un repositorio en línea como es el caso de GitHub, GitLab o BitBucket. Entonces, si necesita descargar el proyecto u obtener las últimas actualizaciones que se realizaron, ¡simplemente consulte estos repositorios remotamente!
El cambio es una característica común durante el desarrollo de un proyecto y, para manejar mejor este tipo de situación, tenemos los VCS como es el caso de Git.
Esta es una pequeña parte del mundo del control de versiones, también existen técnicas y conocimientos esenciales para utilizar estas herramientas de manera eficiente.Si desea aprender más sobre el control de versiones, aquí en Alura tenemos un curso de Git.
Allá podrás ver tanto esta parte del control de versiones del proyecto como también técnicas más avanzadas que podemos aplicar durante el desarrollo en equipo, que es algo muy común en la vida cotidiana.
Puedes leer también:
Cursos de Programación, Front End, Data Science, Innovación y Gestión.
Luri es nuestra inteligencia artificial que resuelve dudas, da ejemplos prácticos y ayuda a profundizar aún más durante las clases. Puedes conversar con Luri hasta 100 mensajes por semana
Paga en moneda local en los siguientes países
Cursos de Programación, Front End, Data Science, Innovación y Gestión.
Luri es nuestra inteligencia artificial que resuelve dudas, da ejemplos prácticos y ayuda a profundizar aún más durante las clases. Puedes conversar con Luri hasta 100 mensajes por semana
Paga en moneda local en los siguientes países
Puedes realizar el pago de tus planes en moneda local en los siguientes países:
País | |||||||
---|---|---|---|---|---|---|---|
Plan Semestral |
487.37
BOB |
69018.45
CLP |
308114.50
COP |
65.90
USD |
264.97
PEN |
1441.56
MXN |
2978.57
UYU |
Plan Anual |
738.82
BOB |
104627.36
CLP |
467081.02
COP |
99.90
USD |
401.68
PEN |
2185.32
MXN |
4515.32
UYU |
Acceso a todos
los cursos
Estudia las 24 horas,
dónde y cuándo quieras
Nuevos cursos
cada semana