Hola Git y GitHub*!

*GitHub y GitLab

$ whoami:

Me llamo Elena y soy Adalaber.

He trabajado como programadora y maquetadora de front, y he hecho un máster en JavaScript y NodeJS en Fictizia. Actualmente estoy redirigiendo mi carrera.

Liada en OSW (Open Source Weekends) y Hackmadrid27%

Twitter: @lpez_elena

GitHub: elenamlopez

LinkedIn: https://www.linkedin.com/in/elena-mateos-lopez/

Control de Versiones

... control de qué?

¿Te suena?

Una versión no es una copia literal

Esa carpeta de Git tan misteriosa y que no se debe tocar, tiene un archivo donde se guardan tan solo las cosas que se cambian.
Linea X en un archivo, cambia "cucu" por 'cucucucucucuc '

Diferentes estados de tu archivo

Working area: Pues como bien dice, el momento en el que estás trabajado. Escribiendo tus cosas, borrando...
Stagin Area: Oye esto ya me mola, creo que lo debería guardar...
Commit: ¡¡¡ Ala guardao !!!!

Vamos a ver como se hace

Meter en Stagin Area:

1. git status:

```
$ git status
```

Git status nos dice el estado en el que se encuentran nuestros archivos. Si están sin seguimiento, si tienen seguimiento pero se han cambiado o si están en Stagin ya.

Meter en Stagin Area:

Añade el archivo que le pasemos a stagin area, y que luego estará en el commit.

```
$ git add <nombre_archivo>
```

Meter en Stagin Area:

```
$ git add .
```

Este comando agrega todo lo que se haya cambiado a Stagin Area.

Busca más formas de agregar a stagin =)

Hacer un commit

Con este comando hacemos un commit de los archivos que estén en stagin area.

Se hace una instantanea de los archivos en ese momento y se agrega a la cabecera (HEAD) quedando registrado y guardado como un punto en el tiempo con un número SHA de referencia.

$ git commit -m "Mensaje de tu commit"

Listar los commits.

Nos mostrará un log o histórico de commits realizados en este repositorio.

Copiarlo en un archivo de texto o similar puede ser una gran idea si piensas viajar en el tiempo de tu histórico...

Para salir de ahí pulsa q!

```
$ git log
```

Viajar en el tiempo

```
$ git checkout <codigo_sha>
```

Viajar en el tiempo

Nos lleva al estado del repositorio en ese momento.

Para volver a donde estábamos tienes que coger el código SHA en el que te encontrabas.

No creas que viajo mucho en el tiempo...

```
$ git checkout <codigo_sha>
```

El archivo .gitignore

1. .gitignore:

Es un archivo, en el que se ponen las carpetas y archivos de los que no deseamos que Git haga un seguimiento.

Por ejemplo aquellos archivos y carpetas con información sensible como tokens, o carpetas de instalación como node_modules.

#History files

.Rhistory

.Rapp.history

etc...

El archivo .gitignore

Todo lo que pongas en el archivo .gitignore,

será ignorado por git

Y recuerda....

Todo tiene solución en Git.

Si te lías, rompes algo, subes lo que no debías, comiteas sin querer algo que no debías comitear... Has hecho un rebase forzado y la has liado parda...

¡¡¡ TODO SE PUEDE SOLUCIONAR EN GIT !!!

No tiene solución en git...

No se puede deshacer, porque se pierde la referencia totalmente, si haces eso sin haber guardado un commit, perderás (para siempre y doy fe) todos los cambios que hayas hecho.

El por qué aquí

```
$ git checkout .
```

Las ramas son buenas

No tengas miedo a las ramas...

¿Qué es una rama?

Toma el estado en el que se encuentra el archivo y hace una derivación a otro espacio, de forma que se puede trabajar en él sin afectar al archivo inicial.

Más adelante podemos juntarlos.

Ejemplo de ramas

Crear una rama:

git branch <nombre_rama>

Por ejemplo: git branch mi-rama

Cambiarse a esa rama:

Por ejemplo: git checkout mi-rama

* Hay un comando para crear una rama y moverse directamente a ella:

$ git checkout -b <nombre_de_tu_rama>

```
$ git checkout <nombre_rama>
```

Trabaja en tu rama

Dentro de tu rama puedes trabajar normal, hacer tus commits y avanzar en el proyecto, pero lo que haces está sólo en esa rama.

Si cambias de rama sin más lo que hayas hecho en esa rama no lo vas a ver.

Para poder juntar todo tienes que mergear (fundir o fusionar) las ramas...

