Primeros pasos con Source Tree

7
93263

En esta ocasión hablaremos de Source Tree, una herramienta tanto para Git como para Mercurial (aunque esta prueba es para Git) para trabajar con estos sistemas de versionado de forma gráfica.

0. Índice de contenidos.

1. Introducción

Una de las partes más importantes a la hora de realizar un proyecto consiste en tener un lugar centralizado en el que todo el equipo pueda acceder a la información del mismo. Para esto, el uso de un sistema de control de versiones (como GIT) es imprescindible.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 17′ (2.8 GHz Intel Core 2 Duo, 8GB 1067 MHz DDR3, 256GB Solid State Drive).
  • NVIDIA GeForce 9400M 256 MB
  • Sistema Operativo: Mac OS X Yosemite Version 10.10.2
  • GIT version 2.3.2 (Apple Git-55)
  • Source Tree 2.0.5.2

3. Instalación

La instalación está cubierta en un tutorial previo realizado por Roberto llamado: Integrando Xcode4 con GitHub

4. Clonación de repositorio a local

Una vez instalado nos aparecerá una ventanita con las opciones básicas:

Donde podemos ver de izquierda a derecha:

  • Local: Todos los proyecto que tenemos actualmente en local.
  • Remote: Los proyectos que están actualmente en remoto, ordenados por repositorios (En la imagen se muestra esta pestaña, donde se ve como el primer repositorio no tiene ningún proyecto, mientras que el segundo tiene dos proyectos asociados).
  • + New Repository: Nos da la opción de crear un repositorio local o remoto, así como añadir un repositorio local existente, o clonar un repositorio remoto a local.
  • Un buscador.
  • Boton de opciones, donde podemos añadir nuevas cuentas y nuevos repositorios, así como actualizar la ventana.

Clonando el repositorio obtenemos una copia del mismo en local. Para realizarlo supondremos que tenemos un proyecto creado dentro de un repositorio. En nuestro caso se llama adictosTree.

El comando de git asociado es:

      git clone [url]
    

Actualizamos la ventana de Source Tree para que aparezca, en el botón de opciones -> Refresh

Como podemos observar, ahora aparece el proyecto que tenemos en remoto, pulsamos en clone y configuramos la ventana emergente:

Donde:

  • Source URL: Es la ruta a tu repositorio(rellenada automáticamente)
  • Destination Path: Ruta local en la que se clonará tu repositorio
  • Name: Nombre del repositorio

En las opciones avanzadas puedes elegir la rama (branch) que quieres clonar a local. Al pulsar el botón clone, llegamos a la ventana principal de source tree. ¡Ya tenemos nuestro repositorio remoto clonado a local!



5. Subida de proyecto desde local al repositorio remoto

Pero, ¿qué pasa si tenemos un repositorio local y queremos establecerlo en remoto?
Source Tree también nos ofrece la posibilidad de configurarlo para este fin.

Accedemos a la ventana inicial de Source Tree y vamos a la pestaña local:

Aquí vemos el proyecto que hemos creado anteriormente, que ya está en local. Ahora vamos a crear un nuevo proyecto. Para ello cogemos la carpeta del proyecto y la arrastramos a la ventana de Source Tree, con la pestaña local seleccionada. Nos saldrá una ventana con:.

  • Destination Path: ruta del proyecto desde donde lo hemos arrastrado.
  • Name: el nombre que va a tener el proyecto.
  • Type: el tipo de sistema de versionado a utilizar.
  • Checkbox de creación de repositorio externo a la vez, que no marcaremos.

NOTA: Aunque salga el check de "Also create a remote repository", nosotros crearemos el repositorio en dos pasos.

Para que este repositorio sea publicado en remoto, hacemos click derecho sobre él, y seleccionamos "Publish to remote…", dónde deberemos especificar el lugar del repositorio local(por defecto será el lugar desde donde hemos arrastrado la carpeta), el nombre del repositorio y el tipo, que en nuestro caso será git.

