Él es nuestro primer invitado y nos va a platicar de la importancia de tener ordenado nuestro software, porque muchas ocasiones de no hacerlo se nos puede volver un dolor de cabeza. También nos presenta una herramienta de control de versiones la cual por cierto les adelanto es gratuita y siguiendo la temática de este blog nos comparte ejemplos muy completos, seguro los va a convencer de utilizarlo.
Espero les agrade este post, nos compartan, dejen sus dudas, comentarios, opiniones, retroalimentaciones, sugerencias.
Espero les agrade este post, nos compartan, dejen sus dudas, comentarios, opiniones, retroalimentaciones, sugerencias.
Leamos a Osvaldo:
Todos en algún
momento de hemos tenido que modificar programas, ya sea por mejoras o por
correcciones, y la mayoría de nosotros lo que hacemos es crear una carpeta /
copia del programa con el mismo nombre pero con terminaciones _Resp, V1, V2, y
así según vallamos avanzando en el desarrollo. Esto se complica más cuando dos
o más desarrolladores trabajan sobre el mismo programa, o peor, en el mismo
archivo.
Los sistemas de
control de versiones nos ayudan a resolver estos problemas. Estos sistemas
funcionan comparando archivos a bajo nivel contra lo que tienen almacenado, de
esta forma guardan el estado de cada archivo en cada versión que se ha
generado, lo que nos permite hacer revisiones a través del tiempo y saber que
se cambió y quien hizo el cambio.
El sistema del que vamos a comentar es Git.
Git es el sistema de versiones desarrollado por
el mismo equipo que desarrolló Linux, por lo que comparte varias
características y comandos, en varias distribuciones de Linux Git está instalado por defecto. Para el caso de
Windows, Mac-os y otras distribuciones de Linux, el instalador se puede
descargar de manera gratuita desde su sitio web (https://www.git-scm.com) ahí también
encontraremos documentación y recursos relacionados. Una vez instalado el
sistema, usaremos el programa Git Bash,
que es la consola de Git.
Veamos
cuales son los estados de un archivo en Git:
- Untracked -> archivo que está en el directorio pero que Git no lo tiene en su sistema de control.
- Tracked -> el archivo es agregado al área stagign* de Git y es donde comienza a ser parte de los archivos controlados por Git
- Committed -> El archivo pasa del área staging al repositorio de la rama** en la que estemos trabajando.
- Staging es el área de Git donde guarda temporalmente el archivo en el que estamos trabajando y es desde donde compara con las versiones que ya existen en el repositorio.
- La rama principal de Git se llama "Master".
Antes
de iniciar debemos de realizar algunas configuraciones de nuestro usuario, ya que Git es una herramienta colaborativa debemos de
saber exactamente quién es el responsable de cada cambio. Para ello usamos los
siguientes comandos en la consola
Veamos cuales son
los estados de un archivo en Git:
Para
iniciar el control de versiones de nuestros programas o archivos, debemos de
inicializar un repositorio, para ello debemos de abrir la consola de Git y ubicarnos en la carpeta donde están los
archivos que vamos a versionar. Estando ahí ejecutamos el comando git init, los principales
cambios que vamos a notar en la consola es que Git
automáticamente nos coloca en la rama Master
y se crea una carpeta oculta .Git que es donde Git
tiene sus recursos para controlar el repositorio
Ahora
que ya tenemos el repositorio en la carpeta de nuestro programa podemos empezar
a agregarlos a la base de versiones. Veamos la forma en que el archivo pasa en
cada uno de los estados anteriormente mencionados con los comandos de Git:
Para
saber que archivos han sido modificados o no están trackeados o si el
repositorio no ha tenido cambios, usamos el comando git status
Hay
proyectos que tienen una gran cantidad de archivos, para agregarlos todos
usamos el comando Git add .
Como
vimos, el comando git add .
agrega los datos a staging, para crear
la primer versión del ejecutamos el comando git commit -m "Comentario
del commit". El comentario es necesario para poder identificar qué
es lo lleva esa versión
A
cada commit Git le asigna un numero único
el cual nos va a servir para poder movernos entre cada una de las versiones.
Para conocer el número de los commits usamos el comando git log
O
para verlo de una forma simplificada git log --oneline
Supongamos
que tenemos un programa al que nos han solicitado realizar un cambio, entonces
creamos la rama Desarrollo1 a partir de Master, que es la versión de producción.
Durante el desarrollo nos reportan un error que se debe de corregir
inmediatamente, entonces creamos una rama que se llama HotFix1 a partir de la rama Master.
Para crear las ramas usamos el comando git Branch "Nombre"
Para saber que ramas
tenemos ejecutamos el comando git
branch, se puede ver que master está resaltado, con esto Git nos indica que el head del repositorio está
apuntando a la rama master
Vamos
a empezar a hacer cambios en nuestra rama Desarrollo1,
para cambiar de ramas usamos el comando git checkout
<nombre de la rama>
Si vemos la consola,
ya no está entre paréntesis la rama Master,
ahora está Desarrollo1, si ejecutamos el
comando git branch
ahora ya estará resaltada la rama
Vamos
a nuestra aplicación y hagamos una función llamada funcionDesarrollo en un módulo existente, esta función solo
mandará un mensaje a pantalla
Guardamos
la aplicación y regresamos a la consola de Git,
usamos el comando git status
y vemos los cambios que ya encontró en el repositorio
Vemos
que el sistema ya nos indica que hay archivos modificados y que debemos de
llevarlos a stagign con git add ., vemos el estatus
con git status y
hacemos el commit en la rama Desarrollo1
Ahora
vamos a cambiar a la rama HotFix1,
nuevamente la consola nos indica que estamos en otra rama
Si
vemos el log de HotFix1 no vamos a
encontrar el commit que se hizo en Desarrollo1
Ahora
veamos el programa, Visual Studio nos va a indicar que el archivo cambió y que
se debe de recargar, notaremos que la función ya no existe
En
esta rama vamos a modificar la función BuscaBase
y creamos otra que nos envíe el nombre de la base
Guardamos
el cambio, en la consola agregamos el cambio a staging
y hacemos el commit
Vamos
a regresar a la rama Master, Visual
Studio nos va a recargar el archivo sin ninguna modificación
Lo
lógico es que traigamos los cambios del HotFix1
a la rama Master, para ello usemos el
comando git merge <nombre de la rama>
Veamos
el log y encontraremos que ya está el commit
de HotFix1 en Master
Veamos
el archivo en Visual Studio
Ya se encuentra la
modificación a la función BuscaBase
y la nueva función nombreBase
Ahora hagamos merge con la rama Desarrollo1 y veamos que pasa
OMG!! El merge falló y la rama master quedó en un
estado Merging!!
Lo que pasa es que
hay conflictos en la misma línea que Git
no puede resolver de forma automática, regresemos a Visual Studio y veamos cómo
nos muestra los conflictos
La mayoría de los
editores modernos ya nos ayudan a gestionar los conflictos, en este caso nos
indica con la etiqueta
<<<<<<<
HEAD
============
Lo que tenemos en la
rama en la que estamos ubicados, en este caso es Master;
y con la etiqueta
>>>>>>>
Desarrollo1
Lo que tenemos en la
rama Desarrollo1
Lo que toca hacer es
resolver el conflicto de forma manual y guardar el archivo
Lo que hicimos fue
dejar las dos nuevas funciones y el parámetro agregado a la función existente.
Regresemos a la
consola y veamos el estatus del programa
Agregamos el archivo
con git add ., y
ejecutemos el commit
¿Por qué hicimos un commit? La función merge lo que hace es escribir los cambios y luego hace un commit para guardar la versión generada con el
merge, al fallar el merge por el conflicto nos toca hacer el commit en un segundo paso
Ahora veamos el log
Vemos que en Master están los commits
que se hicieron en HotFix1, en Desarrollo1 y el commit
para resolver los conflictos
Por último usemos el
comando git log --all --graph
--decorate --oneline
Lo que nos muestra
es una gráfica de lo que realizamos.
Estas son las
funciones básicas de Git, sin embargo aún
se pueden hacer muchas más cosas como:
- Importar repositorios
- Exportar repositorios
- Trabajar con repositorios remotos, usualmente con repositorios en GitHub
- Trabajar con llaves criptográficas
- Elegir commits.
- Y un considerable etc.
Hasta aquí mi
colaboración a este interesantísimo blog, aprovecho para felicitar a Ana por
compartirnos una de sus pasiones en la vida y ojalá que este, su blog, se siga
consolidando como fuente fiable de información.
No olvide compartirnos y seguirnos en este blog o en Facebook.
Comentarios
Publicar un comentario