Mergear:

```
$ git merge nombre_rama
```

1. Situandonos en la rama a la que queremos mergear los cambios de otra, poner en consola:

Cuando mergeas pueden pasar dos cosas:

1. Todo se ha hecho bien y no hay problemas.

2. Cada uno ha tocado el mismo archivo por su cuenta y al mergear las ramas dan conflicto. Git no sabe que cambios son los que han de permanecer, y lo junta pero con conflicto, y te pide que los soluciones...

Ejemplo de conflicto:

Resolver conflicto:

En un mundo ideal lo suyo es ponerse de acuerdo en que hace cada uno. En caso de conflicto sentarse con la persona con la que nos ha surgido y determinar qué es lo que vale.

Pero si no es así toma una decisión , haz un Pull Request y solicita revisión de la persona con la que tienes el conflicto o espera a poder hablar con ella. Intenta no romper nada... X)

Resolver conflicto:

Una vez hecho esto, los pasos son los que siguen:

Resolver el conflicto.
Commitear cambios.
Comprueba que todo está ok y que en tu rama están los cambios finales.
Subirlos (más adelante veremos dónde).

Resolver conflicto ejemplo:

Ramas famosas:

develop ó dev

feature/loquesea

bugfix/esePeasoBug

hotfix/ayQueEstáEnProducción

master....

Esquema de ramas

Ya has acabado commit y hay que subirlo...

A la rama donde estás... ¿vale?

Para que el commit que vas a hacer quede ligado a un Issue en concreto:

Para que el commit que vas a hacer cierre un Issue en concreto:

```
$ git commit -m "blablablaa #nºissue"
```

$ git commit -m "blablablaa Fix#nºissue"

```
$ git push origin nombre_de_la_rama
```

Y no olvides...

Estando en develop:

Una vez tienes ya todo guardado y subido, mergea tu rama a donde corresponda, por ejemplo develop:

Pasos:

1. Hazte pull de la rama donde vas a meter tu rama.

2. Muévete a la rama donde vas a llevar tus cambios.

3. Haz merge de tu rama a la rama donde estás.

```
$ git merge rama_a_mergear
```

Las ramas molan pero...no seas un Diógenes...

Mantener la higiene de ramas es algo importante. Si no vas a desarrollar una segunda release, o incluso un proyecto paralelo... cuando acabes con el trabajo de una rama... ¡¡¡MÁTALA!!! muaaahahahahahha... kill it, kill it...

```
$ git branch -D nombre_rama
```

Buena higiene:

Mala higiene:

Hello git?

GitHub

Uno de los tableros de juego

Disclaimer:

El mundo es genial, hasta que llega Windows..., con un poco de terapia he superado el shock post-traumático.

Representación gráfica de mi persona cuando MrCodeDev me dio la noticia... Una noche dura

¿Qué es eso de subir el repositorio a dónde?:

Cuando el código está tan solo en tu ordenador, es lo que se llama 'repositorio local' o 'tener el repositorio en local'. En principio sólo tu tienes acceso.

Cuando el código lo subes a internet, ya sea en Github o cualquier otra plataforma es cuando se habla del 'repositorio remoto', o 'repositotio en remoto'

Tu repo en local y remoto...

Tienes tu código en tú maquina, y sólo lo ves tú, pero puedes subirlo a un repositorio remoto.

Hay varios sitios donde hacerlo, pero nos vamos a fijar de momento en GitHub. (... y GitLab ...)

Con GitHub (... y GitLab ...) podemos compartir nuestro código y trabajar con otras personas. También podemos tener nuestro código alojado.

Tiene versión gratuita y de pago (... y GitLab también).

Bienvenida de GitHub

GitHub Pages:

settings/options

selecciona la rama en la que tienes tu versión para publicar

GitHub:

Cuando tienes un repo en remoto:

git pull origin nombre_de_la_rama
Si hay conflicto resuelve y commitea
git push origin nombre_de_la_rama

En resumen:

Cuanto más actualizada tengas la rama donde estás y tu repo, menos conflictos tendrás.

ANTES DE HACER PUSH HAZ PULL

Y en caso de incendio

GitLab

Otro tablero de juego

Otro disclaimer:

No nos engañemos... esto estaba alojado en Azure... Que ahora se han cambiado a Google Cloud

Es Open Source y puedes montarte tu propio servidor de GitLab en casa... pero eso es otra historia ;)

GitLab Overview:

Que se parece muuucho

Salvo algunos detalles tiene muchas cosas similares:

