Arquitectura de Arbol

Working Area

Que es?

Es es la parte de trabajo, en donde te pones a plasmar todas ideas en codigo

Staging Area

Que es?

Despues de trabajar tan duro, es momendo de decir que archivos estan listos para generar un commit y cuales no

Repository

Que es?

Es el area de registros del proyecto.

70% Git

git help

Qué es?

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.

git init

Qué es?

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.

git status

Qué es?

Nos muestra el estado en el que se encuentra nuestro proyecto:

• Que cambios hay.
• Que cambios viejos borraste.
• Que es lo que sigue.

git add

Qué es?

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

git commit -m "mensaje"

Qué es?

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"

git log

Qué es?

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.

git log > commits.txt

Qué es?

Es exactamente lo mismo que git log solo que este nos genera un .txt con los commits en la raíz del proyecto.

git checkout

Qué es?

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

git reset

Qué es?

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:

git reset --soft

Es un reset tranquilo, tu Working Area lo deja, no se mete con tú código.

git reset --mixed

Este reset es raro y muy poco usado, borra tu Staging Area sin tocar tu Working Area

git reset --hard

Este comando lo que dice es ¡Hey quiero borrar todo! y en efecto eso es lo que hace, inluyendo tu código.

Ramas

Una rama es una línea alterna del tiempo, en la historia de nuestro repositorio.

Funciona para crear features, arreglar bugs, experimentar, sin afectar la versión estable, la línea principal, del proyecto

Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones. La rama por defecto de Git es la rama master. Con la primera confirmación de cambios que realicemos, se creará esta rama principal master apuntando a dicha confirmación. En cada confirmación de cambios que realicemos, la rama irá avanzando automáticamente. Y la rama master apuntará siempre a la última confirmación realizada.

git branch

Esto creará un nuevo apuntador apuntando a la misma confirmación donde estés actualmente

$ git branch testing

Esto creará un nuevo apuntador apuntando a la misma confirmación donde estés actualmente

¿Cómo sabe Git en qué rama estás en este momento?

Pediante un apuntador especial denominado HEAD. es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama master. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama.

Para saltar de una rama a otra, tienes que utilizar el comando git checkout. Hagamos una prueba, saltando a la rama testing recién creada:

$ git checkout testing

y poder seguir avansando en nuestro proyecto

Procedimientos básicos de fusión

Simplemente, activando (checkout) la rama donde deseas fusionar y lanzando el comando git merge

$ git checkout master $ git merge nombre_de_rama

git log --oneline --graph --all git config --global alias.nicelog 'log --oneline --graph --all'

Trabajando con repositorios remotos

Los repositorios remotos son versiones de tu proyecto que se encuentran alojados en Internet o en algún punto de la red.

GitHub

Es una plataforma social para construir proyectos.

Workflows

Exploración: Git Clone

$ git clone [https or SSH]

$ git log (comprobar commits)

Ramas Remotas

Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red.

Suelen referenciarse como (remoto)/(rama).

Para añadir un nuevo repositorio Git remoto, asignándole un nombre con el que referenciarlo fácilmente, ejecuta $ git remote add [nombre] [url]

Subir cambios a GitHub

Subir cambios a GitHub

$ git init

$ git remote add origin [HTTPS or SSH]

$ git remote -v

Generamos cambios

$ git commit -am "[Mensaje]"

$ git push origin master

2) Repositorios propios (Yo + mi equipo)

- Es lo mismo que el proceso anterior.

- Todos los cambios que hagan nuestros colaboradores lo subirán al repositorio

- Es nuestra obligación, descargar los nuevos cambios antes y después de codificar.

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Git Fetch & Git Merge

Creamos ó entramos a la carpeta de nuestro proyecto

$ git init (si apenas vamos a iniciar)

$ git remote add origin [HTTS or SSH]

$ git fetch origin

$ git merge origin/master

Hacen cambios

$ git fetch origin

$ git merge origin/master

$ git push origin master

GitHub Workflows

3) Repositorios "forked" (De 3º's, hay gestores)

- Ustedes no son los dueños pero quieren participar en el desarrollo.

- Los dueños del proyecto le dan la visión (que commits sí y que commits no)

- Todo esto a través del concepto de Pull Request (PR)

Subir cambios a GitHub

Subir cambios a GitHub

$ git init

$ git remote add origin [HTTPS or SSH]

$ git remote -v

Generamos cambios

$ git commit -am "[Mensaje]"

$ git push origin master

Repositorios "forked"

Necesitamos conectar 2 repositorios.

1) Su repositorio forked (el que se colocó en su cuenta de GitHub y son dueños)

2) El repositorio principal (no son dueños)

Repositorios "forked"

Repositorios "forked"

Repositorios "forked"

Repositorios "forked"

Repositorios "forked"

Repositorios "forked"

Ciclo final - Repositorios "forked"

Repositorios "forked"

La idea es:

- Siempre que vayamos a iniciar cambios, actualizarnos con el proyecto principal.

- Hacer nuestros cambios, experimentos, etc.

- Revisar nuevamente si no hubo cambios con el proyecto principal.

- Subir a nuestro forked repository todo lo que hemos hecho.

- Si queremos, crear un pull request para colaboración.

Repositorios "forked"

Crear ó entrar a la carpeta del proyecto

$ git remote add origin [HTTPS ó SSH del proyecto forked]

$ git remote add upstream [HTTPS ó SSH del proyecto "main"]

$ git fetch upstream

$ git merge origin/upstream

$ git fetch origin

$ git merge origin/master

Hacer cambios en local

$ git fetch upstream

$ git merge origin/upstream

$ git push origin master

Repositorios "forked"

Si queremos, realizamos un Pull Request al proyecto principal ("main")

Gracias !!

Creditos a:

Fili Santillán

MIGUEL NIEVA

The Inventor's House

• @InventorsHouse
• https://www.facebook.com/TheInventorsHouse

Farmging Code

• https://www.facebook.com/farmingcode