Si llevas años trabajando en esto, seguramente te hayas encontrado con sistemas de control de versiones (CVS, SVN,…), y también sabrás que el rey ahora es Git.
Para los advenedizos, explicaremos un poquito que es esto del control de versiones, que puede que sea un concepto que no tengáis claro del todo:
¿Cuántas veces habéis querido montar en el Delorean, volver atrás y cambiar las cosas? Seguro que muchas. Pues un control de versiones os permitirá hacerlo. A ver, no podréis evitar que todo el mundo recuerde esa borrachera en la fiesta de la empresa, ni conseguir un almanaque de resultados deportivos para apostar sobre seguro… pero en temas de código, podrás ser un viajero del tiempo.
Podrás “hacer fotos” de cada momento, pudiendo volver a ese punto cuando quieras, para deshacer cosas que no quieres, recuperar código… Pero no creas que esto es algo lineal, porque existe el concepto de “rama” que te hará mucho más fácil la vida. Imagínate que quieres desarrollar una nueva funcionalidad; pues crearás una rama que partirá de el punto en el que te encuentres y que irá por su camino, independiente. Podrás avanzar en tu trabajo mientras que en la otra rama podrán incluso realizarse nuevos cambios y despliegues sin que tu código tenga nada que ver. Una vez llegado el momento de desplegar tu nueva funcionalidad, “mergearás” la rama y (puede que con algún que otro conflicto) tendrás la versión de todo juntito.
¿Mergear? ¿Conflicto? Tranquilo, ahora veremos un proceso de ejemplo con los comandos básicos y entenderás todo, como si Doc te lo explicase.
Pero antes, que siempre viene bien, el link oficial de Git, para que investigues un poquito:
Venga, vamos a lo práctico, que es para lo que estamos aprendiendo.
Imaginemos que tenemos ya el sistema montado, cosa que, como programador, posiblemente encuentres.
– “Vicente, te paso el enlace del git donde está el proyecto.”
Eso es lo que necesitas para empezar. Eso, y tener instalado Git, claro. Si no habías caído en ello es que has ignorado por completo el enlace que te he puesto antes. Mal. Instálalo y seguimos.
Este es el enlace de ejemplo: https://github.com/entorno5/testing.git
Es un repositorio que tengo en github con tan solo un archivo .readme (en github puedes tener tus repos, cotillea). Nos vale para hacer el proceso completo de este “Hola Mundo” de Git.
Trabajaremos desde consola. En este ejemplo yo he abierto un PowerShell, usa la que más te guste, incluso esta si quieres que tu vecino piense que eres hacker.
Me sitúo en una carpeta y lanzo mi primer comando: git clone, indicando el repo:
Como veis, descarga el repo:
En consola, entramos en la carpeta testing, y ejecutamos: git status. Este comando nos indicará los cambios que existen. Como todavía no hemos hecho nada, nos dirá que no tenemos nada para añadir al commit (luego hablamos de esto).
Cambiemos el contenido del archivo .readme. Volvamos a hacer un git status y veamos qué sucede:
Ahí lo tienes, detecta el cambio que hemos realizado y nos da pistas de lo que debemos hacer: añadir lo cambios que deseemos y hacer el commit. ¿Qué es el commit? Es un registro de cambios, un punto en la línea temporal por donde estamos haciendo un poco el McFly, que nos permite registrarlo y viajar a él con el Delorean siempre que sea necesario.
Pues vamos a añadir el archivo y ver cómo cambia el status:
Ya aparece nuestro archivo para el commit (podrías añadir los archivos que quisieras formaran parte de ese punto y dejar otros que no interese reflejar por el momento). Pues venga, marchando un git commit:
Como ves, en la sintaxis, se le añade un mensaje para que sea algo más descriptivo que el id que le asigna automáticamente (haz un git log y verás de lo que te hablo)
Pues ya tenemos en nuestro repositorio local ese checkpoint, ahora toca enviarlos al servidor con el comando git push:
Si volvemos a ver el status, ya no tenemos cambios que realizar ni subir (recuerda que en este caso solo hay un archivo, como antes hemos comentado, puedes subir solo los archivos que te interesen).
Este es el ejemplo más básico, pero creo que para entender cómo funciona Git, es suficiente. La cosa se complica con más desarrolladores interactuando, y aparecerán los conceptos de los que te hable al principio: conflictos (dos tocáis lo mismo y Git no sabe cómo realizar esa fusión), ramas…
Si tienes alguna duda, joven Marty, déjame preguntas por aquí y entramos más en detalle, o preparamos una nueva entrada ahondando en esos aspectos (para que puedas viajar a ella cuando quieras).
Y hasta aquí nuestro viaje de hoy. Espero que te haya valido como referencia para que empieces a trastear y usarlo en tus proyectos. Podrás trabajar con menos miedo del habitual, dejar de hacer copias por si el cliente quiere volver a una versión anterior y trabajar en equipo con mucha mas eficacia. Ya me contarás.
¡Hasta la semana que viene!