Respecto a operativa es igual
Alta sencilla
Versión gratuita y de pago

Además es Open Source

Bienvenida de GitLab

Inicio:

Menú de usuario:

Profile:

User Settings:

GitLab Pages:

Es algo más complejo que GitHub...

Pero os dejo unos vínculos para investigar:

https://www.youtube.com/watch?v=TWqh9MtT4Bg
https://www.youtube.com/watch?v=dD8c7WNcc6s

No tengáis miedo y probad cuando os veáis mas sueltos con la herramienta

GitLab:

Cuando tienes un repo en remoto:

git pull origin nombre_de_la_rama
Si hay conflicto resuelve y comitea
git push origin nombre_de_la_rama

En resumen:

Cuanto más actualizada tengas la rama donde estás y tu repo menos conflictos tendrás.

ANTES DE HACER PUSH HAZ PULL

¿Agregar repos remotos?

¡Sí se puede!

En consola poner:

¡¡¡¡¡ Cuando hagas push, recuerda hacerlo a ambos !!!!!!

(o tendrás un bonito caos...)

```
$ git remote add nombre_para_remoto url
```

¿Preguntas?

Esto es un vídeo de búhos por si en este punto la desesperación es patente...

^.^

Hora de mancharse las manos y jugar con git

¿Qué vamos a hacer?

Cuenta en GitHub.
Crear un repositorio en GitHub.
Forkear un repositorio.
Configurar Git (en tu ordenador)
Modificar configuración inicial.
Crear un repositorio en local.

Ingredientes:

Cuenta de email.
Ordenador con Git instalado.
- (¿Cómo instalar Git?)

Cuenta de GitHub

Bienvenida de GitHub

Crear un repositorio de GitHub

Mejor ponerle README... y licencia

Forkear un repositorio de GitHub

Básicamente te haces una copia del repositorio en tu GitHub

Configurar Git

Configurar git:

$ git config --global user.name "nombre"

Mejor usar tu usuario de GitHub

$ git config --global user.email "tu_mail@example.com"

Comprobar que está todo ok:
- ```
$ git config --list
```

En local...

Modificar la configuración inicial:

Tan solo repetir los pasos:

$ git config --global user.name "nombre"

Mejor usar tu usuario de GitHub

$ git config --global user.email "tu_mail@example.com"

Comprobar que está todo ok:
- ```
$ git config --list
```

Crear un repositorio en local

Navegar con la terminal hasta dentro de la carpeta que queremos:
- ```
$ git init
```

Clonar un repositorio de GitHub en local

Crear un repositorio en local dentro de la carpeta taller_git_archivos, pero trayéndolo de GitHub
Ve a tu cuenta de github, y haz click en el repositorio que te acabas de forkear:
- ```
$ git clone <url del proyecto>
```
- La url la cogemos de la ventana que sale al pulsar el botón de 'Clone or download':

Cuenta de GitLab

Nuevo repo en GitLab

Aquí vemos el vínculo para añadir un remoto o clonar en local

Gestión de conflictos...

Lo ideal es que no se den... pero se van a dar.

Si tienes un conflicto ¡No entres en pánico!
Es bueno tener papel a mano para anotar cosas.
Intenta siempre hablar con la persona que ha hecho el código con el que has tenido conflicto.
Fíjate SIEMPRE en lo que dice la consola, da muchas pistas.
Un plugin en el editor que uses, puede ser una gran ayuda.

Gestión de conflictos...

Ten siempre MUY en cuenta que es lo que has hecho tu, y que es lo que viene de afuera

Si no lo haces puedes tener un buen lío...

Y recuerda CASI TODO EN GIT tiene solución

Gestión de conflictos...

Evitar conflictos absurdos antes de que se den:

La guía de estilos para el código no es tonteria. Esos espacios vs. tabs... que rompen relaciones.
¿A cuanto tenemos fijadas las tabulaciones?
Comillas simples... comillas dobles... mejor todos igual

PONERSE DE ACUERDO TE QUITARÁ DOLORES DE CABEZA

¡Crear una Issue!

y asignarla, dotar de tags...

Crear una ISSUE:

Esta es la página principal de GitHub

Crear una ISSUE:

Ir a la pestaña 'Issues', veremos esto:

Crear una ISSUE:

New Issue y... ¡A jugarlo!

Pull Request!

También conocido como... PR

¡Hacer PR mola, y que los acepten más!

Es mejor que un PR no dé conflicto, más que nada para que lo acepten.

¡Si buscas revisión dilo!

