¿Qué es un control de versiones?
Un control de versiones es una herramienta de administración de versiones en el desarrollo de un producto. Se orienta muchas veces a desarrollo de código para aplicaciones informáticas, pero hoy en día puede servir para crear cualquier tipo de proyecto que involucre imágenes, documentos de texto, paginas web, etc…
¿Por qué es tan importante para desarrollar proyectos?
Durante la evolución de un verdadero Maker, la mayoría de proyectos para aprender, son relativamente pequeños o han sido creados por otras personas con más conocimiento en algunas áreas especializadas.
Una de los puntos de apoyo que aportan calidad y continuidad a un proyecto son el uso de un control de versiones cuando pasamos a realizar proyectos cada vez más grandes.
Un control de versiones nos permite crear un histórico al que vamos integrando piezas a nuestro proyecto cómo si fuera un puzle hasta completarlo.
Un control de versiones nos permite:
- Optimizar el flujo de trabajo
- Desarrollo colaborativo entre un conjunto de personas
- Comparación entre versiones de proyecto
- Extensible, flexible y robusto
Este proceso puede parecer complicado, pero es una herramienta que nos permitirá abrir una metodología profesional para la creación de código en equipo y de forma robusta.
Control de versiones GIT
Existen varios controles de versiones como Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial, Perforce, Fossil SCM. Pero nosotros nos centraremos en GIT para crear proyectos en nuestro ordenador y de forma remota ya que utilizamos Github para publicar nuestros proyectos. También hacemos mención de Gitlab como plataforma lider basada en GIT.
GIT además tiene soporte en una gran variedad de plataformas de código como el editor Sublime, JAVA, Android Studio, PyCharm, entre muchos otros .
Al final de este taller solo necesitamos conocer en qué se basa esta metodología para poder usar cualquier otro control de versiones.
Filosofía de Control de versiones
Aguna vez os ha ocurrido que estáis programando una aplicación y no sabéis si cualquier cambio será compatible con el objetivo final; se añaden lineas de código para depurar y comprobar el funcionamiento de la aplicación, generamos más archivos; comentamos lo que no usamos; borramos una versión estable y luego nos damos cuenta de que hay que ir varios pasos atrás para recuperar el código anterior… pero ya es demasiado tarde y todo es un caos.
Pues un control de versiones es una herramienta que soluciona esos problemas creando una especie de “copia” que puedes consultar durante el desarrollo y comparar esas partes de código que han sido borradas y añadidas durante el proceso.
Terminología
- Repositorio – Carpeta del proyecto habilitado con un control de versiones para realizar el seguimiento que se sincronizará para trabajar en equipo.
- Commit (Publicar o Enviar ) – Copia de los cambios integrada en el repositorio.
- Rama ( branch ) – Derivación del proyecto que evoluciona de forma independiente para su reincorporación ante el desarrollo de nuevas funcionalidades
- Push – Subir los cambios realizados al respositorio común.
- Pull – Actualizar el repositorio adoptando los cambios producidos por otras personas del equipo.
- Diff – cambio varía entre diferentes sistemas de control de versiones.
- Integración ( Merge) – Fusión de dos conjuntos del proyecto en una revisión unificada de dicho fichero. Usualmente se usa cuando se quiere incorporar una rama o branch a la rama principal del proyecto.
- Rebase – Reorganización del trabajo realizado o del conjunto de commits.
- Log – Información sobre el histórico de cambios (commits).
- Checkout – Gestión de ramas de una a otra para definición del árbol actual de trabajo.
- Remote – Gestión de repositorios remotos.
- Fetch – Actualización y descarga del repositorio. Fetch es un git pull, seguido de una fusión a la rama principal del trabajo realizado en el encabezado – git merge FETCH_HEAD.
En esta imagen se puede ver el proceso por el que pasa cada archivo definiendo los estados como:
- Untracked
- Unmodified
- Modified
- Staged
Configuracion inicial
Para empezar a crear un proyecto, primero deberemos completar unos parámetros de configuración de nuestro entorno GIT.
Esto es importante para definir las configuraciones específicas que debe conocer nuestro proyecto para que las instrucciones en la linea de comandos queden almacenadas.
Hay que tener en cuenta dos modos de utilizar la configuración de nuestro proyectos.
- global – En caso de no especificarlo, nuestro proyecto contendrá la misma configuración que el resto por defecto. Por ejemplo, nuestro nombre y correo son parámetros comunes a todos nuestros proyectos.
- local – En este caso, cada proyecto almacenará información específica diferente de la del resto como por ejemplo el repositorio remoto para subir nuestros cambios.
Para añadir distintos parámetros globales a nuestros proyectos se han de incorporar con las siguientes instrucciones.
git config --global user.name "zms" git config --global user.email "info@zaragozamakerspace.com"
Para conocer las configuraciones de nuestro proyecto podemos listarlas con estas ordenes.
git config --global -l git config --local -l git config -l
Toda esta información estará almacenada en una carpeta oculta .git dentro de nuestro proyecto. Esta carpeta no formará parte del proyecto final, pero es necesaria para sincronizar todos los cambios.
Así que si hacemos un cat del archivo config, podremos editar las configuraciones locales directamente en texto.
Crear un proyecto GIT nuevo
Para empezar a crear un proyecto con GIT, solamente tendremos que tener instalado git en nuestro sistema y ejecutar git init. Con esta instrucción ya tendremos la estructura del control de versiones, pero a partir de este punto es nuestra responsabilidad dedicarle tiempo a su mantenimiento.
La mayoría de veces el proceso de desarrollo se basa en:
- Acceder al proyecto y trabajar en él.
- En el momento que se añaden cambios, se cierran taréas o se modifica un elemento que tenga relevancia para definir una versión se añaden los ficheros con add.
- Se realiza un commit y se escribe una descripción resumida de los cambios más relevantes.
- Subir el proyecto al directorio remoto; si es que contiene uno; con push.
cd /home/my-project git init git status git add --all git status git commit -m "My First commit" git push git status git log --stat --online --abbrev-commit
Si no se han configurado convenientemete las variables del repositorio, la última orden detectará que no existe información suficiente de usuario o ruta remota para publicar los cambios de la version actual.
Para ver más información de nuestra versión actual del proyecto, consultar la documentación.
*IMPORTANTE: Si otra persona ha realizado cambios en el proyecto, nosotros no podremos avanzar sobreescribiendo nuestra copia local a la de los demás.
Por ello, en el proceso de incorporación a la rama de trabajo deberemos actualizar el repositorio con pull, verificando que esos cambios son validados y testeados para poder seguir con el proyecto.
git pull git fetch origin
*En caso de que los cambios no fueran los deseados, con GIT podemos volver a los estados anteriores para recuperar una versión funcional .
En el caso de que nos hayamos equivocado a la hora de preparar el repositorio, podemos eliminar el archivo que esta preparado y bajarlo de nivel.
git rm --cache file
Si queremos guardar el estado en el que hemos dejado el repositorio, sin subir nada para la próxima vez, tendremos que usar la opcion
git stash
Seguir desarrollando un proyecto GIT ya creado por otra persona
En caso de no tener creado un proyecto, podemos partir de un proyecto publicado ya en Internet y seguir ejecutando cambios sobre él. En el caso de la plataforma de Github es tan fácil como escribir la ruta URL dónde se encuentra y se creará una copia en nuestro ordenador.
git clone https://github.com/ZaragozaMakerSpace/CoderDojo2019
Una vez que se descarguen todos los ficheros y archivos, podemos modificar cualquier archivo de texto y con las mismas intrucciones de antes, realizar las acciones requeridas para actualizar el repositorio y subir los cambios.
git status git add --all git status git commit -m "My First commit" git push
Git Ignore
Algunas veces nuestro ordenador crea archivos ocultos o temporales dentro de la ruta de nuestro proyecto. Si estamos acostumbrados a subir todos los cambios a nuestro repositorio de golpe, se añadirá todo el contenido en la ruta de nuestro proyecto.
Ignorar archivos dentro de la copia local de Git a un repositorio remoto es útil para elegir qué ficheros queremos que se suban a la versión de trabajo. También podemos especificar patrones mediante una expresión regular para evitar que los documentos de un solo tipo sean ignorados.
Para ello, deberemos registrar en un archivo llamado .gitignore las instrucciones que se han de ignorar en cada linea.
Por ejemplo si queremos ignorar algunos archivos temporales que crea el propio entorno de GIT deberemos escribir en una linea.
*.swp
Si seguimos los formatos explicados en el siguiente enlace, podremos complementar distintas instrucciones como evitar que un patron de archivos ofusque un archivo concreto.
*.doc
!tutorial.doc
Ramas ( Branch )
Si tu proyecto requiere de la creación de una Branch enhorabuena. Eso quiere decir que tu proyecto está creciendo y de que existen varias lineas de trabajo que en un futuro incorporarás para crear algo más grande.
En el momento de crear nuestro proyecto con git init, nuestra rama principal se establece por defecto como la rama master. master es la rama principal de nuestro proyecto GIT, pero quizás queramos investigar cómo afectarán distintas modificaciones al proyecto o distintas vias de desarrollo.
git checkout -b branchname git branch git checkout master
De esta forma el proyecto creará una bifurcación que se pueden desarrollar por separado o que distintos equipos pueden trabajar para luego fusionarlos con la instrucción merge.
IMPORTANTE: En este aspecto, siempre que nos incorporemos a nuestro proyecto, deberemos situarnos en nuestra rama desde la que vamos a partir, dejando de lado a la principal. Si relizamos cambios y los ejecutamos sobre la rama principal sin darnos cuenta, tendremos que dar un paso atrás y ejecutar los cambios sobre la rama correspondiente.
Repositorio remoto
Si hemos clonado nuestro repositorio desde Github o desde otra plataforma, nuestro repositorio se alojará en los servidores, en este caso, de Github de forma pública. Por lo que la configuración remota cada vez que realicemos un push, se subirá a este servidor.
En caso de no haber especificado una ruta externa para alojar el proyecto y compartirlo, contaremos solamente con una copia local. Si trabajamos en equipo, una copia local en un solo equipo o en varios equipos desincronizadas no tiene sentido para usar GIT, por lo que necesitaremos especificar esta ruta para subir el proyecto y que nuestros compañeros puedan acceder y realizar modificaciones y registros.
*IMPORTANTE. Al crear un repositorio nuevo, por defecto siempre se define un nombre del repositorio de origen denominado”origin” y la rama principal que se denomina “master“.
Es muy habitual que a la hora de realizar un cambio, se destine este cambio a una rama concreta. Por ello es habitual encontrar la denominación origin master a nuestro entorno de trabajo por defecto.
git remote add origin https://github.com/ZaragozaMakerSpace/CoderDojo2019 git remote -v
GIT ME A HUG
Existe mucha más información dentro del mundo GIT, si quieres conocer más, deberás seguir los pasos que se aplican en el siguiente repositorio de GitHug en el que se ofrecen una serie de instrucciones para aprender durante 56 niveles el uso de Git .
Al final de este reto, obtendrás un código que te permitirá leer el siguiente capítulo con algunos trucos más extendidos de esta herramienta.
*Preguntas habituales
- HEAD, HEAD^ , HEAD~1 – Referencias en GIT
- FETCH_HEAD
- DETACHED_HEAD
- PULL VS FETCH
- GIT RESET – SOFT, HARD, MIXED
- CACHED
- GIT DIFF OPTIONS