En este nuevo desplegable configuramos:

  • Account: que cuenta de GitHub quieres utilizar para crear el repositorio.
  • Owner: el propietario de la cuenta.
  • Name: el nombre que va a tener ese repositorio en remoto (suele llamarse igual).
  • Description: descripción opcional para definir el proyecto.
  • Type: tipo de repositorio.
  • Un checkbox que indica si es un repositorio privado o público. En nuestro caso lo desmarcamos ya que usamos el servicio gratuito de Git, que solo permite la creación de repositorios públicos.

Ahora si accedemos a nuestra pestaña remote en source tree, comprobaremos como el repositorio ha sido creado.


6. Operaciones básicas de versionado con Source Tree

En los dos pasos anteriores hemos visto las dos formas de crear un repositorio, ya sea clonando uno existente, o creándolo a partir de un proyecto local para poder trabajar con ellos. Ahora veremos las principales herramientas de Source Tree. Para el ejemplo que estamos manejando actualmente, nos es indiferente usar un proyecto u otro, así que usaremos adictosTree. Empecemos echándole un vistazo a la interfaz:

Comenzando por la barra lateral, echemos un vistazo a los elementos más relevantes:

  • File Status: Como su nombre indica muestra el estado de los ficheros. Siempre que cambiemos algo en algún fichero, cuando pongamos el foco en la ventana del Source Tree, aquí se verán reflejados los cambios en los ficheros. Como este es el proyecto que queremos subir de local al remoto, aquí aparecen todos los archivos del proyecto, ya que aunque el repositorio remoto se ha creado, ningún dato ha sido enviado todavía. Esta pestaña se corresponde con el siguiente comando de git:
  •       git status
        
  • Branches: Nos indica las distintas ramas de trabajo.
  • Remotes: Aquí se encuentran los distintos repositorios remotos(Origin por defecto), así como las ramas de trabajo que están en ellos.
  • La información de «Branches» y «Remotes» se puede ver en git con el comando:

    git branch -a

En la barra superior aparecen las acciones principales que solemos hacer con git: Commit, Checkout, Reset, Stash, Remove, Add/Remove, Fetch, Pull, Push Branch, Merge y Tag

Ahora procedemos a realizar un push de la aplicación. Previamente, hemos tenido que modificar, crear o eliminar algún fichero previo del proyecto. Una vez hecho, nos vamos a Working Copy. Una vez en esta ventana, en la parte inferior aparecen los unstaged files, ficheros que han sido modificados, creados o destruidos, pero que no están en el repositorio local(STAGE). Para añadirlos, simplemente tenemos que pulsar en Add en el menú superior, o en el check encima de todos los ficheros para añadirlos de golpe. Esto en línea de comandos se corresponde con:

    git add [nombre-fichero]
  

Ahora realizamos un commit, para añadir estos ficheros al repositorio local, y nos saldrá una ventana en la parte inferior, cuyo contenido es:

  • Commit options: donde podemos decidir entre distintas opciones del commit, como la de deshacer un commit por defecto.
  • Caja de texto: en la que se introduce el comentario del commit.
  • Check para push: para hacer un push inmediatamente después del commit.

Esta pequeña ventana es equivalente al comando:

    git commit -m "Primer commit de la aplicación adictosTree"
  

Si nos vamos al apartado Branches del menú lateral, veremos que ha salido la rama principal por defecto master. en esta ventana encontraremos la información más importante a la hora de hacer un seguimiento de las versiones que vayamos subiendo al repositorio.

  • Graph: nos muestra de forma visual como se están desarrollando las distintas ramas(lo comprobaremos cuando hagamos una nueva branch)
  • Description: indica los repositorios que se encuentran en esta versión, así como la descripción que se puso al commit. En este caso, la rama master local, y la rama master del remoto(origin/master) están en la misma versión.
  • Commit: muestra el id del commit realizado, para tener controlado las distintas versiones que va teniendo git del repositorio
  • Author: nos indica el autor del commit, así como su correo electrónico.
  • Date: indica la hora y la fecha a la que se hizo el commit.

A continuación crearemos una nueva rama, modificaremos un fichero del proyecto tanto en la rama principal como en la rama creada, y haremos un merge de la misma. El objetivo es ver como nos muestra las diferentes ramas el grafo de la aplicación, así como ver como realizar estos dos comando básicos de git.

Para crear una nueva rama de trabajo, basta que pinchar en Branch en el menú superior. Esto desplegará la siguiente ventana:

