{"id":6,"date":"2016-03-04T22:32:19","date_gmt":"2016-03-04T22:32:19","guid":{"rendered":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/?p=6"},"modified":"2016-03-04T22:32:19","modified_gmt":"2016-03-04T22:32:19","slug":"uso-de-repositorios-git-con-sourcetree","status":"publish","type":"post","link":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/2016\/03\/04\/uso-de-repositorios-git-con-sourcetree\/","title":{"rendered":"Uso de repositorios Git con SourceTree"},"content":{"rendered":"

<\/p>\n

Este ejemplo parte de la base de que hemos creado el repositorio en gitlab.com, pero podr\u00eda ser aplicable a repositorios creados en otros servicios como GitHub, Bitbucket, etc. En \u00e9l tambi\u00e9n se da por hecho que se usa un cliente GUI para el trabajo con el repositorio, en este caso SourceTree.<\/em><\/p><\/blockquote>\n

1) Creamos el proyecto, en este caso como dec\u00edamos en GitLab lo que nos termina dando una URL de un repositorio. Para este ejemplo la URL es:<\/p>\n

https:\/\/gitlab.com\/marcosgonzalez\/uoc-basics.git<\/div>\n

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

\"demogit-01\"<\/p>\n

3) En el cuadro de di\u00e1logo pegamos la url anterior en el campo Source URL<\/strong>, y elegimos la carpeta donde almacenarlo localmente en el campo\u00a0Destination path.<\/b><\/span><\/p>\n

\"demogit-02\"<\/p>\n

4) Pulsamos el bot\u00f3n <\/span>Clone<\/b>, con esto ya tenemos una copia local del repositorio sobre la que trabajar.<\/span><\/p>\n

5) En la ventana que nos abre SourceTree con nuestros proyectos, hacemos doble clic en el denominado<\/span> uoc-basics <\/b>para acceder al mismo.<\/span><\/p>\n

\"demogit-03\"<\/p>\n

6) Veremos una ventana como esta:<\/span><\/p>\n

\"demogit-04\"<\/p>\n

7) El primer paso antes de trabajar es asegurarnos que tenemos la \u00faltima versi\u00f3n del repositorio actualizada, para minimizar conflictos cuando subamos nuestros cambios, por tanto siempre hacemos un PULL\u00a0para comenzar, como indica la anterior imagen.<\/span><\/p>\n

\"demogit-05\"<\/p>\n

Es posible que no nos muestre ninguna rama y por tanto no nos deje hacer el PULL, si eso fuera as\u00ed podemos ir al repositorio original en Gitlab\u00a0\u00a0y crear un README para que pulsando el bot\u00f3n Refresh<\/strong>, podamos acceder a la rama por defecto del repositorio: master<\/strong>.<\/p>\n

Una vez logrado esto, elegir\u00edamos la rama master y ya podr\u00edamos dar al bot\u00f3n OK, para obtener la \u00faltima versi\u00f3n de los ficheros de dicha rama en nuestra copia local.<\/p>\n

\"demogit-06\"<\/p>\n

8) Esto nos lleva a disponer de los ficheros del repositorio en nuestro equipo, e informaci\u00f3n de todos los cambios de la rama que queramos del repositorio, como se puede ver en la siguiente captura para la rama master<\/strong>:<\/span><\/p>\n

\"demogit-07\"<\/p>\n

9) Si trabajamos con los archivos del proyecto, seleccionamos la copia local (Working Copy)<\/strong> y modificamos, eliminamos o a\u00f1adimos alguno, veremos que aparecen los ficheros que han cambiado. En nuestro caso hemos modificado el archivo README.md\u00a0y creado un fichero nuevo.txt.<\/span><\/p>\n

\"demogit-08\"<\/p>\n

9) Si queremos enviar los cambios al repositorio para que queden archivados en el hist\u00f3rico de control de versiones, hemos de hacer un COMMIT<\/strong>\u00a0que se complementa con un PUSH<\/strong>\u00a0para que tengan efecto en la rama remota (en este caso master). <\/span><\/p>\n

Para ello lo primero que haremos es marcar los ficheros de \u00abUnstaged files\u00bb que queremos procesar\u00a0para\u00a0pasarlas\u00a0a \u00abStaged files\u00bb, que ser\u00e1n las que tenga en cuenta el COMMIT<\/strong>. Seg\u00fan las vamos marcando ir\u00e1n quedando como \u00abStaged\u00bb y cuando tengamos todas las que queramos (en este caso los dos cambios) podemos escribir el mensaje de COMMIT<\/strong> que queremos asociar al mismo, que ha de ser lo m\u00e1s representativo posible de los cambios que contiene.<\/span><\/p>\n

