Por Filiberto Santillán / @FiliMX
Esta idea surgió gracias a un tweet y me dije ¡es una gran idea! ¿Porqué no hacerla más cool y divertida?.
Continua abajo
Mi nombre es Filiberto, lo sé es raro pero tu llámame "Fili", tengo 18 años, vivo en México, hace un año que soy parte de la comunidad Platzi. Me considero una persona emprendedora, creativa, con ganas de siempre aprender más. Te doy la bienvenida a esta presentación y espero que sea de tu agrado.
Nota: Siempre mantente al tanto de la esquina inferior derecha, ya que pueden haber temas con contenido más abajo.
Esta presentación esta pensada y hecha sólo para los estudiantes del curso de Git & Github de mejorandola, así que si no eres parte del curso ¿qué esperas?.
Cómpralo desde $29 dólaresSi tienes alguna duda, comentario, error, quieres sugerir algo, quieres algún cambio, o incluso si ves alguna falta de ortografía, manda un mensaje através de las redes sociales ó manda un tweet con el hashtag #filigit, responderé lo más pronto que pueda.
Es la gestión de diversos cambios que se realizan sobre un elemento, registran y guardan cada modificación del proyecto, de igual forma nos solucionan tres problemas del pasado:
Aquí es donde editamos y tabajamos con nuestros proyectos, es cuando decidimos abrir el editor de código, preparar una buena taza de café y empezar a hacer magia.
Aquí es donde escogemos que archivos están listos para el siguiente commit, de igual manera decidimos que archivos no lo están y no pueden continuar por el momento.
Aquí es el registro de todo nuestro proyecto, ese proyecto por el cual pasaste dos noches sin dormir y tomaste diez tazas de café, pero que sin duda te deja una gran satisfacción al terminar.
Después de haber instalado git, tenemos que comprobar si todo está bien, así que solo basta con escribir en la consola git --version y esto nos dará como resultado, la versión actual que tenemos en nuestro computador.
Al saber que tenemos git y que todo va perfecto, ahora tenemos que definir nuestro nombre de usuario, para eso sirve este comando y es como git sabe quienes somos.
Git ya sabe nuestro nombre, pero aún no sabe nuestro correo electrónico y esto es algo necesario para git, con un simple comando le decimos nuestro correo.
Este simple comando lo que hace es darnos una interfaz de colores, te lo recomiendo para que sea más fácil diferenciar algunas cosas de otras.
Por último tenemos este comando que nos dice nuestras configuraciones a nivel global, todo lo que hicimos antes aquí no los muestra.
Se usa --global para que el cambio o configuración que hacemos sea a nivel global y afecte a todos los usuarios por igual.
Si queremos cambiar el nombre de usuario o correo sólo tenemos que volver a usar el mismo comando pero con el nuevo nombre:
Es un comando que se utiliza para saber como funciona cada instrucción de git, al igual que da una breve explicacíon de dicha instrucción.
git --help comando.
Con esté comando le decimos a git que empiece a monitorear todos los cambios que haga en mi carpeta de trabajo, es el Nivel 1 de nuestro proyecto, es el inicio de una fantástica aventura.
Si no inicias con git init nos dirá que no hay un repositorio de git.
Nos muestra el estado en el que se encuentra nuestro proyecto:
Con este comando decidimos que archivos van a convertirse en commit y que archivos aún no están listos.
Agregamos todos los archivos.
git add -A
Agregamos solo el archivo index.html o el nombre del archivo que usemos.
git add index.html
Aquí ya estamos en la ultima parte del esquema de árbol y es hacer un commit como tal.
Ya que hicimos código y decidimos que archivos están listos, solo queda guardar lo que hicimos en un commit es decir el trabajo de hoy está hecho.
git commit -m "hoy pase de estar en ssj3 a ssj4"
Nos dice como está el repositorio a nivel de commits (Cuantos commits tenemos en el repositorio), quien las hizo, cuando las hizo y básicamente todo.
Es exactamente lo mismo que git log solo que este nos genera un .txt con los commits en la raíz del proyecto.
Con este comando viajamos a travez del tiempo, y podemos ir a cualquier commit que tengamos atrás, esto sin afectar a los que hay enfrente.
Si hacemos un cambio a algún proyecto que tienes atrás, crearás dos mundos paralelos
git checkout commit
git checkout master
Master -> rama principal
Este comando es súper poderoso y ten cuidado con usarlo, hace lo mismo que git checkout a diferencia que arrasa con todos los commits que tiene enfrente.
Tiene tres tipos de ejeción:
Es un reset tranquilo, tu Working Area lo deja, no se mete con tú código.
Este reset es raro y muy poco usado, borra tu Staging Area sin tocar tu Working Area
Este comando lo que dice es ¡Hey quiero borrar todo! y en efecto eso es lo que hace, inluyendo tu código.
Una rama es una línea del tiempo, en la historia de nuestro repositorio, funciona para crear features, arreglar bugs, experimentar, etc. Sin afectar la versión estable.
Esta línea donde empezamos se le conoce como master, es la línea principal y estable del proyecto.
Tenemos nuestra línea principal master (Trunks), pero digamos que alguien quiere crear una rama para hacer otras cosas llamada experimental (Goten).
Eso lo podemos lograr con:
git branch nombre de la rama
De ésta forma creamos una nueva línea (Rama) en la que nosotros podemos trabajar sin afectar a master
Para eliminar una rama se usa el comando:
git branch -d nombre de la rama
Es la forma en que nos movemos de un punto a otro (commit), Nuestro HEAD es el punto en donde nos encontramos.
Es la creación de un nuevo commit que vincule una de nuestras ramas (trunks), con alguna otra rama (Goten), dando como resultado un nuevo commit (Gotenks).
Para hacer una fusión tenemos que seguir 2 pasos:
Es la línea que absorbera la rama que nosotros deseamos, en este caso será experimental.
Lo logramos hacer con el comando antes visto checkout
git checkout nombre de la rama
Aquí es cuando nuestra línea que absorbe (Trunks) toma a la línea experimental (Goten) y nos dá nuestro nuevo commit (Gotenks).
Cuando se hace la fusión nos pueden dar 2 resultados diferentes:
Simplemente hará la fusión sin preguntar nada, es cuando los gestores trabajan archivos diferentes al repositorio
Ejemplo:
Es cuando dos desarrolladores o tú trabajan sobre el mismo archivo en la fusión
En la terminal podemos igual ver como esta avanzando el proyecto, con el comando git log, de esta forma visualizaremos de forma simple y sintetizada el dibujo de las ramas.
El comando es:
git log --oneline --graph --allSabemos que es un comando largo y da pereza, para eso existen los aliases los cuales hacen que no tengamos que escribir todo, es poder poner nuestros comandos git como queramos con el nombre que sea.
git config --global alias.filigit '--oneline --graph --all'
Ahora simplemente para usarlo hacemos lo siguiente:
git log filigit
Github es una comunidad o plataforma donde podemos almacenar nuestros proyectos, utiliza Git para su gestión.
Cada vez son más las personas que estan esta gran comunidad, la mayoria de ellas estan por el ámbito web, pero sin duda hay proyectos totalmente distintos.
Github además lleva un historial de tu código, guarda cada nuevo cambio que haces.
Son flujos de trabajo colaborativos.
Lograr trabajar con varios profesionales sobre el mismo proyecto sin morir en el intento.
Es la manera de como logras integrar todo tu equipo para que se alcance un proyecto completo.
Cuando clonas proyectos, es cuando no te interesa colaborar, solo quieres ver el proyecto y tenerlo en la computadora
Se basan en dos comandos:
git clone [https]
git clone [SSH]
Solo tenemos que ir al proyecto que necesitamos, y justo a la derecha tenemos el https para clonar
Ya que estamos en la carpeta donde queremos tener el proyecto usamos el comando:
git clone [https]
Somos los dueños, si alguien decide participar nostros decidimos si aceptamos las propuestas o no, y regularmente se usan para guardar proyectos personales.
Empezamos por crear un repositorio Local y Remoto.
Es decir crear un repositorio en nuestra computadora y otro en Github.
Ya que hicimos esto, Github no sabe que existe nuestra computadora, y nuestra computadora no sabe que existe Github.
Es cuando usamos:
git remote
git remote
Lo que hace es vincular nuestro repositorio local (Computadora) con nuestro repositorio remoto (Github).
Ejecutamos el comando:
git remote add origin Repositorio de github
De esta forma se vinculan y se conocen.
Para saber nuestros enlaces que hacemos via repositorio:
git remote -v
Finalmente ahora ya que trabajamos, hay que mandar esos cambios al repositorio de github
git push origin master
master -> Es la rama que mandaremos a github, obviamente podemos poner cualquier rama.
Es lo mismo que el proceso anterior, pero todos los cambios que hagan los colaboradores, podran hacerlos sin preguntar.
Ya no solo eres tú, si no que ya habrá alguien más.
Los colaboradores no piden permiso, suben cambios y se acabo.
Esto se explica a través de un proceso llamado:
git fetch & git merge
Cuando nosotros generamos un enlace remoto con un repositorio, hay una rama escondida llamada: origin/master y lo que haces es espejear el repositorio de github a tú área local.
git fetch
Lo que hace git fetch es espejear nuestro repositorio remoto con nuestro origin/master
Entonces para sincronizarnos usamos:
git fetch origin
Ahora lo que tenemos en remoto ya esta en la línea origin/master
Pero que pasa si yo creo commit totalmente distinto a lo que hay en origin/master ?
git merge
Ahora que tenemos dos commits totalmente distintos, llego la hora de fusionarlos y así crear un nuevo commit.
Para esto solo tenemos que estar en la rama principal y ejecutar:
git merge origin/master
git push
Finalmente ya que tenemos la fusión, ahora lo pasamos al repositorio remoto
Solo usamos el comando visto en el primer workflow.
git push origin master
Nosotros no somos dueños pero queremos participar en el desarrollo.
Todo dentro de un concepto de pull Request (PR).
Este tipo de repositorios trabajan bajo dos esquemas.
Necesitamos conectar dos repositorios porque cuando hacemos un fork es posible que ese proyecto se actualize y nosotros avancemos paralelo a otra cosa.
Una vez hecho el fork ahora conectamos los remotos.
Primero con el repositorio Fork
git remote add origin [http]
Seguimos con el siguiente remoto (El repositorio original)
git remote add upstream
Como vemos ya tenemos los dos remotos:
Ahora tenemos que espejear las dos ramas ocultas del proyecto:
git fetch origin
git fetch upstream
Esto va a hacer que tomemos los ultimos cambios en:
Ya que tenemos los últimos cambios, ahora hay que darselos a nuestra rama master y así se actualize junto con los nuestros.
git merge origin/master
git merge upstream/master
Ahora ya que tenemos todo en nuestro repositorio local, tenemos que pasarlo a nuestro repositorio remoto (repositorio fork) que esta en github.
git push origin master
Son todas las actividades que hacen a un proyecto de software disponible para su uso, es la manera en que haces publico tus proyectos, la forma en que te mueves y los llevas al mundo.
Hay cuatro ambientes regularmente en los equipos profesionales web.
Es nuestra área local (PC, Laptop), es donde creamos código y nos pasamos horas divirtiendonos, siendo mejores profesionales.
Es un repositorio remoto (Online, Web), puede ser en Github o algún otro servidor, es nuestro sitio final, el que le mostramos al mundo.
Funciona para que nosotros generemos un test, exámenes para encontrar fallos en los códigos.
Es un servidor extra básicamente, en ves de subir el proyecto a production primero pasas por staging y verificamos si todo va bien.
Con Github Pages podemos generar un proyecto de nuestro repositorio permitiendonos mostrarlo a travez de un dominio, el unico problema es que no podemos usar backend, pero es muy util para portafolios, blogs y todo tipo de paginas del lado del frontend totalmente gratis
Para ello solo tenemos que crear una nueva rama de nombre gh-pages y acoplarlo con nuestro nombre de usuario un ejemplo es esta presentación simplemente ve el url, si quieres saber más de este tema:
Todos los cambios y modificaciones que hagamos en la rama gh-pages se aplicaran a la pagina como tal.
SSH es una forma segura de conectar con Github.
A diferencia de HTTP no pide el usuario y contraseña porque con SSH sabe quien eres tu.
Primero hay que generar la llave:
$ ssh-keygen
Creara una carpeta .ssh oculta, que por lo general se encuentra en el Home.
Nota: si este comando no te funciona en windows, descarga: msysgit
Nos movemos a esa carpeta, y dentro nos encontramos con dos archivos que nos interesan:
Para analizarla usamos:
$ cat id_rsa.pub
Esto nos mostrara un código muy raro, lo copiamos absolutamente todo.
Ahora vamos a Github / Settings / SSH keys / Add SSH Key
Nos pedira un título y una llave, el título puede ser el que sea, pero en la llave pondremos lo que copiamos en la terminal.
Por ultimo damos click en Add key
Nos dirijimos al repositorio remoto en github y copiamos el SSH, en la terminal nos dirijimos a nuestro proyecto local, y ejecutamos:
git init
Ahora hay que conectar via SSH con el repositorio remoto
git remote add origin [SSH]
Hacemos un git pull (fetch + merch) a la rama master
git pull origin master
Pero como estamos trabajando con github pages usamos:
git pull origin gh-pages
Por ahora no aparece la rama gh-pages ya que esta oculta, para empezar a usarla:
git checkout gh-pages
Ahora si ya podemos trabajar y hacer el deployment
1) Trabajar en código
2) git status
3) git add -A
4) git commit -m "Mensaje"
5) git push origin gh-pages
Bueno primero tenemos que dejar en claro que remote repository (Github) es un servidor, cuando nos conectamos a un servidor este mismo puede conectarse con otro servidor.
Esto se le conoce como infraestructura de servidores.
La forma correcta de autenticación es con SSH, esto dice ¿eres tu el propetario de estos tres ambientes?.
Si nosotros tenemos la llave nosotros podemos entrar a todos los candados, es decir los diferentes repositorios o servidores.
Eso basicamente es deployment
Ahora lo que tenemos que hacer es que a ese dominio o aplicación que acabamos de crear generar un repositorio con nuestra amiga la terminal.
Entramos remotamente desde la terminal al servidor.
$ ssh kakaroto@web396.webfaction.com
Recuerda que la dirección SSH varia segun tu servidor.
Nos dara la dirección para entrar de forma remota, esto igual depende del servidor, pero siempre nos la tiene que dar.
Ponemos nuestra contraseña, puede ser la misma o distinta a key que usamos con github.
Una vez hecho esto, ya estamos conectados de forma remota a travez de SSH
Ahora tenemos que conectar la llave SSH que tenemos al servidor pero desde github y que no tenga ningun problema para mandarse información.
Esto lo logramos con:
$ ssh-keygen
Nuevamente nos genera una llave publica y privada
Entramos a la llave publica y nuevamente copiamos el código encriptado.
Para obtener el código recuerda usar:
$ cat id_rsa.pub
Vamos a Github / Settings / SSH keys / Add SSH Key
Nos pedira un título y una llave, el título puede ser el que sea, pero en la llave pondremos lo que copiamos en la terminal (Servidor).
Por ultimo damos click en Add key
¡Bien!, ya generamos una llave publica ahora con el servidor.
Recordar que estamos conectados a un servidor externo y no a nuestro PC.
Empecemos a conectar Github con nuestro servidor, regularmente tenemos comandos de git, en caso de que no tengamos git en el servidor, tenemos dos opciones:
Ahora si podemos empezar a traer el proyecto desde github.
Mini-bonus por mi
Esta es una pequeña ayuda que proporciono, pero básicamente hablare de lo mismo y de forma que tu lo puedas entender.
Los issues es una forma de dar seguimiento, mejorar o resolver un error de nuestros proyectos.
Para crear un issue tenemos que ir a nuestro repositorio en Github / settings y en la parte de Features activamos Issues.
Una vez hecho esto en la parte derecha nos saldra un nuevo icono, damos click.
Ahora damos click en New Issue, aquí es donde elegimos un título y una pequeña descripción de lo que se debe de hacer.
En el issue hay una parte que dice No one is assigned que básicamente es: No has asignado el issue a nadie así que damos click en el engrane y seleccionamos a alguien incluso podemos a nosotros mismos.
De esta forma la persona que seleccionamos es la que tiene que hacerse cargo de ese issue.
Ya que tenemos todo esto damos click en:
Submit new issue
Ahora esta nuestro issue creado, y podemos hacer aun más...
Si entramos al issue podemos tener conversaciones con el equipo acerca de lo que pasa, poner imagenes o finalmente cerrar el issue porque se resolvio.
Que pasa si tenemos una gran cantidad de issues, es posible que sea dificil encontrarlos, para eso tenemos:
Milestones
Labels
Son grupos de issues que corresponden a un proyecto, característica, o periodo de tiempo.
Ejemplo:
Issues de Betas
Issues para Enero
Issues para Rediseño
Para crearlos solo tenemos que ir a Milestone
Damos click en el boton de New milestone
Como podemos tenemos que asignar un título, una descripción y una fecha de vencimiento (opcional), hecho esto, damos en create milestone.
Ahora cuando creamos un issue podemos meterlo dentro de un milestone, de esta forma podemos llevar el control.
Son una gran manera de organizar diferentes tipos de problemas. Los problemas pueden tener todas los labels que sean y se pueden filtrar por una o varias labels a la vez.
Git nos proporciona algunos labels por defecto pero igual nosotros podemos crear los nuestros.
Damos click en New label, asignamos un nombre y un color, finalmente damos click en Create label.
Así de sensillo es crear labels
Podemos asignarlos a nuestros issues y tener una buena organización.
Si no te quedo claro los issues
Son una serie de comandos encapsulados dentro de un archivo.sh, se ejecutan con la terminal, y van de arriba a abajo.
Si por alguna razón tienes problemas en windows, descarga cygwin
Solo tenemos que crear nuestro archivo .sh y empezar a escribir nuestras instrucciones
Para ejecutar este shell script y se aplique todo lo que tiene:
sh nombre.sh
Son scripts que se ejecutan antes, durante o después de realizar un movimiento con git.
Estos scripts son archivos .sh, y constan de 17
Este hook se ejecuta después de generar un commit
Es decir una ves que nosotros usemos
git commit -m "mensaje"
Este hook va a ejecutarse automáticamente.
Para ello primero tenemos que ir a la carpeta hooks:
cd .git/hook
Nota: debemos haber iniciado git antes en la carpeta de nuestro proyecto
git init
No está nuestro hook, así que tenemos que crear
touch post-commit
Para editar usamos:
vim post-commit
Dentro ponemos
#!/bin/sh
git push origin master
Ahora ya que tenemos guardado esos comandos en post-commit hay que dar permisos:
chmod +x post-commit
Listo ahora ya tenemos el hook activado solo tenemos que generar el commit:
git remote add origin [SSH]
git add -A
git commit -m "Usando hooks"
Lo que paso es que se hace un push pero sin tener que ejecutarlo, los hooks son tus amigos y lo hacen por tí.
Básicamente un Automatic Deployment es un manual deployment pero automatizado.
Primero hay que crear nuestra llave SSH dentro de nuestro servidor.
ssh-keygen
La obtenemos con:
cat id_rsa.pub
La copiamos y vamos a Github / settings/ add SSH key / agregamos llave
De esta forma logramos conectar el servidor con Github.
Antes de empezar con lo siguiente tenemos que lograr conectar el Local Repository con Github vía SSH
Nosotros ya sabemos hacer eso así ¡que que esperan! :D
mkdir portafolio
git init
git remote add origin [SSH]
git remote -v
git pull origin master
Nota: El archivo .gitignore lo que va hacer es no tomar los archivos .sh del repositorio.
touch .gitignore
vim .gitignore
Dentro de .gitignore ponemos: *.sh
touch deploy.sh
Lo que haremos es editar nuestro index.html
cd .git/hooks
touch post-commit
vim post-commit
Dentro de post-commit:
#!/bin/sh
git push origin master
ssh miguelnieva@web396.webfaction.com 'bash -s' < deploy.sh
chmod +x post-commit
cd ../..
vim deploy.sh
Dentro de deply ponemos lo siguiente:
#!/bin/sh
cd ~/webapps/portafolio -> Según tu servidor
git init
git remote add origin [SSH]
git pull origin master
git status
git add -A
git commit -m "Deploy 1"
¡Listo! ya hicimos deployment automático
Si por alguna circustancia extrema, no podemos usar Github, existen los "bare respositories", que no son más que repositorios limpios, envian y reciben contenido.
Un bare repository unicamente guarda el historial de cambios, con todos sus archivos, pero no puedes editarlos.
Un bare repository ¡¡¡jamás se toca!!!
Primero creamos nuestras dos carpetas o aplicaciones en servidor.
Entramos a nuestro servidor via SHH (Ya sabemos como) y borramos los index.html que tienen.
Ahora lo se hara es lo siguiente: normal repository (local) suba cambios al bare repository y que normal repository (server) reciba esos cambios.
Empecemos
Creamos nuestra carpeta y un archivo index.html
mkdir proyecto
touch index.html
Editamos nuestro index
vim index.html
Creamos el commit
git init
git status
git add -A
git commit -m "Commit 1"
Entramos al servidor vía SSH y nos movemos hasta la carpeta
ssh goku@web396.webfaction.com
cd/webapps/gitcentral
Ejecutamos git init
git init --bare --share
--bare -> Porque este repositorio va a ser un "bare".
--share -> Para que lo puedan pushear diferentes usuarios.
Ahora tenemos que subirlo al servidor directamente, y mandamos cambios:
git remote add origin goku@web396.webfaction.com:home/goku/webapps/gitcentral
git push origin master
git init
git remote add origin ../gitcentral
git pulls origin master