Skip to content
Pablo Riutort edited this page Oct 17, 2018 · 11 revisions

Qué es Git y qué no es Git

Git, ese gran desconocido

Git es un sistema de control de versiones creado por el mismísimo Linus Torvalds.

Un sistema de control de versiones es básicamente un control del historial de archivos. Dicho historial puede ser modificado mediante los comandos de Git.

GitHub es una página web que hace un hosting gratuito de Git, al igual que BitBucket y muchos otros servicios web. Estas webs no son Git.

Repositorio
Un sitio donde se guardan cosas.

Diff y Patch

Los abuelos del control de versiones

Antiguamente no existía nada de control de versiones y los programadores tenía que trabajar bastante a pelo. Los comandos de git están basados en programas básicos que todavía podemos encontrar en nuestra terminal.

  • diff - compare file line by line.

  • patch - apply a diff file to the original.

Ya se ve por dónde van los tiros. Si aplicamos un diff en dos archivos, este programa nos sacará las diferencias línea a línea, por ejemplo, imaginemos que tenemos los siguientes archivos:

  • jack.txt:
Mucho trabajar y poco jugar  
hacen de Jack un chico aburrido.
  • stewie.txt:
Mucho trabajar y poco jugar
hacen de Stewie un chico aburrido.

Si aplicamos diff jack.txt stewie.txt:

2c2
< hacen de Jack un chico aburrido.
---
> hacen de Stewie un chico aburrido.

Vemos que nos saca por pantalla las diferencias entre los dos textos, en este caso en la segunda línea.

La notación de diff incluye 2 números y un carácter entre ellos:

d – a line was deleted
c – a line was changed
a – a line was added

El número de la izquierda hace referencia a la línea del primer archivo y el número de la derecha del segundo.

Con esto sabemos encontrar las diferencias entre dos archivos, los cambios que ha habido entre ellos, ahora entrará en juego el comando patch.

patch aplica los cambios de un archivo diff en el original. El archivo diff lo generamos redirigiendo la salida con >:

diff jack.txt stewie.txt > diferencias.patch

Ahora tenemos el resultado del diff en el archivo diferencias.patch, para aplicar estos cambios sobre jack.txt hacemos:

patch jack.txt < diferencias.patch

Y si finalmente abrimos el archivo jack.txt, veremos que se han efectuado nuestros cambios:

Mucho trabajar y poco jugar 
hacen de Stewie un chico aburrido.

Empezando un repo

Instalación y primeros pasos

¡Ya estamos preparados para empezar un repositorio!

  1. Instalamos Git: sudo apt-get install git
  2. Iniciamos Git en una carpeta que deseemos trackear con git init
  3. Configuramos nuestras credenciales: git config user.name AulaLinux; git config user.email aulalinux@uib.es.

En este punto deberíamos ver la carpeta .git ejecutando ls -a. Dentro de este directorio se encuentra todo el repositorio de Git, si se borra entonces la carpeta deja de ser un repositorio y pasa a ser un directorio normal.

Un repo consta de dos partes, la local y la remota.

La local es la de tu ordenador personal, la remota es de un servidor, en este caso usaremos nuestro repo de GitHub.

Git puede "sincronizar" tus cambios del repo local con el remoto, así otro programador podrá verlos o incluso tú mismo en otro ordenador y siempre tendrás una copia en la nube.

Para conectar nuestro repositorio local con el remoto necesitamos una url, la de este repositorio es: https://github.com/AulaLinux/Git-Capacitor.git

git remote add origin https://github.com/AulaLinux/Git-Capacitor.git

Lo que hace este comando es habilitar el repositorio remoto llamado origin (aunque podrías llamarlo como quieras).

¡Ahora nuestro repo local y el remoto ya está conectados!

Clonar un repositorio

The easy way

Si lo que queremos es bajarnos un repositorio que ya existe, lo tenemos fácil con git clone <url_repo>.

Y configuramos nuestras credenciales: git config user.name AulaLinux; git config user.email aulalinux@uib.es.

Estructura de Git

Git no es más que un grafo dirigido (dígrafo), en concreto un árbol.

Esta es la estructura de un repositorio cualquiera de Git:

  • commit: Son los nodos del grafo.

  • ramas: Es un posible recorrido del grafo a partir de un nodo. A las ramas se les ponen nombres, generalmente a la principal se la llama master.

  • HEAD: Es un puntero que dice dónde está el útimo commit.

El commit

El commit es la estructura más importante de Git, un commit es el punto de referencia de los cambios que hay en el repositorio. Cada commit representa un cambio en el repositorio y en un conjunto de archivos.

Un commit sigue la siguiente estructura:

Los commits sólo pueden ver a su commit padre.

  • hash: Es el identificador del commit.

  • autor: Por eso es importante crear unas credenciales, un commit tiene que tener un nombre de autor y un email.

  • fecha: Obviously.

  • mensaje: Describe el cambio que introduce el commit en el repo. Escribir comentarios útiles es quizá lo más importante del commit.

Git < commit < mensaje = El mensaje es lo más importante.

Ciclo de los archivos

¡Todos a escena!

Trabajar con Git es muy similar a hacer una película o una obra de teatro, hay hasta un escenario.

Un archivo puede tener 4 estados en un repositorio (Realmente puede tener más estados, pero por ahora trabajaremos con estos):

  • untracked: Es el estado por defecto de un archivo. Git todava no sabe qué hacer con él.

  • staged: El archivo está sobre el escenario.

  • unmodified: El archivo está igual que en el último commit.

  • modified: El archivo ha sido modificado desde el último commit.

lifecicle

Los archivos están en el repositorio, luego pueden salir a escena y si han cambiado desde la última escena entonces pasan a estar modificados. Si decidimos grabar el escenario estaremos haciendo un commit y quedará registrado el cambio.

Todos estos cambios quedan registrados sobre la rama en la que se hacen

Ignorar archivos

A veces no queremos que nuestros archivos pertenezcan al repositorio, pero son necesarios para el proyecto: un archivo de configuración, un archivo de base de datos, un xml inútil etc.

Para que estos archivos no queden trackeados con Git, existe un archivo especial llamado .gitignore. En él guardamos el path de los archivos que no queramos que Git trackee para que entre en el ciclo de los archivos.

.gitignore:

base_de_datos.sql
contraseñas.txt
lista_compra.md

Si no existe el archivo deberemos crearlo nosotros mismos, Git sabrá qué hacer

Workflow

  • git status: Comprueba el estado de un repostiorio.

  • git add <path> | --all: Añade un archivo al repositorio para que sea trackeado y lo pasa al escenario (stage). También se pasan archivos al escenario si han sido modificados desde la última vez. --all añade todos los archivos no trackeados.

  • git commit -m <mensaje> <path>: Crea un commit de lo que hay en el escenario.

Ahora introducimos comandos de Git que interactúan con el repositorio remoto.

  • git pull <repositorio_remoto> <rama_remota>: Sincroniza o baja los cambios del repositorio remoto a nuestro repositorio local.

  • git push <repositorio_remoto> <rama_remota>: Sincroniza o sube los cambios locales con los del repositorio remoto.

Es buena práctica hacer siempre un pull antes de un push.


Cosas interesantes para aprender más sobre Git

Hasta aquí un tutorial muy básico para que puedas empezar con Git desde 0 hasta 88mph, pero Git tiene muchísimo más:

Cosas serias


Git-Capacitor

Para un demostración práctica, visita la página de Git-Capacitor de esta misma wiki.