CURSO PROFESIONAL DE GIT Y

GITHUB
Un primer curso

INTRODUCCION
 Git es un sistema control de versiones. Guarda el historial de cambios de un proyecto en un solo
archivo.
 Enlace para descargar https://git-scm.com/
 Git puede ser instalado en Windows, Mac o Linux
 GitHub es de Microsoft

COMANDOS BASICOS DE GIT

Todo inicia con el comando git init el cual permite la activación del sistema control de versiones.

Algunos otros comandos básicos que veremos son:

 Git status
 Git add
 Git reset HEAD
 Git reset
 Git commit
 Git rm [--force, --cached]
 Git branch -d

Ciclo de vida o estados de los archivos en Git

 Archivos tracked: Viven dentro de Git. No tienen cambios pendientes. Repositorio actualizado.
 Archivos Staged: Son afectados por el comando git add. Archivos que han sido modificados. Git
sabe de estos cambios, pero no han sido guardados definitivamente en el repositorio con el
comando git commit.
 Archivos Unstaged: Git tienes registro de estos archivos, pero esta desactualizado. Sus últimas
versiones solo están guardadas en el disco duro.
 Archivos Untracked: No viven dentro de Git sino en el disco duro. Git no tiene registro de ellos.

Rama o Branch
 Todos los commits se realizan sobre una rama especifica.
 Crear una nueva rama lo conocemos como checkout.
 Unir dos ramas se conoce como Merge.

Creando un Repositorio
Configurar git
 git config --list
 git config --global user.email "[email protected]"
 git config --global user.name "Tu Nombre"
Ejemplo
1. Git init (Debes estar en la carpeta de tu proyecto)
2. Git status
3. Git add Nombre_Archivo
4. Git commit -m “Mensaje de tu commit”

Nota: Usando el shortcut git commit -am “Mensaje del commit” permite agregar al staging área y
realizar commit.

Tip: Si te olvidaste de agregar un archivo, no hagas un nuevo commit. Realiza los siguientes pasos

i) git add archivo-que-olvide-agregar

ii) Git commit –amend –no-edit

Analizar Cambios del Proyecto

 Utilizamos el comando git show que muestra los cambios realizados sobre un archivo.
 Si queremos ver la diferencia entre una versión a otra utilizamos el comando git diff commit A
commit B
 Con el comando git log podemos ubicar el ID del commit para hacer la diferencia.

Volver en el Tiempo
 Git reset –hard borrara hasta el commit que le indiques.
 Se puede hacer un git reset –soft el cual dejara archivos en el staging área
 El comando git checkout + ID del commit nos permite viajar en el tiempo y devolvernos.
Podemos volver a cualquier versión anterior de un archivo específico o incluso del proyecto
entero. Esta también es la forma de crear ramas y movernos entre ellas.

FLUJO DE TRABAJO BASICO CON UN REPOSITORIO REMOTO

  git clone url_del_servidor_remoto: Nos permite descargar los archivos de la última versión de la
rama principal y todo el historial de cambios en la carpeta. git.
 git push: Luego de hacer git add y git commit debemos ejecutar este comando para mandar los
cambios al servidor remoto.
 git fetch: Lo usamos para traer actualizaciones del servidor remoto y guardarlas en nuestro
repositorio local (en caso de que hayan, por supuesto).
 git merge: También usamos el comando git fetch con servidores remotos. Lo necesitamos para
combinar los últimos cambios del servidor remoto y nuestro directorio de trabajo.
 git pull: Básicamente, git fetch y git merge al mismo tiempo.

Ramas En Git
 La rama master es default
 Normalmente posee un apuntador llamado HEAD o es el commit más reciente
 Cuando se crea una nueva rama lo que realmente hacemos es una copia del ultimo commit de
nuestra rama master.
 Para crear una nueva rama usamos git branch Nombre_Rama
 Para hacer cambios entre ramas usamos git checkout Nombre_Rama
 Los cambios realizados en cabecera deben unirse a master
 Para esto es necesario ubicar el HEAD en master y luego hacer un git merge cabecera

Solucionando Conflictos al Hacer un Merge

 Cuando dos ramas diferentes hacen cambios distintos a una misma línea se presenta un
conflicto.
 Los archivos con conflictos por el comando git merge entran en un nuevo estado que
conocemos como Unmerged. Funcionan muy parecido a los archivos en estado Unstaged, algo
así como un estado intermedio entre Untracked y Unstaged, solo debemos ejecutar git add para
pasarlos al área de staging y git commit para aplicar los cambios en el repositorio.

TRABAJANDO CON REPOSITORIOS REMOTOS

GitHub
 GitHub es una red social para desarrolladores
 Puedes crear proyectos y realizar commits
 Si hemos trabajado desde nuestro PC y queremos subir nuestro proyecto a GitHub:
1. Nos ubicamos en la carpeta del proyecto
2. Copiamos la URL del proyecto
3. Usamos git remote add origin URL. Verificamos con los comandos git remote y git remote -v
4. Usamos git pull origin master
Nota: Si aparece “Fatal: refusing to merge unrelated histories” usamos git pull origin master
–allow-unrelated-histories
Llaves Publicas y Llaves Privadas
Las llaves públicas y privadas nos ayudan a cifrar y descifrar nuestros archivos de forma que los podamos
compartir archivos sin correr el riesgo de que sean interceptados por personas con malas intenciones.

La forma de hacerlo es la siguiente:

 Ambas personas deben crear su llave pública y privada.

 Ambas personas pueden compartir su llave pública a las otras partes (recuerda que esta llave es
pública, no hay problema si la “interceptan”).
 La persona que quiere compartir un mensaje puede usar la llave pública de la otra persona para
cifrar los archivos y asegurarse que solo puedan ser descifrados con la llave privada de la
persona con la que queremos compartir el mensaje.
 El mensaje está cifrado y puede ser enviado a la otra persona sin problemas en caso de que los
archivos sean interceptados.
 La persona a la que enviamos el mensaje cifrado puede usar su llave privada para descifrar el
mensaje y ver los archivos.

Nota: Puedes compartir tu llave pública pero nunca tu llave privada.

Configurar Llaves SSH en Local

Debemos agregarle un nivel más de seguridad usando el protocolo SSH

Para configurar una llave SSH seguimos los siguientes pasos en el home de tu entorno local:

1) ssh-keygen -t rsa -b 4096 -C “[email protected]”

2) Configuramos nuestro sistema
a) Windows y Linux
i) eval $(ssh-agent -s): Configurar servidor SSH. Programa que revisa que las llaves corren.
ii) ssh-add ruta-donde-guardaste-tu-llave-privada : Agregamos la llave al servidor
b) En Mac
i) eval “$(ssh-agent -s)”
ii) # Si usas una versión de OSX superior a Mac Sierra (v10.12)
iii) # debes crear o modificar un archivo "config" en la carpeta
iv) # de tu usuario con el siguiente contenido (ten cuidado con
v) # las mayúsculas):
vi) Host *
vii) AddKeysToAgent yes
viii) UseKeychain yes
ix) IdentityFile ruta-donde-guardaste-tu-llave-privada
x) ssh-add -K ruta-donde-guardaste-tu-llave-privada -

Conexión a GitHub con SSH

 Cada persona/computador debe tener una llave publica/privada
 En GitHub navegar a Settings > SSH an GPG keys >New SSH key
 Colocamos un nombre del computador y la llave publica
 Usamos git remote set-url origin url-ssh-del-repositorio-en-github
 Debemos actualizar nuestro origen con nuestro entorno local
Tags y Versiones en Git y GitHub
Los tags o etiquetas nos permiten asignar versiones a los commits con cambios más importantes o
significativos de nuestro proyecto.

Comandos para trabajar con etiquetas:

 Crear un nuevo tag y asignarlo a un commit: git tag -a nombre-del-tag id-del-commit.

 Borrar un tag en el repositorio local: git tag -d nombre-del-tag.
 Listar los tags de nuestro repositorio local: git tag o git show-refs --tags.
 Publicar un tag en el repositorio remoto: git push origin --tags.
 Borrar un tag del repositorio remoto: git tag -d nombre-del-tag y git push origin
:refs/tags/nombre-del-tag.

Tip: Los alias nos permiten simplificar líneas de código en git. Alias NOMBRE_ALIAS = comando de git.

Manejo de Ramas
Puedes trabajar con ramas que nunca envías a GitHub, así como pueden haber ramas importantes en
GitHub que nunca usas en el repositorio local. Lo importantes que aprendas a manejarlas para trabajar
profesionalmente.

Crear una rama en el repositorio local:

git branch nombre-de-la-rama o git checkout -b nombre-de-la-rama.

Publicar una rama local al repositorio remoto: git push origin nombre-de-la-rama.

Recuerda que podemos ver gráficamente nuestro entorno y flujo de trabajo local con Git usando el
comando gitk.

Configurar Múltiples Colaboradores en un Repositorio de GitHub

El nuevo integrante debe clonar el repositorio en el entorno local

Se debe agregar el colaborador en los settings del repositorio no de la cuenta de GitHub antes de
realizar un push.

FLUJO DE TRABAJO PROFESIONAL

Haciendo Merge de Ramas de Desarrollo a Master

Trabajar con binarios (Archivos que contengan imágenes o imágenes mismas) no es recomendado

Se debe actualizar en el navegador e inclusive la cache usando la combinación CTRL + SHIFT + R

El encargado de realizar los merge o coordinar lo que suscede con el proyecto es comúnmente
denomidado DevOps
Pull Requests
En un entorno profesional normalmente se bloquea la rama master, y para enviar código a dicha rama
pasa por un code review y luego de su aprobación se unen códigos con los llamados merge request.

Para realizar pruebas enviamos el código a servidores que normalmente los llamamos staging develop
(servidores de pruebas, similares al entorno de produccion) luego de que se realizan las pruebas
pertinentes tanto de código como de la aplicación estos pasan a el servidor de producción con el ya
antes mencionado merge request.

Un pull request puede ser visto como un estado intermedio antes de enviar un merge

Los pull requests están dados por GitHub

Creando un Fork
Los forks funcionan de la misma manera que los pull request

Se utiliza cuando no eres colaborador o perteneces al equipo, pero quieres realizar cambios en el
proyecto como contribuyente.

Solo se puede hacer a proyectos públicos

Ignorar Archivos en el Repositorio con .gitignore

No todos los archivos que agregas a un proyecto deberían ir a un repositorio, por ejemplo cuando tienes
un archivo donde están tus contraseñas que comúnmente tienen la extensión .env o cuando te estás
conectando a una base de datos; son archivos que nadie debe ver.

Para que no se suban estos archivos no deseados se puede crear un archivo con el nombre .gitignore en
la raíz del repositorio con las reglas para los archivos que no se deberían subir (ver [sintaxis de
los .gitignore(https://git-scm.com/docs/gitignore)).

Las razones principales para tomar la decisión de no agregar un archivo a un repositorio son:

Es un archivo con contraseñas (normalmente con la extensión .env)

Es un blob (binary large object, objeto binario grande), mismos que son difíciles de gestionar en git.

Son archivos que se generan corriendo comandos, por ejemplo la carpeta node_modules que genera
npm al correr el comando npm install

GitHub Pages
https://pages.github.com/
MULTIPLES ENTORNOS DE TRABAJO
Git Rebase: Reorganizando el trabajo realizado
El comando rebase es una mala práctica, nunca se debe usar, pero para efectos de curso te lo vamos a
enseñar para que hagas tus propios experimentos. Con rebase puedes recoger todos los cambios
confirmados en una rama y ponerlos sobre otra.

# Cambiamos a la rama que queremos traer los cambios

git checkout experiment

# Aplicamos rebase para traer los cambios de la rama que queremos

git rebase master

Rebase debe usarse para repositorios locales ya que reescribe la historia del repositorio

Se le hace rebase primero a la rama que cambia y luego a la rama principal

Git Stash: Guardar cambios en memoria y recuperarlos después

Cuando necesitamos regresar en el tiempo porque borramos alguna línea de código pero no queremos
pasarnos a otra rama porque nos daría un error ya que debemos pasar ese “mal cambio” que hicimos a
stage, podemos usar git stash para regresar el cambio anterior que hicimos.

git stash es típico cuando estamos cambios que no merecen una rama o no merecen un rebase si no
simplemente estamos probando algo y luego quieres volver rápidamente a tu versión anterior la cual es
la correcta.

Git Clean: Limpiar tu proyecto de archivos no deseados

A veces creamos archivos cuando estamos realizando nuestro proyecto que realmente no forman parte
de nuestro directorio de trabajo, que no se debería agregar y lo sabemos.

Para saber qué archivos vamos a borrar tecleamos git clean --dry-run

Para borrar todos los archivos listados (que no son carpetas) tecleamos git clean -f

Git cherry-pick: Traer commits viejos al head de un branch

Existe un mundo alternativo en el cual vamos avanzando en una rama pero necesitamos en master uno
de esos avances de la rama, para eso utilizamos el comando git cherry-pick IDCommit.

cherry-pick es una mala práctica porque significa que estamos reconstruyendo la historia, usa cherry-
pick con sabiduría. Si no sabes lo que estás haciendo ten mucho cuidado.

Git Reset y Reflog: Úsese en caso de emergencia

¿Qué pasa cuando todo se rompe y no sabemos qué está pasando? Con git reset HashDelHEAD nos
devolveremos al estado en que el proyecto funcionaba.
Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo que estás haciendo sólo
es actualizar la punta del branch, para gestionar éstas puntas existe un mecanismo llamado registros de
referencia o reflogs

git reset --soft HashDelHEAD te mantiene lo que tengas en staging ahí.

git reset --hard HashDelHEAD resetea absolutamente todo incluyendo lo que tengas en staging.

git reset es una mala práctica, no deberías usarlo en ningún momento; debe ser nuestro último recurso.

Buscar en archivos y commits de Git con Grep y log

A medida que nuestro proyecto se hace grande vamos a querer buscar ciertas cosas.

Por ejemplo: ¿cuántas veces en nuestro proyecto utilizamos la palabra color?

Para buscar utilizamos el comando git grep color y nos buscará en todo el proyecto los archivos en
donde está la palabra color.

Con git grep -n color nos saldrá un output el cual nos dirá en qué línea está lo que estamos buscando.

Con git grep -c color nos saldrá un output el cual nos dirá cuántas veces se repite esa palabra y en qué
archivo.

Si queremos buscar cuántas veces utilizamos un atributo de HTML lo hacemos con git grep -c "<p>".

Comandos útiles
git shortlog -sn = muestra cuantos commit han hecho cada miembros del equipo.

git shortlog -sn --all = muestra cuantos commit han hecho cada miembros del equipo hasta los que han
sido eliminado

git shortlog -sn --all --no-merge = muestra cuantos commit han hecho cada miembros quitando los
eliminados sin los merges

git blame ARCHIVO = muestra quien hizo cada cosa linea por linea

git COMANDO --help = muestra como funciona el comando.

git blame ARCHIVO -Llinea_inicial,linea_final= muestra quien hizo cada cosa linea por linea indicándole
desde que linea ver ejemplo -L35,50

**git branch -r **= se muestran todas las ramas remotas

git branch -a = se muestran todas las ramas tanto locales como remotas

assets/img/iPad.png