\"demogit-09\"<\/p>\n

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\u00e9s. Lo normal tras el COMMIT es lanzar el PUSH, con lo que esta opci\u00f3n es un atajo al siguiente paso.<\/p>\n

11) Como hemos dicho una vez que los cambios se han enviado al repositorio con COMMIT, veremos el indicador en el bot\u00f3n 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\u00f3n que nos muestra el siguiente cuadro de trabajo, en el que debemos pulsar OK una vez configurados los par\u00e1metros (normalmente los que ofrece son los que queremos aplicar)<\/p>\n

\"demogit-10\"<\/p>\n

Pod\u00e9is apreciar un cambio en la interfaz de las capturas, debido a que la nueva versi\u00f3n de SourceTree ha salido muy recientemente y propone una interfaz simplificada y m\u00e1s limpia. De hecho la botonera superior se ha reducido a los comandos b\u00e1sicos lo que permite menos confusi\u00f3n al trabajar con la herramienta a un nivel m\u00e1s b\u00e1sico.<\/p>\n

12) Si accedemos a nuestro repositorio en GitLab podremos ver como en el apartado Actividad refleja el push y en Commits \u00a0podemos 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\u00f3n:<\/p>\n

\"demogit-11\"<\/p>\n

Forma de trabajo habitual<\/h2>\n

Como hemos comentado, la forma de trabajo habitual es hacer siempre un PULL antes de comenzar a trabajar, y antes de cada COMMIT.\u00a0No es mala pr\u00e1ctica hacer varios COMMITS en una misma sesi\u00f3n de trabajo, pero tampoco es conveniente hacer un COMMIT a cada cambio.<\/p>\n

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\u00a0un fichero que a la hora de volcarse al repositorio, se detecta que no es la \u00faltima versi\u00f3n… 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\u00f3n que nosotros subimos no est\u00e1 cambiada sobre la \u00faltima versi\u00f3n disponible, y toca seleccionar con qu\u00e9 partes de cada zona del fichero cambiada nos quedamos para unificar los cambios de los dos miembros.<\/p>\n

Con respecto a las ramas, una buena pol\u00edtica de trabajo es crear ramas para\u00a0desarrollar bloques de funcionalidad concretos,\u00a0de manera que se pueda trabajar sobre ella con libertad, y el proceso de unificaci\u00f3n sea sobre el conjunto de los cambios una vez finalizado. De esta forma se reducen tambi\u00e9n las colisiones de c\u00f3digo entre desarrollos que no pertenecen a la misma funcionalidad.<\/p>\n

En realidad existen diferentes estrategias de gesti\u00f3n de ramas para el trabajo y cada equipo puede encontrar una mejor que otra en funci\u00f3n de la tipolog\u00eda del proyecto y de la propia manera de trabajar sobre el repositorio, aunque en equipos peque\u00f1os estas estrategias pierden relevancia al simplificarse bastante la probabilidad de conflictos y trabajos simult\u00e1neos.<\/p>\n

Uno de los recursos m\u00e1s reconocidos para la gesti\u00f3n de ramas de forma avanzada es lo que se conoce como Git-flow (de Vincent Driessen)<\/a> que se puede encontrar explicado en el siguiente art\u00edculo en espa\u00f1ol: http:\/\/aprendegit.com\/que-es-git-flow<\/a><\/p>","protected":false},"excerpt":{"rendered":"

Este ejemplo parte de la base de que hemos creado el repositorio en gitlab.com, pero podr\u00eda ser aplicable a repositorios creados en otros servicios como GitHub, Bitbucket, etc. En \u00e9l tambi\u00e9n se da por hecho que se usa un cliente GUI para el trabajo con el repositorio, en este caso SourceTree. 1) Creamos el proyecto, … <\/p>\n

Seguir leyendo \u00abUso de repositorios Git con SourceTree\u00bb<\/span><\/a><\/p>\n","protected":false},"author":49,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[4,5,6],"class_list":["post-6","post","type-post","status-publish","format-standard","hentry","category-tutoriales","tag-git","tag-repositorio","tag-workflow","entry"],"_links":{"self":[{"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/users\/49"}],"replies":[{"embeddable":true,"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":8,"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/posts\/6\/revisions"}],"predecessor-version":[{"id":33,"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/posts\/6\/revisions\/33"}],"wp:attachment":[{"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/media?parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/categories?post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/multimedia.uoc.edu\/blogs\/frontend\/wp-json\/wp\/v2\/tags?post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}