Integración de GitHub / Git / GibHub Desktop y MS Visual Studio Code

0
746

Antes de empezar me gustaría que revisases el tutorial anterior:

Primeros pasos con TypeScript con Microsoft Visual Studio Code

Y ver este video de 2 minutos para entender donde estamos y a donde vamos.

Para tener registrados todos los cambios que hacemos a nuestros documentos podemos trabajar con un repositorio de documentos.

Este repositorio puede estar en local lo que nos permite trabajar a nosotros solos.

Si queremos trabajar de un modo colaborativo con otra gente lo suyo es tener un repositorio en un servidor y sincronizar con él, tanto nosotros cómo otras personas.

Hay muchas opciones en el mercado y una de las más extendidas es Git.

GitHub es un entorno en la nube que nos permite crear repositorios remotos y, gracias a Git, podemos trabajar en local y coordinarnos con ese repositorio remoto. De ese modo tenemos la capacidad de salvaguardar nuestro trabajo (todas las versiones relevantes para nosotros) y coordinarlos con el de otra gente.

Primero veamos cómo podemos crear un repositorio en GitHub y luego explicamos otros conceptos básicos.

Vamos a

https://github.com/ y nos creamos una cuenta o rescatamos una muerta, como es mi caso.

Vamos inicialmente a trabajar en la página Web de GitHub que es más sencillo para entender los conceptos sin otras complejidades.

Creamos un repositorio (agrupación que representa un directorio realmente), público inicialmente. Le decimos que nos cree un fichero README.TXT con el que vamos a jugar.

Ahora vemos que el repositorio está creado y tenemos nuestro fichero.

Vamos a visualizar el fichero y editarlo

.

Al final de la página vamos a hacer commit y guardar el fichero de nuevo en el repositorio. Esto es la parte final de la pantalla anterior.

Podemos comprobar el histórico de cambios del fichero e incluso rescatar todas las versiones anteriores.

Bien, ahora vamos a aclarar algunos conceptos para no equivocarnos, sobre todo cuando trabajemos en nuestro ordenador.

Digamos que tú puedes irte a tu ordenador y crear un fichero. Este, cada vez que le das a guardar, pisa al anterior, por lo tanto solo conservas el último.

También puede utilizar un software de gestión de versiones, que puedes instalar en ese ordenador, y crear un repositorio en el directorio donde has creado tu fichero.

Es decir, que el sistema de control de versiones inserta unos ficheros adicionales para que un directorio normal se convierta en un repositorio controlado por Git.

Ahora bien, cuando tú edites tu fichero con un editor normal, simplemente estas tocando la ultima versión de tu fichero donde digamos que el repositorio sabe que lo estas tocando pero no se da por enterado. Es decir, que tienes que actuar para, a efectos de ese repositorio, decir si quieres confirmar los cambios (commit) o descartarlos. Puedes por ejemplo estar todo un día o varios días tocando un fichero y hacer el commit al final del día o ir haciendo poco a poco dándole nombres por si quieres en algún momento volver a una versión concreta.

Imagínate que tu mismo te conectases en remoto desde otro ordenador a ese repositorio Git que está en tu ordenador. Para todos los efectos  los últimos cambios que has hecho en el fichero que estas tocando directamente con un editor no existe para Git, el sabe el último commit que hiciste nada más. Lo que tú no le has notificado no existe para él y no se lo puede contar a otras partes.

Por tanto una cosa es el fichero que yo edito y otro la versión última que tienes confirmada el repositorio.

Ahora vamos a introducir otra variable y es que si quiero trabajar con una tercera persona, podemos tener un servidor central de repositorios, como es GitHub donde más de un usuario se puede conectar.

Por tanto los pasos son los siguientes. En GitHub creo un repositorio, y supongamos este solo tiene un README.TXT. Si alguien quiere trabajar con ese repositorio tiene que instalarse git en su máquina. Entonces puede descargarse el repositorio en un git local. Este repositorio está formado por ficheros ocultos en un directorio que lo habilitan para controlar versiones. Así que tenemos 3 versiones del mismo fichero. La del servidor remoto, que puede estar tocando alguien. La primera versión descargada de la copia del git local y la física que puedo editar en el sistema de ficheros, conceptualmente hablando.

