Si te dedicas o te interesa el mundo del desarrollo, seguramente hayas oído hablar de Git o GitHub. Estas herramientas pueden facilitar la vida para los desarrolladores pero saber qué es lo que hacen exactamente qué diferencias hay entre ellas puede llegar a ser algo confuso.
En este post vamos a ver cómo utilizar Git para manejar el código de nuestro repositorio así como el funcionamiento de las diferentes ramas que podamos necesitar. Y todo esto utilizando GitHub para publicar nuestro repositorio de manera pública de tal forma que otros desarrolladores también puedan contribuir.
¿Qué es Git y GitHub?
Git es un software de control de versiones diseñado en su día por Linus Torvalds. Permite a varios desarrolladores crear y modificar código de manera conjunta manejando el versionado, las evoluciones del código y las diferentes ramas de desarrollo.
GitHub es un servicio de repositorios en la nube basado en Git.
¿Cómo creamos un repositorio remoto en GitHub?
Accede a GitHub. Aquí podemos hacer login (de manera gratuita para uso personal), y de esta forma poder crear y gestionar nuestros repositorios.
Para crear un repositorio deberemos definir un nombre válido y un tipo de acceso (público o privado). Será necesario iniciar el repo para poder utilizarlo. Al hacerlo se generará la rama “main”, que es a donde subiremos nuestro código por defecto.
Ahora bien, para el uso de los comandos Git para la sincronización de nuestro código con el repositorio, necesitaremos descargar el cliente para entornos Windows, Mac y Linux, lo cual podremos hacerlo mediante este enlace.
¿Cómo obtenemos la ruta remota de un repositorio para copiarlo a nuestro equipo local?
Para poder empezar a trabajar necesitaremos clonar un repositorio a local. Para ello accederemos al repo y seleccionaremos “code”, y bajo la pestaña de ‘clone’, nos dará la ruta remota del repo y será la que usemos para la clonación.
** Git admite diferentes protocolos: https://, git:// o bien user@server:path/to/repo.git.
Esta información la utilizaremos más adelante cuando comencemos a clonar el repositorio a local.
Y ahora empezamos con Git, la parte divertida 😉
Lo primero de todo es entender cómo funciona git. Básicamente el sistema de git se compone de 3 partes:
- Directorio de trabajo: es el directorio de nuestro equipo que contiene los ficheros (nuestro código, por ejemplo).
- Index (o stage o chache): es una zona intermedia donde se registran los ficheros que modificamos y que se enviarán en nuestro próximo commit.
- Repositorio: es donde se almacenan nuestros cambios y que podremos sincronizarlo con uno remoto.
** HEAD: que referencia al último commit realizado (la última versión de nuestro código de nuestra actual rama que se añade al repositorio).
Si ejecutamos el comando git con la opción “add” se registrarán los cambios en el index.
Si posteriormente ejecutamos la opción “commit” se añadirán esos cambios a nuestro repositorio local.
Y si finalmente queremos subir los cambios a nuestro repositorio remoto de GitHub, tendremos que ejecutar la opción “push”.
Otro concepto importante para entender es el de las ramas o branches.
Las ramas se utilizan para desarrollar funcionalidades aisladas (unas de otras) y en su conjunto representan nuestro proyecto.
Lo habitual es trabajar con la rama de ‘develop’, por ejemplo, pero también se pueden crear otras ramas para hacer desarrollos paralelos, como por ejemplo una para ‘feature’, ‘hotfix’ …o similar.
¡Vamos a la práctica! Cómo usar Git
Si ejecutamos “git –version” desde nuestro sistema nos indicará la versión actual y además podremos comprobar que esta correctamente instalado. Si ejecutamos ‘git –help’ nos mostrará la ayuda y sus comandos.
Para clonar un repo a local, deberemos posicionarnos en la ruta donde queremos alojar nuestros repos, por ejemplo un directorio de trabajo, y desde ahí ejecutar el comando:
~]$ git clone https://<remote_github_server>/<my_user>/<my_repo>.git
O bien, si queremos clonarlo a una carpeta diferente:
~]$ git clone https://<remote_github_server>/<my_user>/<my_repo>.git myfolder
Una vez clonado, accederemos y podremos ver su contenido y las ramas creadas (o también llamadas branches):
~]$ git branch
# o bien:
~]$ git branch -v
incluso con ‘-vv’
Como buenos programadores, no deberiamos hacer cambios en la rama ‘main’ así que crearemos una rama de desarrollo que llamaremos ‘develop’.
~]$ git branch develop
Y cambiaremos a dicha rama:
~]$ git checkout develop
** Si ejecutásemos el comando ‘git checkout -b <branch_name>’ crearíamos la rama y nos cambiaríamos a ella directamente.
Si quisiéramos eliminar una rama creada (por ejemplo ‘dev2’), ejecutaríamos el comando:
~]$ git branch -d
Una vez que estemos en la rama deseada, cualquier cambio que hagamos (modificación de código o ficheros), se verá reflejado. El comando ‘git status’ nos muestra si se han producido cambios en los ficheros y ‘git diff’ las líneas modificadas:
~]$ git status
~]$ git diff
~]$ git diff develop origin/develop
# para ver las diferencias antes de publicar los cambios.
Si quisiéramos llevarnos esos cambios a la cache (o stage), tanto las modificaciones como la creación de nuevos ficheros o su borrado, deberemos ejecutar:
~]$ git add [|]
o bien:
~]$ git add.
Posteriormente será necesario enviar esos cambios a nuestro repositorio local, para lo cual deberemos ejecutar:
~]~]$ git commit -m “<mensaje descriptivo>”
Si volvemos a revisar el estado de nuestros cambios veremos cómo ha cambiado la salida:
~]$ git status
Si nos hubiéramos equivocado con el mensaje o quisiéramos rectificar algunos cambios, podríamos utilizar la opción ‘ammend’, para lo cual deberemos ejecutar:
~]$ git commit –amend -m “<nuevo mensaje>”
** La opción ‘ammend’ nos permite corregir únicamente nuestro último ‘commit’. Si se nos hubiera olvidado añadir algún fichero también podríamos utilizarlo después de un ‘git add’.
Y si quisiéramos subir la información de nuestra nueva rama (que no existía en el servidor) para que la puedan utilizar otros desarrolladores:
~]$ git push -u origin develop
Para posteriores subidas de nuestros cambios podríamos omitir la opción ‘-u’ (abreviatura de –set-upstream-to):
Y una vez hecho esto, cualquier integrante del equipo podría descargarse nuevamente nuestros cambios escribiendo desde dentro de su copia local del repositorio:
~]$ git pull
# si no existen cambios, nos lo notificaría
Si esta nueva persona quisiera revisar las modificaciones que se han realizado en nuestro repositorio, podría ejecutar:
~]$ git log
~]$ git log –oneline
# para mostrar la información en versión abreviada
~]$ git log –graph
# para mostrar un gráfico de las ramas
Si quisiéramos ver los cambios de un commit concreto podríamos ejecutar:
~]$ git show <id_commit>
¿Cómo revertimos los cambios en Git?
Si hiciéramos cambios que hubiésemos añadido al stage (git add) podríamos revertirlos con el comando:
~]$ git rm –cached <file_name>
Una vez realizado se puede ver como el fichero README vuelve a estar en estado ‘untracked’.
Seguimos avanzando con nuestro desarrollo, volvemos a modificar ficheros, ejecutamos un ‘git add’ y un ‘git commit’ y ejecutamos un ‘git diff develop origin/develop’ para ver las diferencias entre nuestra rama local de ‘develop’ y la remota:
Si ya hubiésemos enviado los ficheros a nuestro repositorio local (git commit), podríamos volver a la versión previa con el comando:
~]$ git checkout HEAD~1 <file>
# o bien mediante:
~]$ git revert HEAD
Y si ya hubiéramos publicado los cambios a nuestro repositorio remoto, podríamos volver a un commit previo mediante la opción ‘reset. Este parámetro admite 2 opciones: ‘soft’ (mantener los cambios locales) o ‘hard’ (sin mantenerlos).
~]$ git reset –hard HEAD~
Con la opción ‘reset’ tenemos la capacidad de mover nuestra rama de desarrollo a un commit concreto, bien indicando el ID de dicho commit o con ordinal del HEAD, ahora bien, también modificará el historial de los commits:
** Git referencia cada confirmación con un hash SHA-1 de 40 dígitos, pero para la mayoría de los mensajes informativos usa una forma más amigable y abreviada (01d3d6d) de 7 dígitos. Con el comando ‘git log’ o ‘git show’ se puede ver el hash completo:
¿Cómo fusionamos la parte de main con la parte de desarrollo?
¿Cómo haríamos un ‘merge’ entre la rama de main y ‘develop’? ¡Muy fácil! 😎
Tendremos que posicionarnos en la rama de destino y solicitar el merge desde ahí. Sería así:
~]$ git checkout main
~]$ git merge develop
De esta forma los cambios que tuviéramos en la rama ‘develop’ se integrarían en la rama ‘main.
¿Cómo se crea un repo en local?
Para hacer esto tendremos que crear una carpeta para nuestro repo en local e inicializarlo:
~]$ git init
Y agregar un repositorio remoto:
~]$ git add remote origin https://<remote_github_server>/<my_user>/<my_repo>
Y lo podríamos revisar mediante el comando:
~]$ git remote -v
¿Cómo se usa Git Stash?
Esta opción nos permite, en caso de conflictos o si queremos pausar una línea de desarrollo, guardar en un espacio reservado los cambios que tuviéramos hechos y volviendo al último commit, de tal forma que podamos volver a restaurar las modificaciones de ese espacio reservado cuando lo consideremos oportuno. La sintaxis sería:
~]$ git stash save “mensaje”
# para guardar nuestros cambios en un espacio reservado.
~]$ git stash show
# muestra los cambios que hubiera en el espacio de trabajo.
~]$ git stash list
# muestra los espacios reservados creados.
Para restaurar los cambios de ese espacio de trabajo tenemos 2 opciones:
- Pop: restaura los ficheros y elimina el stash después de hacer un commit
- Apply: restaura los ficheros pero mantiene el stash.
Una vez hecho, se indican con unas marcas las partes del código que se modificaron.
¿Y si creamos una nueva rama a partir de un commit pasado?
Si ejecutamos el comando ‘git log’, podríamos identificar un commit y utilizarlo para hacer un cambio a esa ‘rama’.
Posteriormente solo tendríamos que crear una nueva branch y ya tendríamos una nueva línea de desarrollo 😉
Información adicional para convertirte en todo un experto
En lo referente a los repositorios existen 2 ficheros para tener en cuenta:
- README.md: Es el estándar para crear documentación sobre nuestros desarrollos hecho en markdown. En futuros artículos os hablaremos más sobre ello. 😉
- .gitignore: Es un fichero plano de texto que indica que ficheros o directorios se deben excluir de nuestros proyectos.
Tienen una sintaxis muy sencilla. Simplemente debemos indicar el patrón o los nombres completos de los archivos que se excluirán.
Un ejemplo sería este:
# ignore txt files
*.txt
Pero si quisiéramos incluir un fichero concreto previamente excluido, podríamos hacerlo con el signo de exclamación
!my_data.txt
O por ejemplo podríamos usar un patrón similar a esto:
# Ignore debug0.log, debug1.log … debug9.log
debug[0-9].log
# Ignore any LOG folder
**/log
Si hubiéramos realizado un commit (antes de crear nuestro fichero .gitignore) y hubiéramos añadido algún fichero no deseado, podríamos eliminarlo del repositorio con el siguiente comando:
~]$ git rm –-cached <file_name>
Git en sí es todo un mundo, pero con un rato de lectura se le puede perder el miedo y puedes comenzar a utilizarlo. Espero que con lo que os he contado tengáis para empezar. Así que os animo a que exploréis todas sus opciones y las pongáis en práctica.
Santander Global T&O es una compañía del Grupo Santander con más de 3.000 empleados y basada en Madrid, trabajamos para convertir al Santander en una plataforma abierta de servicios financieros.
Mira las posiciones que tenemos abiertas aquí para unirte a este equipazo y Be Tech! with Santander
Síguenos en LinkedIn y en Instagram.
Javier Gómez
Santander Global T&O
Ingeniero de sistemas con más de 20 años de experiencia en diferentes roles como arquitecto de sistemas, gestionando soluciones de virtualización de Apps & VDIs y proporcionando soluciones end-to-end, así como administrando sistemas y automatizando tareas mediante PowerShell.
Me considero una persona inquieta y un infatigable explorador del universo IT, que ha sabido hacer de su trabajo su pasión.
