Hola Git y GitHub*!

*GitHub y GitLab

$ whoami:

Me llamo Elena y soy Adalaber.

He trabajado en BQ como programadora y maquetadora de front, y y he hecho un máster en JavaScript y NodeJS en Fictizia. Trabajo como programadora en Next Chance.

Liada en varios proyectos de OSW (Open Source Weekends).

Twitter: @lpez_elena

GitHub: elenamlopez

$ whoami:

Aquí Chechu.
Full Stack JS en proceso, actualmente en el curso de Js avanzado en Fictizia . Podéis encontrarme en muchos proyectos de OSW o en el Yermo de Fallout.
Apasionado de la programación y enamorado de JavaScript.
Github: https://github.com/Xexuline

Twitter: @Xexuline

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.

$ 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

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...

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:

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.
Subirlos.
Comprueba que todo está ok y que en tu rama están los cambios finales.

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:

Muy necesario, porque este taller no solo estaba agendado antes de la compra, sino que además aun estoy en estado de shock post-traumático... bueno ya casi no.

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

Tu repo en local y remoto...

Tienes tu código en tú maquina, pero así sólo lo ves tu, 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 (tu código estará visible para todo el mundo) y de pago (puedes tener repositorios privados), (... 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 en GitHub.
Configurar Git.
Modificar configuración inicial.
Crear un repositorio en local.
Forkear un repo en Github.
Clonar ese repo en tu 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...

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

(Modificar para que se clonen su fork NO EL MIO!!!!)

Crear un repositorio en local dentro de la carpeta taller_git_archivos, pero trayéndolo de GitHub:
- ```
$ 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
En css... ni te cuento...

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

¿Qué vamos a hacer?

Dar permisos a otra persona.
Añadir un remoto a nuestro repo.
Crear una rama.
Hacer un PR.
Resolver un conflicto

Trabajo en parejas

Con la persona que tengas a tu izquierda...

El Compi 1 da permiso a su compañer@ en su repositorio de GitHub.
La persona a la que se le da permisos (Compi 2) tiene que agregar un remoto en su repo local...
Cambiaros en local a la rama de practica.

Da permiso a tu compañer@ en el repo para poder hacer commits.

Settings / Collaborators

La persona a la que se le da permisos tiene que agregar un remoto en su repo local..

En la consola, la persona a la que se le ha dado permisos, tiene que añadir un repo remoto (el del compañer@) a su local, para poder subir cambios al mismo repo.

¿Recordáis cómo se hace? ^.^

* Tiene premio jejeje

$ git remote add <nombre para el nuevo origen> <url>

Cambiaros en local a la rama practica

En la consola poned:

$ git checkout practica

Participante 1

Crea una rama llamada compi1.
Cambiate a esa rama.
Elimina el archivo index.html
Renombra el archivo index-participante1.html a index.html
Renombra el archivo style-participante1.css a style.css
Haz un commit y mira como se ve la página de tu repo local.
Mergea tu rama compi1 con practica (recuerdas cómo?)
Sube tu commit al repo remoto de GitHub (a la rama práctica!!!)

Participante 2

Crea una rama llamada compi2.
Cámbiate a esa rama.
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..
Mergea tu rama compi2 con practica.
Sube tu commit al repo remoto de GitHub

Relax :)

¿Por qué crees que no puedes hacer push?

(tiene premio)

¿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.

Cómo se hace en github:

Esto es lo que viene (rama que hace el PR)

De los iguales hasta el final es lo que está en la rama que recibe el PR

Cómo se hace en github:

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