¿Cómo se hace?

Has trabajado en tu rama, has commiteado, y si vas a GitHub verás un botoncito nuevo ...

Aquí está el commit, fixeando una issue...

Y aquí el botón para hacer PR

¡Dale al botón!

Luego verás esto

Si tienes permiso sobre el repo claro...

Y finalmente...

¡Al turrón!

En parejas ;P

¡Al turrón!

En parejas ;P

¿Qué voy a hacer?

Es importante entender que todo lo que hago para simular ser otra persona no es en absoluto necesario para Git.

Olvidaros totalmente del tema de levantar máquinas virtuales ni el tener que lidiar con dos cuentas de github, o otras historias similares.

*Lo realmente importante es que voy a ser dos personas al mismo tiempo XD

¿Qué vamos voy a hacer?

Forkear un repositorio.
Dar permisos a otra persona.
Crear una rama.
Hacer un PR.
Mergear una rama.
Resolver un conflicto

Compi 1 (Hello

Forkear el repo para la práctica

Visita la página del repositorio:
- https://github.com/ElenaMLopez/Banana_oh_la_la
Dar al botón que pone Fork

Dar permisos en un repo

Settings / Collaborators

El Compi 1 da permiso a su compañer@ en su repositorio de GitHub recien forkeado.

Aceptar permisos

El Compi 2 debe aceptar los permisos, puede llgar un email o bien desde la plataforma de github en notificaciones

Clonar el repo de Copmpi 1

Cambiaros en local a la rama practica

En la consola poned:

git checkout practica

(no uséis nunca ni tildes ni caracteres extraños en los nombres de las ramas, tipo 'ñ' o 'ß'...)

Compi 1

Crea una rama llamada compi1 desde la rama practica:
1. git checkout -b compi1
Elimina el archivo index.html
Renombra el archivo index-participante1.html a index.html
Elimina el archivo style.css
Renombra el archivo style-participante1.css a style.css
Haz un commit y mira como se ve la página de tu repo local.
Sube tu commit a la rama compi1 de github:
1. git push -u origin compi1
2. Con este comando se sube el commit y se crea en remoto la nueva rama

Compi 1

Realiza un PR desde la rama compi1 a la rama practica en github:

Compi 1

Compi 2

Crea una rama llamada compi2 (desde la rama practica en local):
1. git checkout -b compi2
Elimina el archivo index.html.
Renombra el archivo index-participante2.html a index.html.
Renombra el archivo style-participante2.css a style.css
Haz un commit y mira como se ve la página de tu repo local..

Compi 2

Mergea tu rama compi2 con practica:
1. Cambiar a la rama práctica: git checkout practica
2. Mergear: git merge compi2
Sube tu commit al repo remoto de GitHub:
1. git push origin practica

Relax :)

¿Por qué crees que no puedes hacer push?

¿Qué te dice la consola?
Nuestro rezo diario: Antes de hacer push haz un pull.....
Hazte pull.
Anota en un papel los archivos que te dan conflicto o bien sin hacer nada más en la consola ve a tu editor de código y busca los archivos.
En cada caso quedaos con los archivos del compi2.

Resolver el conflicto

En el editor:

HEAD: En la sección que hay ANTES de los iguales, vemos lo que tenemos en NUESTRA RAMA LOCAL
Después de los iguales: Vemos lo que ENTRA EN LA RAMA.
Siempre es importante tener claro que es lo que tenemos y que es lo que entra

Resolver el conflicto

En GitHub:

Resolver el conflicto

En GitHub:

Rama a mergear

Rama en la que queremos mergear

Se puede editar y escribir, así que hay que borrar todo lo que no sirve. Cuidado con borrar cosas que sí son necesarias

Conflicto resuelto:

Si todo ha ido bien, ahora en la rama de práctica al ejecutar index.html deberías ver algo así en la rama practica:

Gestión de proyectos con GitHub y GitLab

¡¡¡Tienes un kamban!!!

Kamban en Github:

Creas un nuevo proyecto

Selecciona una plantilla de kamban normal o lo que prefieras.

Kamban en Github:

Kamban en GitLab:

En el menú lateral: Issues/Board

Kamban en GitLab:

Herramientas

Que te ayudan a jugar con git

Herramientas

Consola:

Git Flow: Es un conjunto de extensiones de Git que facilita la gestión de ramas y flujos de trabajo. Link
Git mergetool: Nos da una interfaz gráfica para gestión de conflictos. Link
Normalmente los IDEs tienen plugins para gestión de conflictos