Guía básica de ungit, herramienta de control de versiones en datalab

Índice de contenidos

Ungit es la herramienta de control de versiones de código abierto que viene directamente integrada en DataLab, de Google Cloud Platform. En este post encontrarás una guía básica de cómo utilizar ungit y los conceptos clave sobre control de versiones.

Si quieres saber más sobre Datalab te recomendamos que veas nuestro post: ¿Qué es google cloud platform?

¿Qué es un sistema de control de versiones?

Un sistema de control de versiones es un sistema que permite registrar cambios de uno o varios archivos a lo largo del tiempo. De modo que permite volver a un momento específico y “viajar en el tiempo” para recuperar o consultar ese punto concreto más adelante. 

Resulta especialmente útil cuando varias personas trabajan en un mismo proyecto. Se pueden comparar distintas versiones de un mismo archivo, y por supuesto volver a una versión previa si se produce un error o se elimina el archivo.

Conceptos básicos

Ramas

Git utiliza un sistema de ramas que facilita el trabajo de varias personas de manera simultánea en un mismo proyecto.  En este caso, encontramos una rama master que es la principal, sobre la que no es aconsejable trabajar directamente. Adicionalmente creamos otras ramas. Algunos prefieren crear una por persona otros por funcionalidades. Dentro de las buenas prácticas se aconseja crear ramas por funcionalidades y cerrarlas conforme se vayan completando. Elegir una opción u otra puede depender de la madurez del equipo principalmente.

La interfaz se visualiza así:

Cada rama puede tener dos estados distintos: local y remoto. Local es el punto en el que está trabajando el usuario en su máquina y remoto es  aquel punto de la rama  al cual tienen acceso el resto de usuarios. Es aconsejable fijarse bien en el punto al que está apuntando el local antes de empezar a trabajar, así evitaremos conflictos posteriores al ‘publicar’ los cambios. En ungit el local viene representado por el nombre de la rama en color blanco y el remoto en color azul

El contenido que veamos en datalab depende directamente de la rama sobre la que nos encontremos en ungit, y en todo momento se corresponderá con el estado en local, aunque el remoto de nuestra rama esté apuntando a otro punto.

Cuando un usuario ‘guarda y comparte’ los cambios (luego veremos a qué nos referimos con guardar y compartir), local y remoto estarán en el mismo punto. Sin embargo, el usuario puede decidir ir a un backup anterior para seguir trabajando, y entonces el local estará apuntando a un punto más atrasado que el remoto. O también se puede ‘guardar’ y no ‘compartir’ los cambios, entonces el local estará en un punto más avanzado que el remoto.

Cuando se considera que el contenido de la rama es correcto y funciona bien entonces se deberían ‘compartir’ los cambios con el resto pasándolos a la rama master (explicamos más adelante cómo hacerlo).

GitIgnore

El archivo .gitignore determina los archivos que queremos que git ignore. Si en datalab tenemos  archivos que no queremos que formen parte del control de versiones deberemos incluirlos en este fichero. ¿ Qué tipo de archivo meteremos en gitignore ? Archivos muy pesados que no sufran cambios relevantes que traquear. Otro ejemplo sería, en una aplicación web, la carpeta node_modules que se incluiría en el fichero gitignore ya que se puede generar cada vez a partir de otro archivo.

Acciones

Hay varias acciones que nos permite realizar ungit para llevar a cabo el control de versiones.

Crear una rama

Siguiendo las buenas prácticas, es recomendable utilizar ramas distintas para cada funcionalidad. La forma de crearlas en ungit es muy sencilla. Hay que ubicarse en la rama que queremos como base y hacer click en el símbolo del “ + ”. Luego le damos un nombre y pulsamos la tecla del enter ( ) o el botón que indica “ branch ”.

Ten en cuenta que hasta que no hagas un push de la rama (lo vemos más adelante), para el resto de compañeros no existirá esa rama.

Checkout

El checkout nos permite cambiar de una rama a otra. Podemos visualizar en qué rama estamos trabajando fijándonos en el desplegable que se marca en la captura siguiente:

Para cambiar de rama solo hay que hacer click sobre el nombre de la rama a la que quiero ir y hacer click en checkout como se indica en la siguiente captura.

Recuerda que no es aconsejable trabajar directamente sobre la rama master, y que la información que veas en datalab dependerá directamente de dónde hayas hecho checkout.

Commit

Hacer un commit es equivalente a hacer un backup del estado actual de la máquina. Se genera un nuevo punto en ungit en mi repositorio en local, punto al que puedo volver en cualquier momento aunque siga haciendo más commits (equivaldría al Time Machine en Mac).

