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
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
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:
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.
- Subirlos.
- Comprueba que todo está ok y que en tu rama están los cambios finales.
Resolver conflicto ejemplo:
Resolver conflicto ejemplo:
Ramas famosas:
develop ó dev
feature/loquesea
bugfix/esePeasoBug
hotfix/ayQueEstáEnProducción
master....
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
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
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
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.
- Modificar configuración inicial.
- Crear un repositorio en local.
Ingredientes:
- Cuenta de email.
- Ordenador con Git instalado.
Cuenta de GitHub
Bienvenida de GitHub
Bienvenida de GitHub
Crear un repositorio 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
Nuevo repo en GitLab
Nuevo repo en 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?
- Forkear un repositorio.
- Dar permisos a otra persona.
- Crear una rama.
- Hacer un PR.
- Mergear una rama.
- Resolver un conflicto
Compi 1
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
Clonar el repo
- Ambos tienen que clonar el repositorio:
- git clone https://github.com/ElenaMLopez/Banana_oh_la_la
- cd Banana_oh_la_la
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:
- 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:
- git push -u origin compi1
- 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):
- 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:
- Cambiar a la rama práctica: git checkout practica
- Mergear: git merge compi2
- Sube tu commit al repo remoto de GitHub:
- 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
Herramientas
Gráficas:
- Sourcetree: https://www.sourcetreeapp.com/
- GitHub desktop: https://desktop.github.com/
- GitKraken :https://www.gitkraken.com/
- y muchas más...
- Listado completo
Consejo
Aprende con la consola, equivócate, busca en google y cuando sepas que haces realmente, si quieres pasa a las herramientas gráficas
¡¡¡¡MUCHÍSIMAS GRACIAS!!!!
Esperamos que os gustase
^.^
Recursos:
Comandos básicos de git en castellano:
https://gist.github.com/ElenaMLopez/ca17cb107b6a3c51946279f8fd67327d
Libro de referencia: https://git-scm.com/book/es/v1
Chuleta de GitHub: https://github.github.com/training-kit/downloads/es_ES/github-git-cheat-sheet.pdf
Chuleta de muy pro: https://elbauldelprogramador.com/mini-tutorial-y-chuleta-de-comandos-git/#chuleta-de-comandos-git
Consola (linux):
https://gist.github.com/ElenaMLopez/eec11d0d10fbceb446709d12927d0c27
Hola Git y GitHub *! *GitHub y GitLab
Hello Git!!!!
By Elena M. López
Hello Git!!!!
- 2,431
