Hola Git y GitHub!

$ whoami:

Me llamo Elena y soy Adalaber.

He trabajado en BQ como programadora y maquetadora de front, y he realizado un máster en JavaScript y NodeJS.

Podéis encontrarme en varios proyectos de OSW (Open Source Weekends).

Twitter: @lpez_elena

GitHub: elenamlopez

$ whoami:

Yo soy Jose, conocido como @MrCodeDev en twitter.

Soy Full Stack Junior y en mis ratos libres toco el chelo y hago fotos.

Me apasiona la tecnología y estoy profundizando en mis conocimientos como guilder de OSW

GitHub: mrcodedev

Gracias a ...

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

1. git add <archivo>:

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

git add . agrega todo a stagin

Busca más formas de agregar a stagin =)

Hacer un commit

1. git commit -m "Mensaje del 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.

Listar los commits.

1. git log:

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

Viajar en el tiempo

1. git checkout <codigo_sha>:

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

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

git checkout .

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í

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.

Crear una rama:

git branch <nombre_rama>

Por ejemplo: git branch mi-rama

Cambiarse a esa rama:

git checkout <nombre_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]

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

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 la 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:

1. Resolver el conflicto.

2. Commitear cambios.

3. Subirlos.

4. Comprueba que todo está ok y que en tu rama están los cambios finales.

Resolver conflicto ejemplo:

Estoy en master, me traigo feature-header y boom!!

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?

git push origin <nombre-rama>

Y no olvides...

Estando en develop:

git merge <mi-rama>

Una vez has terminado de trabajar con la rama, y 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.

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, kill it...

git branch -D <nombre-rama>

Buena higiene:

Mala higiene:

Hello git?

GitHub

Un tablero de juego

Disclaimer:

Muy necesario, porque no sólo Microsoft me cae mal (alerta eufemismo), sino que además aun estoy superando el estado de shock post-traumático... bueno ya casi está.

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.

Con GitHub 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).

Bienvenida de GitHub

PASO 2: En esta página podéis seleccionar el plan y montar organizaciones.

Bienvenida de GitHub

PASO 3: Selecciona lo que quieras o sáltate el paso, que se puede :)

Bienvenida de GitHub

Al crear un nuevo proyecto os pide la confirmación de la cuenta. Hazla.

Bienvenida de GitHub

GitHub:

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

Y en caso de incendio

¿Agregar repos remotos?

¡Sí se puede!

En consola poner:

git remote add <nombre_para_remoto> <url>

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

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

¡Al turrón!

Hora de mancharse las manos y jugar con git

¿Qué vamos a hacer?

Crear un repositorio en GitHub.
Forkear un repositorio en GitHub.
Configurar Git. (local)
Crear un repositorio en local.
Clonar en tu local un repositorio de GitHub.
Hacer un commit en local sobre ese repo
Subir ese commit a vuestro repo forkeado
Hacer un Pull Request... sí sí, vas a hacer uno!
Tomar una merecida cerveza, refresco o lo que quieras :)

Ingredientes:

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

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

Crear un repositorio en local dentro de la carpeta que queremos, 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':

Haz tus cambios en el código:

Edita el README.md con cualquier IDE
Agrega tu nombre para que aparezca como asistente al taller ;P

Haz tu primer commit:

Guarda los cambios en el archivo
Haz un commit ... (Tiene premio a la más rápida)

Haz tu primer push:

¡¡¡ También tiene premio !!!

¿Preguntas?

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

^.^

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

He hecho cambios y hago un commit

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

¡RStudio tiene Git!

Así es, y vamos a ver como funciona

(overwiew)

Configurar Git en RStudio

Ir al menú RStudio/Preferences
En el menú de la ventana da la izquierda click en Git/SVN
Seleccionar el "Git executable" la ruta /usr/bin/git
Click en Apply y luego en OK

Con esto ya tenemos seleccionado el control de versiones con Git

Crear un proyecto con Git inicializado

Nuevo proyecto.
En la ventana que aparece pulsar en New Directory, si en este punto se pulsa en Version Control, se puede clonar desde un remoto, pedirá la url.
Dar nombre al proyecto y bajo el input de Create project as subdirectori of: donde se da la ruta hay que marcar el checkbox Create a git repository
Click en Create Project

Con esto hemos creado un proyecto con Git inicializado.

Trabajar con control de versiones

Vemos el botón del menú desplegable de git.
Entrar en este menú en Git / Project Setup
En la ventana de Project Options que sale, comprobar que tenemos en la sección Git/SVN como Version control system Git
Realizar algún cambio y guardarlo
Entrar en el menú de Git / Diff <nombre_archivo>
Si no se selecciona un archivo no entra en Stagin Area, al seleccionarlo es como añadirlo con git add
Seleccionar los archivos a salvar en el commit
En la ventana superior derecha llamada Commit message, poner el mensaje del commit y hacer click en commit

Hacer un pull y un push

Con un repositorio ya vinculado a un remoto, hacer un cambio y salvar
Realizar un commit
En el menú de Git, pulsar en pull
En el menú de Git pulsar en push

Gestión de proyectos con GitHub

¡¡¡Tienes un kamban!!!

Kamban en Github:

Creas un nuevo proyecto

Selecciona una plantilla de kamban normal o lo que prefieras.

Kamban en Github:

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