Lo aconsejable es ir haciendo commits de vez en cuando. Además, ungit no responde muy bien cuando se acumulan muchos cambios sin commitear.

Push

Al hacer push de la rama subimos los cambios al repositorio en remoto de la misma (nombre de la rama en color azul) y hacemos los cambios visibles para todos los usuarios. De momento los cambios solo están en la rama en la que estoy trabajando, y no han sido incorporados a la rama master.

Hacer un push equivale a compartir los cambios.

Reset

Es posible que hayamos hecho un commit y que antes de hacer el push decidamos eliminarlo y desechar esos cambios. En este caso habría que seleccionar el  nombre de la rama en local y hacer click en reset para eliminarlo.

Pull

Dentro de una misma rama, puede que el repositorio en remoto esté más actualizado que el repositorio en local. Si esto es así podemos actualizar la información que vemos en nuestro repositorio en local de la siguiente manera:

  1. Mover la rama en local (color del nombre en blanco) hasta donde está la rama en remoto (color nombre en azul).

Merge

Una vez hayamos finalizado de hacer cambios en la rama y la funcionalidad esté lista para pasarla a la rama master hay que hacer un merge. Hay que seguir unos sencillos pasos para pasar la información de nuestra rama a la rama master:

  1. Click en la rama master en remoto (color del nombre en azul).
  2. Click en checkout.
  1. Click en la rama de la que quiero copiar los cambios.
  2. Click en merge.
  1. Click en la rama master en local (color del nombre en blanco).
  2. Click en push.

En este momento estamos situados en la rama master con todos los cambios de la otra rama incorporados. Una vez hacemos merge de una rama en la master no debería seguir utilizándose. Deberíamos crear una nueva rama para la funcionalidad que vayamos a empezar a trabajar.

Resolución de conflictos

A veces cuando hacemos merge surgen conflictos. Ahora mismo es el punto flojo de la interfaz gráfica de Ungit. De momento la única opción que deja es marcar el conflicto como resuelto, pero no manipularlo para decidir qué es lo que prevalece y que es lo que no. Esperamos que pronto se puedan resolver con Ungit .

Conclusión

Ungit es un sistema de control de versiones que facilita utilizar todas las funcionalidades de ungit a través de una interfaz gráfica muy intuitiva. ¿Qué te ha parecido ungit? ¡Si quieres saber más cosas sobre ungit o su uso en datalab no dudes en escribirnos un comentario!

Share on facebook
Share on twitter
Share on linkedin
Share on email
5 min
Suscríbete a nuestra newsletter

Los mejores artículos de analítica digital para potenciar tu negocio.

Deja un comentario

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

Entradas relacionadas

Todo lo que necesitas saber sobre el lanzamiento de GTM server-side

Hasta ahora, las soluciones de tag managers como GTM se basaban en inyectar una librería y procesar toda la información en el navegador, ejecutando las solicitudes de seguimiento directamente desde el lado del cliente (navegador) a servidores de terceros. Con la llegada del nuevo contenedor de GTM server-side se agrega una capa adicional de administración

BigQuery Omni: nueva herramienta multi-cloud de GCP para el análisis de datos

Lanzamiento BigQuery Omni BigQuery Omni de Google Cloud es una nueva solución multi-cloud de análisis de datos, impulsada por Anthos, la plataforma de Google que integra aplicaciones híbridas y multi-cloud.  Omni permite a los usuarios ejecutar BigQuery para analizar datos de las nubes de Amazon AWS y Microsoft Azure.  El coste de mover datos entre

Cómo el ITP de Safari afecta a tus decisiones con Google Analytics y A/B testing

Con el Intelligent Tracking Prevention o ITP, Safari restringe el uso de las cookies para el seguimiento del comportamiento de los usuarios en cualquier página web. En su versión 2.0, el ITP empezó a bloquear únicamente las cookies cargadas por servidores de terceros en todos los sitios web. Por tanto, desde que apareció esta versión,

SameSite cookies: prevención de ataques CSRF

SameSite Cookie attribute se deberá definir en las cookies HTTP para prevenir ataques Cross Site Request Forgery (CSRF) en aplicaciones web. No tener definido este atributo en la creación de la cookie implica que esta será ignorada o restringida una vez los navegadores actualicen sus versiones para mejorar los estándares de seguridad.

4 minutos

Dificultad

Ir arriba

Esta web utiliza ‘cookies’ de terceros. Al clicar aceptar está aceptando el uso que realizamos de las cookies. Para más información puede consultar nuestra Política de cookies