En esta ventana puedes configurar:

  • Current Branch: indica la rama en la que estamos actualmente.
  • New Branch: indica el nombre que va a tener la nueva rama.
  • Commit: Un checkbox que indica desde que commit quieres realizar la creación de la rama nueva(por defecto desde donde se encuentre la rama actual).
  • Checkbox que indica si quieres realizar un checkout de la rama creada.

Tal y como hemos creado rama 1 se corresponde a los comandos de git de:

    git checkout -b rama1
  

Tras pulsar el botón "Create Branch", observamos como en el menú de la izquierda, en Branches se nos ha creado nuestra nueva rama. También podemos observar como en la descripción aparece esta nueva rama en el commit actual, que es el que hemos elegido.

Ahora procedemos a realizar cambios en esta rama, para luego realizar un merge(comprobaremos los cambios realizados en el menu izquierdo, en working copy)

Una vez modificado el archivo o creado uno nuevo, vamos a nuestro working copy y realizamos un commit en la rama creada rama1.

Comprobamos el estado actual de las ramas en el graph:

Antes de realizar el merge, vamos a modificar el fichero desde la rama principal, para que veamos como se ven reflejados estos cambios en el grafo que nos muestra a aplicación. Para ello, hacemos un cambio de rama, a la rama principal (master) simplemente haciendo doble click en la rama del menú de la derecha (comprobamos como ahora el nombre en negrita es master).

Esto es correspondiente al siguiente comando de git:

    git checkout master
  

Modificamos el fichero desde la rama principal y hacemos un commit (comprobar como el contenido del fichero a la derecha no se corresponde con el contenido que tenía el fichero al hacer el commit en la rama1):

Si ahora observamos el grafo, podemos comprobar como nos muestra las distintas ramas que están siendo creadas. Observar también como al modificar el fichero en la rama principal, este se encuentra una versión por delante del que se encuentra en remoto (1 ahead):

Gracias a la herramienta gráfica podemos ver de forma visual las ramas en las que estamos trabajando, así como los cambios realizados en cada una de ellas leyendo los commits en la parte inferior.

Para finalizar, realizaremos un merge de rama1 a master, y subiremos los cambios al servidor remoto(recordad que toda la creación de las ramas ha sido en local, ya que no hemos hecho ni un solo push). Para realizar un merge, basta con pulsar el botón merge en el menú superior.

En esta ventana observamos como tenemos que elegir una rama para que se una a nuestra rama actual(nosotros estamos actualmente en master). Por lo que solo tenemos que seleccionar la rama en el grafo. Dejamos la opción por defecto de que realice un commit si no han surgido conflictos, y aceptamos.

Como era de esperar, nos ha surgido un conflito debido a la modificación del mismo fichero en dos ramas diferentes, así que saldrá un mensaje de aviso como el siguiente:

Para resolverlo, lo más común es ir al archivo en conflicto, y resolver el error manualmente, aunque si tienes claro que versión del archivo quieres dejar, en working copy, hacer click derecho en el archivo, y tienes una opción de resolución de conflictos, que te da las opciones tanto de conservar el fichero de tu rama, de la rama ajena, o abrir un editor externo para resolver el conflicto.

En nuestro caso resolvemos el error manualmente, y hacemos un commit y un push de la aplicación, como habíamos visto previamente, siendo el resultado:

Para finalizar, si ya hemos terminado con la rama, la eliminamos haciendo click derecho en la rama a eliminar, y seleccionando la opción Delete [nombre rama].

En comandos sería equivalente a:

    git branch -d [nombre-rama]
  

Con esto ya habríamos visto las principales funcionalidades de Source Tree. Tiene muchas más herramientas, ¡te aconsejo encarecidamente que trastees un poco con la interfaz!

7. Conclusiones

En resumen:

  • ¡Dile adiós a la línea de comandos!. Usando la aplicación de escritorio puedes manejar todos tus repositorios, tanto locales como remotos a través de una interfaz simple.
  • Simplifica el control de versiones para el equipo. Operaciones como create, clone, commit, push, pull y merge solo con par de clicks.
  • Es bueno tanto para los que están iniciandose, como para los más expertos.

8. Referencias

7 COMENTARIOS

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad