GUIA: INICIACIÓN A GIT
Lo esencial para iniciarse en el mundo de git.
@estebanrfp / @slvrkl / @aguja2013 / @andresLoquesea
Investigación y desarrollo de tecnologías para la web
desarrolloactivo.com
CLASE 1
Instalación - Conceptos Básicos
CONTROL DE VERSIONES
Solucionan tres problemas del pasado:
- a - Proyectos difíciles de gestionar y liderar.
- b - Riesgos a sobrescribir el código.
- c - La centralización y poca probabilidad de trabajar remotamente.
ARQUITECTURA DEL ÁRBOL
• Working Area
• Staging Area
• Repository
Es donde editamos nuestro código.
Es donde seleccionamos los archivos que conformarán el commit.
Es el registro de todo el proyecto.
CONFIGURACIÓN
Definimos Nombre y Correo de manera Global.
git config --global user.name "Tu nombre"git config --global user.email "Tu correo"
Activamos la interfaz de colores.
git config --global color.ui true
Listamos nuestra configuración global.
git config --global --list
Ayuda general o sobre un comando.
git --help
git --help < nombre del comando. >
Iniciamos Git en una carpeta
git init
Estado en el que se encuentra nuestro proyecto
git status
Agregamos al staging area todos los archivos.
git add -A
Hacemos un commit con su descripción.
git commit -m "mensaje"
Informe sobre los commits realizados.
git log
Generamos un informe de los commits en un archivo .txt. Nos permite recuperar commits borrados.
git log > commits.txt
Volvemos al estado del proyecto en el commit que le indiquemos.
git checkout < número de commit >
Borramos todo desde el commit actual al commit que le indiquemos.
No borra nada del Working Area Borra el Staging Area sin tocar el Working Area Borra todo en todas las áreas
git reset --soft < número de commit >
git reset --mixed < número de commit >
git reset --hard < número de commit >
CLASE 2
Ramas y Fusiones
RAMAS
Una rama es una nueva línea que se crea para experimentar y hacer cambios sin afectar a la versión estable.
Línea Master
Es la línea principal y estable del proyecto.
Creando una rama
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
CONCEPTO HEAD
Nuestro HEAD es el punto en donde nos encontramos (commit - rama).
FUSIONES
Es unir dos ramas generando un nuevo commit.
Para hacer una fusión realizamos 2 pasos:
1 - Nos situamos en la línea (rama) que va a absorber.
git checkout < nombre de la rama >
2 - Fusionamos.
Aquí es cuando la línea en la que estamos situados absorbe la rama que deseamos fusionar creando un nuevo commit.
git merge < nombre de la rama >
Cuando se hace la fusión nos pueden dar 2 resultados diferentes:
1 - Fast-Forward.
Hace la fusión automaticamente porque las ramas fusionadas han sido trabajadas en áreas o archivos diferentes. No se enciman.
Ejemplo:
Esteban Fuster Pozzi -> index.html
Miguel Nieva -> styles.css
2 - Manual Merge
Las ramas fusionadas han sido trabajadas en las mismas áreas de un mismo archivo.
Resultado:
Esteban Fuster Pozzi -> index.html
Miguel Nieva -> index.html
•Nos tocará decidir y escoger manualmente el código que quedará estable.
GIT LOG & ALIASES
Versión simplificada del comando git log que permite visualizar en una sola linea el estado del commit.
git log --oneline --graph --all
Para comandos largos como este existen los aliases para poder reemplazarlos por un nombre pripio que elijamos.
git config --global alias.nice '--oneline --graph --all'
Ahora para usarlo escribimos:
git log nice
Clase 3
Workflows y Colaboración Remota
Github
Github es una comunidad o plataforma donde podemos almacenar nuestros proyectos, utiliza Git para su gestión. Lleva un historial de tu código y guarda cada nuevo cambio que haces.
Git no es lo mismo que Github
Github se basa en tres áreas
• Colaboración:
-
• Creación:
-
• Conexión:
Libertad de hacer o que te hagan propuestas basadas en el código original de cualquier proyecto.
Proyectos, empresas, startups, equipos.
Conectas con el mundo profesional y te abres a nuevas oportunidades de trabajo.
WORKFLOWS
Son flujos de trabajo colaborativos.
Lograr trabajar con varios profesionales sobre el mismo proyecto.
Es la manera de como logras integrar todo tu equipo para que se alcance un proyecto completo.
Exploración: Git Clone
Cuando clonas proyectos, guardas una copia exacta en tu ordenador para experimentar, estudiarlo y hacer lo que quieras. 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 o SSH para clonar.
Estando en la carpeta donde queremos tener el proyecto usamos el comando:
git clone [https]
Github Workflows están divididos en tres áreas:
2 - Proyectos Propios.
Somos los dueños, si alguien decide participar nosotros decidimos si aceptamos las propuestas o no, y regularmente se usan para guardar proyectos personales.
Creamos una carpeta en Local y un repositorio Remoto(Github).
Para vincular los repositorios ejecutamos el comando:
git remote add origin < Repositorio de github >
Para verificar el vínculo y ver los enlaces:
git remote -v
Luego de crear y modificar archivos los subimos al repositorio remoto.
git push origin master
2 - Proyectos propios (Yo + Equipo)
Las personas que se sumen al equipo como colaboradores son libres de hacer cambios a través de un proceso llamado:
git fetch & git merge
Al generar 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 ?
Ahora que tenemos dos commits totalmente distintos, llego la hora de fusionarlos y así crear un nuevo commit.
git merge
Para esto solo tenemos que estar en la rama principal y ejecutar:
git merge origin/master
Finalmente ya que tenemos la fusión, ahora lo pasamos al repositorio remoto
git push
Solo usamos el comando visto en el primer workflow.
git push origin master
3) Proyectos con terceros
Nosotros no somos dueños pero queremos participar en el desarrollo.
Aquí aparece el 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:
- • Repositorio Fork
- • Repositorio Original
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 está en Github.
git push origin master
IMPORTANTE
Antes, Después y siempre:
git fetch
Clase 4
Manual Deployment + Project Management
DEPLOYMENT
Es hacer público un proyecto dejándolo disponible para su uso.
ENVIRONMENTS (AMBIENTES)
Hay cuatro ambientes regularmente en los equipos profesionales web:
- • Development
- • Production
- • Testing
- • Staging
Development
Es nuestra área local (PC, Laptop), donde creamos código.
Production
Es un repositorio remoto y público (Online, Web), puede ser en Github o algún otro servidor.
Testing
Área de pruebas para el funcionamiento correcto del código.
Stagin
Es un servidor extra para verificar si todo va bien antes de pasar a production.
GITHUB PAGES
Servicio gratis de Websites para los repositorios alojados en Github.
Creamos una rama con el nombre 'gh-pages'. Damos editar a la descripción del repositorio y donde pone website colocamos http://nombredeusuario.github.io/nombredelrepositorio.
Todos los cambios en la rama 'gh-pages' se aplican al website.
•Sólo Front-end.
CONECTAR POR SSH
SSH es una forma segura de conectar con Github, diferente de HTTP y con la posibilidad de evitar el uso de contraseña.
Primero hay que generar la llave en la terminal. En el home:
ssh-keygen
Creara una carpeta .ssh oculta.
Nos movemos a esa carpeta, y dentro nos encontramos con dos archivos que nos interesan:
• id_rsa.pub
• id_rsa
Llave publica, es la que le entregamos al servidor o a alguna persona.
Llave privada, jamas hay que perderla ni compartirla.
Para analizarla, dentro de .ssh usamos:
cat id_rsa.pub
Esto nos mostrara un código muy raro y lo copiamos.
Ahora vamos a Github.com y en nuestro repositorio vamos a / Settings / SSH keys / Add SSH Key.
Nos pedira un título y la llave que copiamos en la terminal.
Por ultimo damos click en Add key.
Nos dirijimos al repositorio remoto en github y copiamos el SSH.
•Ejemplo de llave SSH: git@github.com:evercoders/ejemplo.git
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:
• git status
• git add -A
• git commit -m "Mensaje"
• git push origin gh-pages
MANUAL DEPLOYMENT
Dejemos en claro que remote repository (Github) es un servidor, cuando nos conectamos a un servidor este mismo puede conectarse con otro servidor.
La forma correcta de autenticación es con SSH.
Si nosotros tenemos la llave y podemos entrar a los diferentes repositorios o servidores.
Eso basicamente es deployment.
Entramos remotamente desde la terminal al servidor.
ssh ubuntu@evercoders.com
Recuerda que la dirección SSH varia según tu servidor.
Ponemos nuestra contraseña, puede ser la misma o distinta a la key que usamos con Github.
Una vez hecho esto, ya estamos conectados de forma remota a través de SSH.
Ahora tenemos que conectar la llave SSH que tenemos al servidor pero desde Github para que sin problemas se envíen la 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.com y luego a nuestro repositorio / Settings / SSH keys / Add SSH Key
Nos pedira un título y una llave, que la copiamos de 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:
- •Que el proveedor nos los active.
- •Nosotros los instalemos.
Ahora si podemos empezar a traer el proyecto desde Github.
git init
git remote add origin [SSH]
git pull origin master
ISSUES
Los issues es una forma de dar seguimiento, mejorar o resolver un error de nuestros proyectos.
Crear un Issue
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.
El issue podemos asignarlo a cualquiera del equipo o a uno mismo.
Ya que tenemos todo esto damos click en: Submit new issue
Si entramos al issue podemos tener conversaciones con el equipo acerca de lo que pasa, poner imagenes o finalmente cerrar el issue porque se resolvió.
Para una mayor organización y detección de issues tenemos:
•Milestones
•Labels
Milestones
Son grupos de issues que corresponden a un proyecto, característica, o periodo de tiempo.
Para crearlos solo tenemos que ir a Milestone
Damos click en el boton de New Milestone.
Tenemos que asignar un título, una descripción, una fecha de vencimiento (opcional) y click a create milestone.
Ahora cuando creamos un issue podemos meterlo dentro de un milestone, de esta forma podemos llevar el control.
Labels (etiquetas)
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.
Github 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 y contar con una buena organización. aqui
CLASE 5
Automatic Deployment + Git Hooks
SHELL SCRIPTS
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
Crear .sh
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
GIT HOOKS
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
post-commit
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í.
AUTOMATIC DEPLOYMENT
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.
SUB PROYECTO
Antes de empezar con lo siguiente tenemos que lograr conectar el Local Repository con Github vía SSH
1) Creamos carpeta
mkdir portafolio
git init
git remote add origin [SSH]
git remote -v
2) Jalamos archivos (si es necesario)
git pull origin master
3) Creamos archivo .gitignore & deploy.sh
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
4) Generamos Cambios
Lo que haremos es editar nuestro index.html
5) Creamos el Git HOOK y lo llenamos
cd .git/hooks
touch post-commit
vim post-commit
Dentro de post-commit:
#!/bin/sh
git push origin master
ssh usuario@dominio.com 'bash -s' < deploy.sh
6) Autorizamos el Git Hook
chmod +x post-commit
7) Llenamos los comandos que se ejecutatan en servidor (deploy.sh)
cd ../..
vim deploy.sh
Dentro de deply ponemos lo siguiente:
#!/bin/sh
cd ~/WEBPATH/ -> Según tu servidor
git init
git remote add origin [SSH]
git pull origin master
Ahora probamos
git status
git add -A
git commit -m "Deploy 1"
Lo que va a pasar es lo siguiente:
• Empieza a funsionar el Hook.
• Hace el commit y el push.
• Nos pidde la contraseña del área del servidor.
• ¡Listo! ya hicimos deployment automático!
DEPLOY TOTAL EN SERVER
Si no podemos usar Github, existen los "bare respositories", que no son más que repositorios limpios, envían y reciben contenido.
Un bare repository unicamente guarda el historial de cambios, con todos sus archivos, pero no puedes editarlos. ¡jamás se toca!
Primero creamos nuestras dos carpetas o aplicaciones en servidor.
- • gitcentral
- • deployserver
Guarda todos nuestros repositorios "bare" y solo va a recibir/enviar información.
Mostrara nuestro resultado, ya pasando por el "bare".
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.
LOCAL
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"
Servidor (Bare repository)
Entramos al servidor vía SSH y nos movemos hasta la carpeta
ssh info@evercoders.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.
Local
Ahora tenemos que subirlo al servidor directamente, y mandamos cambios:
git remote add origin
info@evercoders.com:home/goku/webapps/gitcentral
git push origin master
Servidor (normal repository)
git init
git remote add origin ../gitcentral
git pulls origin master
mkdir gitcentral
cd gitcentral
git init --bare --share
git remote add origin ubuntu@54.194.94.13:/home/ubuntu/webapps/gitcentral
mkdir deployserver
cd deployserver
touch index.html ( escribimos dentro “hola mundo”)
git init
git add -A
git commit -m “primer commit”
git remote add origin ../gitcentral
Deploy automático de repositorios bare
cd ../gitcentral/hooks
touch post-receive
chmod +x post-receive
Post-receive situado en /webapps/gitcentral/hooks
#!/bin/bash
cd ../deployserver || exit
unset GIT_DIR
git pull origin master
ó
#!/bin/bash
cd /home/ubuntu/webapps/deployserver || exit
unset GIT_DIR
git pull origin master