Cuando toque el fichero local lo tendré que guardar en el disco duro. Una vez guardado (cada vez que quiera compilar), cuando considere oportuno (unas veces al día) tendré que hacer commit en el git local (dandole un nombre a la entrega) y posteriormente tendré que decirle a mí git local que transfiera los cambios al git remoto, al origen.

No os preocupéis que luego todo es más fácil de lo que parece.

Si seguimos con nuestro hola mundo, como entenderéis pueden pasar varias cosas. Que yo me lo descargue a mí git local. No lo toque en un rato y que cuando lo toque otro día y lo suba alguien más ya lo haya tocado. Por tanto se pueden producir conflictos.

Podemos hacer que todo el mundo trabaje sobre los mismos ficheros (rama principal) y que se produzcan los conflictos lo antes posible. Cuanto más rápido todos tratemos de integrar nuestro código en un repositorio menores serán los conflictos. No es igual que la gente sincronice cada media hora que cada quince días.

Otro modo de trabajar es crear una rama (branch) o variación de todos los ficheros. De ese modo imaginad que mucha gente está tocando REDME.TXT, nosotros hacemos nuestros cambios y solicitamos al administrador del repositorio que visualice los cambios e integre (merge).

Bueno, veréis que esto tiene algo de teoría que es conveniente estudiar. Por eso os recomiendo que vayáis a la documentación y la leas un poco que está bastante bien explicado.

También comprenderéis que hay muchos modos de abordar el problema de trabajo colaborativo con un código que está formado por miles de ficheros, con muchas personas a la vez, pero eso ya son asuntos avanzados.

De momento os dejo en enlace a la documentación para que veáis esquemas explicándolo

https://guides.github.com/activities/hello-world/

Vamos ahora a volver a tocar el fichero README.TXT pero ahora creando una rama (branch) fuera de la master (principal).

Modificamos el fichero.

Al final de la página le damos a el nombre de la rama.

 

Entonces ya entendemos los conceptos anteriores. Hemos grabado el fichero, creado una rama y hecho commit pero, para que se pueda integrar en la rama principal hay que notificarle al administrador del repositorio que la integre (pull request).

Cuando vemos que tenemos una petición y no entra en conflicto con la rama principal podemos decirle que las mezcle y que unifique.

Y podemos observar el resultado.

En el histórico podemos ver las ramas y matarlas si ya no nos aportan valor. Aunque obviamente recomendaría dejarlas un tiempo.

Ahora, para entender mejor la diferencia entre el repositorio remoto y el repositorio local y tener un asistente visual para manejar GitHub vamos a instalar GitHub Desktop que podéis encontrar en https://desktop.github.com/

Realmente nos os hace falta para nada porque entre el id y los comandos git lo hacemos todos pero así es más visual.

Lo descargamos, instalamos y metemos nuestras credenciales de la cuenta de GitHub.

Podemos hacer varias cosas. Descargarmos un repositorio a local, se denomina clone.

Elegimos el repositorio remoto y le decimos en qué directorio local queremos crearlo. Por tanto, nos creará un directorio y nos bajará la última versión de ficheros (último commit) de los qué disponga.

Podemos ver el histórico de ficheros.

Editamos con el editor por defecto el fichero antes de hacer nada en nuestro entorno de desarrollo para que veáis los conceptos.

En este caso es MS Visual Studio Code. Cambiamos alguna línea y guardamos.

Detecta que ha habido cambios pero recordar que hay que hacer commit para que se de por enterado (en master). Hay que hacer commit a master (abajo a la izquierda).

Pero ahora está en el repositorio Git de nuestra máquina, y hace falta hacer un push a GitHub.

Y vamos comprobando en GitHub lo que va pasando, simplemente refrescando.

Con esto ya podéis jugar, sin complicaros la vida con el compilador con GitHub en la Web y con GitHub Client en el cliente. Yo me tiraría un rato haciendo cambios, provocando conflictos de versiones y viendo lo que va pasando.

Entonces podemos asumir que habrá un dueño del repositorio de código (el que lo crea) y administrará las pull-request de otros usuarios.

Ahora bien, lo que nos interesa es instalarlo en nuestro editor de código, IDE o compilador para hacer el trabajo más sencillo. Veréis que luego ni eso, sino que se montan los proyectos ajenos a los IDEs con otros productos que se encargan de controlar el ciclo de vida: dependencias, compilación, lanzamiento de pruebas, empaquetamiento, distribución de código.

