GitHub
Vamos a hacer una pequeña demostración de algunas de las capacidades que tiene GitHub para el control de versiones de código. GitHub es un sistema de almacenamiento de código para control de versiones y colaboración (definición comercial).
Esto es algo de lo que muchos de nosotros hacemos todos los días: colaborar con distintos equipos o compañeros, en uno o varios proyectos, pero al final hay código que pudiéramos compartir.
Es como cuando alguien se va de vacaciones y tienes que ocuparte de sus pendientes, necesitas su código. ¿Y si no te dejó el USB o el disco duro con la última versión? Eso es un poco obsoleto, lo más simple es usar Git para poder hacer esas tareas de colaboración.
Nuevo repositorio
Al grano. Previo a todo esto he creado una cuenta en https://github.com, igual que cuando crearon su cuenta en Twitter o Facebook. Una vez que tienen su usuario y contraseña, pueden entrar al portal y seguir estos pasos.
El primero de todos es crear un nuevo repositorio. Ese lugar en la nube donde van a almacenar todos sus artefactos.
Para esto basta con dar un click en el + que se muestra en la figura y seleccionar la opción para crear un nuevo repositorio.
Posteriormente, el sistema nos va a solicitar algunos datos del repositorio como nombre, descripción, si es público o privado y si queremos inicializarlo (poblarlo) con un archivo README. Al confirmar todo esto ya tendremos nuestro repositorio creado.
El repositorio se va a crear con una rama por default: master. Ésta va a ser la rama en la que se encuentra la última versión de nuestro código, la más actualizada.
Nuevo branch
Para incluir nueva funcionalidad, lo que deberíamos hacer es crear nuevos branches (sin actualizar directamente en master). En esos nuevos branches vamos a trabajar por separado, una vez que finalicemos, vamos a realizar un merge con master para incluir nuestros cambios. Cuando creamos un nuevo branch, tomaremos una foto (snapshot) de master en ese momento del tiempo. Todo el código que se encuentre en master, se copiará a nuestro nuevo branch.
En mi caso he incluido un branch llamado: branch-20170517. Aquí es donde voy a incluir mis cambios, sin alterar el master.
Basta con dar un click en el combo (justo a lado de master) y elegir la opción para crear una nueva rama o branch.
Una vez que he creado mi branch, puedo iniciar a trabajar los cambios que necesite. Para esto es muy importante asegurarnos que estamos realizando estos cambios en el branch que acabamos de crear, no en master.
Una vez que estamos seguros que estamos en el branch adecuado, vamos a trabajar los cambios. Para este ejemplo únicamente voy a modificar el archivo README que se creó inicialmente. La modificación consiste en agregar una nota en el README, pero ahora en español.
Commit (guardar)
Una vez que he realizado los cambios en mi branch de trabajo, voy a hacer un commit del mismo (guardar). El commit siempre tiene asociado un mensaje, con esto podemos tener la historia de quién hizo los cambios y porqué. Es una buena práctica colocar un mensaje claro de los cambios asociados a ese commit.
Después de haber realizado los cambios en el README, es necesario hacer un merge hacia el branch master. Recordemos que estamos trabajando en branch-20170517.
Pull request
Un pull request es la parte fundamental del concepto de colaboración en GitHub. Básicamente con un pull request le solicitamos a alguien, que haga la revisión de los cambios que hemos realizado, la descargue y haga el merge hacia su branch. En este caso estaríamos haciendo algo como lo siguiente:
branch-20140517 >> pull request >> master
Dentro del pull request va a suceder lo siguiente:
comparación >> merge (aprobación de los cambios) >> confirmación
Para crear el pull request sólo tenemos que ir al tab de la parte superior del sistema: pull request. Luego elegir el botón nuevo pull request.
Posteriormente vamos a llenar algunos datos para crear el pull request. Desde qué branch se originan los cambios (branch-20170517) y hacia qué branch se tienen que trasladar (master). También se muestran las diferencias entre ambas ramas. Una vez realizado esto, hay que presionar el botón crear pull request.
Podemos incluir algunos comentarios, indicando la razón del pull request.
Merge
Esto será enviado a un flujo de aprobación, donde alguien tendrá que hacer el merge de los cambios. En este caso como estoy usando el mismo usuario, yo completaré ambas tareas. Hasta este momento nuestro pull request estará abierto.
Algo que me pareció muy cotorro, es que puedes agregar algunas reacciones (mano arriba, mano abajo, cara feliz, gorro de fiesta). Esto le da un toque de red social a esta parte del flujo. Y puede reflejar en un ícono, nuestro pensamiento acerca de los cambios realizados en el repositorio.
El pull request va a permanecer abierto hasta que alguien apruebe (o rechace) los cambios, y posteriormente lo cierre. En nuestro caso son cambios que se pueden combinar directamente entre nuestro branch de trabajo y master, así que esto es automático. Simplemente presionamos el botón merge pull request, incluimos algunos comentarios si lo consideramos necesario y entonces el pull request quedará cerrado y nuestro branch master ya contendrá los cambios realizados al README.
En la siguiente pantalla tenemos una última confirmación del merge. Si nos queremos arrepentir, éste es el momento. Una vez presionado el botón, ya no se podrá dar marcha atrás.
Lo que nos mostrará el sistema son dos cosas: la confirmación del merge y una opción para borrar el branch. Una vez que tenemos los cambios en master, ya no necesitamos más ese branch.
Finalmente podríamos agregar algunos comentarios y/o reacciones, vemos la confirmación tanto del merge, como del borrado del branch.
Confirmación en el repositorio
Si volvemos a nuestro repositorio, vamos a poder que los cambios ya están incluídos en master.
SourceTree
Hacer esto directamente en GitHub, pudiera ser muy simple. Sin embargo, para una gran cantidad de artefactos, esas tareas de comparación y merge pueden volverse un poco complejas. O bien, si a nosotros no nos acomodan los sitios web y preferimos la línea de comandos, entonces podemos utilizar Git. O algo intermedio, un cliente de Git.
SourceTree es uno de los que me parecen muy intuitivos y completos, por detrás usa Git. Trae un Git propio, o si ustedes tienen una versión en particular previamente instalada, se puede configurar para que use la que más les convenga.
Una vez que el administrador ha creado el repositorio inicial (todos los pasos anteriores), alguna de nuestras tareas pudiera ser hacer algunos cambios (agregar, modificar o eliminar artefactos). Para eso necesitamos tener el código en nuestras máquinas o en un ambiente local. Posteriormente desarrollar, probar y subir los cambios de nuevo al repositorio. Para esto usamos SourceTree (o Git).
Clonar repositorio
Lo primero que haremos es descargar el repositorio que ya está en la nube de GitHub. Elegimos clone, colocamos la URL de nuestro repositorio de GitHub, la carpeta de destino en nuestra máquina y el nombre del branch que deseamos descargar. Presionamos el botón de clonar y esperamos la confirmación de la descarga.
Copia local
Lo anterior nos va a crear una copia local del repositorio en la ruta que indicamos. Ahí comenzaremos con los cambios.
Los cambios que hice son muy básicos: agregué un README, pero en vez de tener extensión MD (como el original del repositorio), le puse extensión TXT.
Commit
Mis cambios están listos y es hora de hacer commit. Si vamos a la sección de commit (arriba a la izquierda) de SourceTree, podemos ver varias cosas: los archivos que están pendientes por subirse al repositorio (README.txt) y el contenido (o diferencia) de lo que está en nuestra copia local y lo que está en el repositorio. Una vez que seleccionamos lo que queremos subir, presionamos el botón de commit (que está abajo a la derecha). Aquí podemos agregar nuestros comentarios del commit (al igual que lo hicimos en GitHub).
Push
Ya que hicimos el commit, los cambios no se verán reflejados en el repositorio, sino hasta hacer un push. Source Tree nos habilitará la sección de push (arriba a la izquierda). Esto nos dará oportunidad de elegir desde dónde y hacia dónde necesitamos hacer el push de los cambios. En este caso van de mi master local hacia el master del repositorio de GitHub. Esperamos la confirmación de finalización del push.
Confirmación de cambios en el repositorio
Ahora podremos confirmar que los cambios fueron colocados correctamente en el repositorio. El archivo README.txt debería estar ahí:
Cambio directamente en el repositorio
Para mostrar cómo debemos tratar cuando alguien más realiza un cambio en el repositorio, vamos a crear una clase java simple directamente en GitHub. De alguna forma SourceTree nos debe avisar que ha habido un cambio en el repositorio y que lo debemos descargar. Esto es para que siempre podamos tener la última copia del repositorio, Podríamos estar trabajando en un componente que alguien más actualizó y subió al repositorio, si no tenemos la última versión podríamos estar planchando sus cambios.
Para mostrar esto creamos la clase java en el repositorio y hacemos commit, directamente en GutHub.
Pull
Ahora veremos en SourceTree que en el botón de Pull, tenemos una marca (número) que indica que algunos cambios están en el repositorio, pero no en nuestra copia local y debemos descargarlos. Presionamos el botón de pull, confirmamos desde dónde y hacia dónde vamos a traer los cambios y finalmente esperamos la confirmación de que los cambios han sido descargados.
Confirmación en nuestra copia local
Finalmente podemos ir a nuestra copia local y confirmar que los cambios han sido descargados correctamente.
Resumen
Esta es una manera muy simple de mostrar algunas de las características GitHub, y también de cómo podemos interactuar con esos repositorios a través de Git o SourceTree, que es un cliente de Git. A partir de aquí pueden crear su propio repositorio y jugar con las estructuras, branches, merge, flujo de GitHub.
Es una inicial y muy simple aproximación a este tipo de sistemas de control de versiones y colaboración en la nube. Puede convertirse en algo muy poderoso e importante en su entorno de integración continua.
Pueden dar una mirada más a profundidad en las referencias que menciono a continuación.
Referencias
GitHub: https://github.com/
SourceTree: https://www.sourcetreeapp.com/
Git: https://git-scm.com/
No hay comentarios.:
Publicar un comentario