Tutorial sobre Git, github y los VCS

Git es un sistema de control de versiones (VSC). Fue diseñado por Linus Torvalds, el creador de Linux. Nos permite hacer fácil la gestión del código y por lo tanto el desarrollo general de cualquier aplicación. Además, podemos conectarlo con los repositorios externos (Github, gitlab, bitbucket...) para tener nuestro código disponible en cualquier parte.

Podemos utilizar Git en todos los sistemas operativos. Para descargarlo tan solo tenemos que buscar en Google: "Git + Sistema Operativo".

Un commit es cada uno de los cambios del repositorio. No hagas un commit solo por cada archivo, si no por cada característica añadida (aunque puede ser solo un archivo) y documentarla bien. Más adelante, en la parte de local repository, veremos más sobre esto.

Una rama o branch son lineas paralelas de nuestro propio repositorio. Se crean ramas para que en la principal el código esté limpio. Si la rama funciona correctamente la añadimos a la principal (merged branch), sino podemos seguir trabajando con ella o simplemente dejarla o borrarla. Hay varios tipos de ramas según su uso. Las principales son las ramas para añadir características (features) y las ramas para arreglar errores (bugs).

Así que creamos una nueva rama (branch), añadimos una característica y hacemos un commit.

Ahora nos vamos a basar en el diagrama de Git para explicar todos los conceptos, partes y sus características. Se divide en:

• Working Directory
• Staging Area
• Local repo
• Remote repo

Working Directory

Para comenzar, el Working Directory es nuestra carpeta local en donde trabajamos y editamos los archivos. Puede tener el nombre que queramos y estar localizada en donde queramos de nuestro ordenador. Por ejemplo, en la siguiente imagen puedes ver que mi Working Directory está en el Escritorio y se llama 1. Este es mi directorio donde trabajo.

Al comenzar el proyecto tenemos que tener claras el tipo de proyecto que vamos a realizar. Para ello tan solo tienes que preguntarte: ¿Quiero poder acceder desde cualquier parte al repositorio (puede ser tanto publico como privado) o quiero solo tener una copia en mi ordenador? Si tu respuesta es la primera entonces haz el siguiente paso, si es la segunda ve al final y mira las notas.

Al comenzar un proyecto lo primero es crear el repositorio online (Remote repository) para ello vamos a Github, Gitlab o Bitbucket (hay muchos más, puedes ver una larga lista y su comparación aquí). Nosotros vamos a utilizar Github. Creamos una cuenta o accedemos a la que ya tenemos y pulsamos en la derecha sobre el icono + para crear un repositorio. Añadimos el nombre del repositorio y podemos poner opcional la descripción, crear un README (muy recomendado para ir documentando el repositorio), un .gitignore (en este archivo es para que no suba ciertos archivos, por ejemplo todos los que contengan ciertos datos como los .log o uno en concreto) y especificar una licencia de código abierto.

Una vez creado tenemos que pasarlo a nuestra carpeta local Working Directory y para ello vamos al botón verde. Como ya tenemos instalado Git vamos a utilizarlo. Para ello copiamos la URL que nos da el botón verde. Abrimos una terminal en nuestra carpeta local y escribimos git clone y la URL anterior.

Como podemos ver en nuestra carpeta local ya se han descargado los archivos de inicio. Recuerda entrar en la nueva carpeta desde la terminal para continuar, puedes utilizar un cd nombre-carpeta-del-repo. En mi caso cd Prueba-repositorios.

Staging Area

El Staging Area es el lugar donde vamos a ir añadiendo archivos cuando terminemos de editarlos. Es un paso intermedio, en el podemos ir añadiendo archivos hasta que ya queramos subirlos al repositorio, por ejemplo, si hemos actualizado varios archivos relacionados pero no queremos subir otros, solo los seleccionados.

Este paso que en a simple vista no tiene mucho sentido, ¿Por que no subimos los archivos directamente al repositorio y ya?, tiene su razón y sus muchas ventajas.

1. Control y detección de cambios. Todos los archivos que vamos subiendo al staging area vamos a poder ver los cambios que hemos realizado en ellos. Si hemos añadido lineas de código, esas lineas van a tener un símbolo + delante, si por el contrario hemos quitado lineas lo que veremos es el símbolo -.
2. Es más eficiente. Hace un cacheo en los archivos antes de subirlos.
3. Añadimos metadatos.

Como ejemplo vamos a crear un archivo llamado Nuestro-primer-documento.txt. Para comprobar los archivos del directorio podemos utilizar en la terminal el comando git status. Y nos saldrá el archivo que acabamos de crear, informándonos que hay archivo que no esta en nuestro repositorio remoto y que lo añadamos a la staging area con un git add. Y es lo que vamos a hacer. Después de hacerlo, si realizamos cambios en ese archivo vamos a poder ver los cambios, el control y detección de cambios, con un git diff.

También podemos utilizar un git add . para añadir todos los archivos modificados de la carpeta local pero de donde estemos, por ejemplo, podemos estar en una subcarpeta. Y un git add --all para añadir todos los archivos modificados de toda la carpeta local.

Y utilizamos el git rm --cached Nombre-archivo para eliminar del staging area si no queremos subirlo al final.

Local repository

Luego tenemos el repositorio local, es el repositorio en de nuestro ordenador donde se van a almacenar los archivos.

Para pasar los archivos del staging area al repositorio local utilizamos el comando git commit. Podemos hacerlo de varias maneras.

• Si hacemos un git commit sin añadir nada nos va abrir el editor de texto para que añadamos un poco de texto que luego se va a mostrar en el repositorio, se suele añadir los cambios realizados, por ejemplo, añadí una nueva fuente y cambié la tipografía web.
• Si hacemos un git commit -m "Añadí una nueva fuente y cambié la tipografía" va a tener el mismo efecto que el anterior pero nos ahorramos el editor de texto.
• Podemos indicar los archivos que queremos subir del staging area. Si no queremos subir todos podemos hacer git commit Nuestro-primer-documento.txt y luego sin nada para el editor de texto y con -m para indicar el comentario sin él.

Ya tenemos nuestros archivos y código en nuestro repositorio local. Podemos ver los archivos de él con el comando: git ls-tree

Lo que hace un commit es básicamente agrupar todos los archivos que hemos añadido y dar la orden de confirmar sus cambios.

Remote repository

Por último, subir nuestro repositorio local a la nube, subirlo a un repositorio remoto online. Así lo puedes tener disponible desde cualquier lugar del mundo. Y es muy útil para trabajar con compañeros, tanto de forma pública como privada.

Tan solo tenemos que ejecutar el comando git push y ya podemos ir a nuestro repositorio de Github para ver los cambios en el repositorio.

Vale, hasta aquí todo bien, pero no es mi usuario de Github.

Eso es por que no estas verificado con las GPG. Qué no te asusten esas siglas, tan solo son una serie de números y letras que se utiliza para verificar tu propia firma digital y también sirven de cifrado.

Vale, vale, pero como utilizo esa GPG. La respuesta depende de tu propio sistema operativo: Aquí. En resumen tienes que generar la GPG directamente con Git o con un programa y añadirla en Github.

Notas:

En el primer paso, podemos crear manualmente la subcarpeta del proyecto y utilizar git init para crear un proyecto en local en vez de crearlo en remoto con Github.

Puedes utilizar un git log para ver los commits de cada repositorio, junto con su hash, autor, fecha exacta y comentario.