Os recomiendo visitar este video donde se muestran todos los pasos para usar GitHub en MS Visual Studio Code, es de Raghav Pal 

Primero nos vamos a bajar Git para Mac.


Mi equipo es Mac

macOS Catalina
Versión 10.15.2

MacBook Pro (15-inch, 2018)
Procesador 2,9 GHz Intel Core i9 de 6 núcleos
Memoria 32 GB 2400 MHz DDR4
Gráficos Intel UHD Graphics 630 1536 MB


 

Arrancamos el instalador y ya sabeis ok, ok

Ahora desde la línea de comando ejecutamos “git —version” para asegurarnos que está instalado.

Nos vamos ahora a MS Visual Studio Code. Desde las opciones Shift+Command+P escribimos Git Enabled para comprobar que la propiedad está marcada.

Ahora nos vamos a GitHub Desktop y le decimos crear un nuevo repositorio. Ojo que como la carpeta de trabajo ya la tenemos creada solo tenemos que poner el trayecto de la carpeta padre y dar el nombre del repositorio el de nuestra carpeta de trabajo existente donde tenemos los ficheros TypeScript.

Por tanto, queda habilitada nuestra carpeta como carpeta de repositorio controlada por Git. Ahora desde GitHubDesktop solo tenemos que pulsar la opción de hacer Push y todos los ficheros de nuestro proyecto subirán.

Le damos a Push y revisamos los ficheros a GitHub.

De todos modos esto no hace falta hacerlo de GitHub Desktop, lo podemos hacer directamente en nuestro entorno de desarrollo que será lo normal.

Si ahora cambiamos cualquier fichero en nuestro IDE veremos que aparecen los colores del control de versiones.

Si vamos a la barra de menú lateral, tercera opción que es un dibujo representando ramas,  podremos ver que hay cambios en ficheros que están dentro del repositorio Git.

Podemos darle un nombre al commit y pulsar el icono del check.

Realmente hay tres arboles de ficheros en nuestra máquina (más el del servidor remoto): el directorio de trabajo, los ficheros provisionales para el siguiente commit (stage) y el histórico (el último commit). Os recomiendo leer este artículo que lo explica muy visual.

https://marklodato.github.io/visual-git-guide/index-es.html.

Podemos decirle a nuestro IDE que hagamos de un paso el commit de ficheros con los ficheros cambiados y los que están provisionales.

Recordad que estamos haciendo commit de los ficheros del repositorio local, como ya he explicado. Ahora si queremos que se mande al servidor GitHub hay que decírselo, hacer un push.

Solo para que lo veáis me voy a GitHub Desktop y nos aparece una operación pendiente de push a origen.

Para hacerlo dentro del entorno, si miráis los puntos suspensivos al lado del check, aparece un menú con todas las opciones contra el repositorio.

Parece que no ha sido tan buena idea poner el lenguaje en castellano porque entonces nos liamos con los verbos.

Lo vamos a devolver a ingles. Me voy a cambiar las propiedades. Pulsamos Shift+Command+P y escribimos Display Language

Elegimos “en” para ingles.

Y arrancamos de nuevo el IDE.

Ya se entiendo todo mejor, contra-intuitivamente.

Si ejecutamos Push desde nuestro IDE la primera ves nos aparecerá una ventana para introducir el usuario y contraseña del repositorio de GitHub. Introduciéndolo tendremos sincronizados repositorios.

Podemos irnos ahora a GitHub y comprobar que todo está funcionando.

Y podemos ver el histórico de versiones y de cambios en cada push.

Bueno, ya tenemos cuenta de GitHub, Git instalado, los repositorios creados y el MS Visual Studio Code configurado.

Ahora los siguientes pasos serían aprender un poquito de TDD, para sentar unas buenas bases de desarrollo, e instalar los productos para formatear correctamente el código, transpira, etiquetar, ejecutar los test y empaquetar la aplicación,  desplegando donde proceda.

Aquí te dejo el enlace al siguiente tutorial:

Instalación de Jest con TypeScript y MS Visual Studio Code

 

Dejar respuesta

Please enter your comment!
Please enter your name here