Uso de repositorios Git con SourceTree

Este ejemplo parte de la base de que hemos creado el repositorio en gitlab.com, pero podría ser aplicable a repositorios creados en otros servicios como GitHub, Bitbucket, etc. En él también se da por hecho que se usa un cliente GUI para el trabajo con el repositorio, en este caso SourceTree.

1) Creamos el proyecto, en este caso como decíamos en GitLab lo que nos termina dando una URL de un repositorio. Para este ejemplo la URL es:

2) Abrimos SourceTree (o la aplicación que hayamos decidido usar para trabajar con el repositorio) y accedemos a New repository > Clone from URL, para disponer de una copia local con la que trabajar.

3) En el cuadro de diálogo pegamos la url anterior en el campo Source URL, y elegimos la carpeta donde almacenarlo localmente en el campo Destination path.

4) Pulsamos el botón Clone, con esto ya tenemos una copia local del repositorio sobre la que trabajar.

5) En la ventana que nos abre SourceTree con nuestros proyectos, hacemos doble clic en el denominado uoc-basics para acceder al mismo.

6) Veremos una ventana como esta:

7) El primer paso antes de trabajar es asegurarnos que tenemos la última versión del repositorio actualizada, para minimizar conflictos cuando subamos nuestros cambios, por tanto siempre hacemos un PULL para comenzar, como indica la anterior imagen.

Es posible que no nos muestre ninguna rama y por tanto no nos deje hacer el PULL, si eso fuera así podemos ir al repositorio original en Gitlab  y crear un README para que pulsando el botón Refresh, podamos acceder a la rama por defecto del repositorio: master.

Una vez logrado esto, elegiríamos la rama master y ya podríamos dar al botón OK, para obtener la última versión de los ficheros de dicha rama en nuestra copia local.

8) Esto nos lleva a disponer de los ficheros del repositorio en nuestro equipo, e información de todos los cambios de la rama que queramos del repositorio, como se puede ver en la siguiente captura para la rama master:

9) Si trabajamos con los archivos del proyecto, seleccionamos la copia local (Working Copy) y modificamos, eliminamos o añadimos alguno, veremos que aparecen los ficheros que han cambiado. En nuestro caso hemos modificado el archivo README.md y creado un fichero nuevo.txt.

9) Si queremos enviar los cambios al repositorio para que queden archivados en el histórico de control de versiones, hemos de hacer un COMMIT que se complementa con un PUSH para que tengan efecto en la rama remota (en este caso master).

Para ello lo primero que haremos es marcar los ficheros de «Unstaged files» que queremos procesar para pasarlas a «Staged files», que serán las que tenga en cuenta el COMMIT. Según las vamos marcando irán quedando como «Staged» y cuando tengamos todas las que queramos (en este caso los dos cambios) podemos escribir el mensaje de COMMIT que queremos asociar al mismo, que ha de ser lo más representativo posible de los cambios que contiene.

10) Una vez seleccionados los ficheros y escrito el mensaje podemos enviar el COMMIT, y como se indica en la captura anterior, marcar incluso que se traslade a la rama en el origen correspondiente con un PUSH inmediatamente después. Lo normal tras el COMMIT es lanzar el PUSH, con lo que esta opción es un atajo al siguiente paso.

11) Como hemos dicho una vez que los cambios se han enviado al repositorio con COMMIT, veremos el indicador en el botón de PUSH que existen elementos por trasladar a la rama en el origen (en este caso master). Si queremos que tengan efecto debemos hacer PUSH mediante dicho botón que nos muestra el siguiente cuadro de trabajo, en el que debemos pulsar OK una vez configurados los parámetros (normalmente los que ofrece son los que queremos aplicar)

Podéis apreciar un cambio en la interfaz de las capturas, debido a que la nueva versión de SourceTree ha salido muy recientemente y propone una interfaz simplificada y más limpia. De hecho la botonera superior se ha reducido a los comandos básicos lo que permite menos confusión al trabajar con la herramienta a un nivel más básico.

12) Si accedemos a nuestro repositorio en GitLab podremos ver como en el apartado Actividad refleja el push y en Commits  podemos ver los existentes y en cada uno de ellos navegar para ver los ficheros implicados y los cambios realizados. Haciendo clic sobre el texto del commit, podemos ver dicha situación:

Forma de trabajo habitual

Como hemos comentado, la forma de trabajo habitual es hacer siempre un PULL antes de comenzar a trabajar, y antes de cada COMMIT. No es mala práctica hacer varios COMMITS en una misma sesión de trabajo, pero tampoco es conveniente hacer un COMMIT a cada cambio.

Si todos los miembros del equipo trabajan de esta forma se reducen las probabilidades de que se den situaciones que requieran de un MERGE, que se produce cuando un miembro del equipo modifica un fichero que a la hora de volcarse al repositorio, se detecta que no es la última versión… es decir mientras hemos hecho cambios en un fichero, otro miembro del equipo lo ha modificado y vuelto a subir, por lo que la versión que nosotros subimos no está cambiada sobre la última versión disponible, y toca seleccionar con qué partes de cada zona del fichero cambiada nos quedamos para unificar los cambios de los dos miembros.

Con respecto a las ramas, una buena política de trabajo es crear ramas para desarrollar bloques de funcionalidad concretos, de manera que se pueda trabajar sobre ella con libertad, y el proceso de unificación sea sobre el conjunto de los cambios una vez finalizado. De esta forma se reducen también las colisiones de código entre desarrollos que no pertenecen a la misma funcionalidad.

En realidad existen diferentes estrategias de gestión de ramas para el trabajo y cada equipo puede encontrar una mejor que otra en función de la tipología del proyecto y de la propia manera de trabajar sobre el repositorio, aunque en equipos pequeños estas estrategias pierden relevancia al simplificarse bastante la probabilidad de conflictos y trabajos simultáneos.

Uno de los recursos más reconocidos para la gestión de ramas de forma avanzada es lo que se conoce como Git-flow (de Vincent Driessen) que se puede encontrar explicado en el siguiente artículo en español: http://aprendegit.com/que-es-git-flow