SCV Git

Objetivo principal

Familiarizarse, entender qué es y cómo trabaja Git & GitHub

Contenidos

1.1 Introducción

• Historia
• Tipos de SCV

1.2 SCV Centralizados vs SCV Distribuidos

• Ventajas de un SCV distribuidos

¿Por qué usar un SCV?

• ¿Cuál es la última versión?
• ¿Cómo vuelvo a la versión anterior?
• ¿Cómo unimos los cambios con los de otros?

SCV: Flujo de trabajo a cambio de:

• Llevar un historial de todos los cambios
• Posibilidad de trabajar en varias cosas a la vez
• Colaborar con otros
• Hacemos copia de seguridad de todo el historial

Un desarrollador, sin red

• 1972 Source Code Control
• 1980 Revision Control System

Centralizados

• 1986 Concurrent Version System
• 1999 Subversion ("CVS done right")

Distribuido

• 2001 Arch, monotone
• 2002 Darcs
• 2005 Mercurial (hg), Bazaar (bzr), Git

Antes de BitKeeper

• Para desarrollar Linux, se usaban parches y archivos tar.gz

BitKeeper

• 02-2002 BitMover regala licencia BitKeeper (privado)
• 04-2005 BitMover retira la licencia

Git

• 04-2005 Linus Torvalds presenta Git
• 06-2005 Git se usa para gestionar Linux
• 02-2007 Git 1.5.0 es utilizable por mortales
• 03-2016 Última versión: Git 2.7.3

1.2 SCV Centralizados vsSCV Distribuidos

1.2 SCV Centralizados vsSCV Distribuido

Ventajas de un SCV distribuido

• El trabajo es mucho más rápido.
• Clonar un repo Git es más eficiente.
• Nosotros decidimos cuando enviar los nuevos cambios.
• Es fácil aportar, hacer experimentos, crear y eliminar.

Contenidos

• 2.1 ¿Qué es Git?
• 2.2 Caracteristicas de Git
• 2.3 Arquitectura de Árbol
• 2.4 Instalación de Git
• 2.5 Configurando Git

2.1 ¿Qué es GIT?

2.1 ¿Qué es GIT?

2.2 Caracteristicas de Git

2.2 Caracteristicas de Git

1) Registran y guardan cada modificación del proyecto en un registro. Todo lo que modificas, lo vigilan.

2.2 Caravteristicas de Git

2) Te dan acceso a este registro. Con esto, puedes gestionarlo, compartirlo, colaborarlo, administrarlo, editarlo, etc.

2.2 Caracteristicas de Git

3) Podrás moverte hacia atrás o hacia adelante en diferentes momentos del proyecto.

2.3 Arquitectura de árbol

2.3 Arquitectura de árbol

2.3 Arquitectura de árbol

2.3 Arquitectura de árbol

2.3 Arquitectura de árbol

2.4 Instalación

a) Entren a http://git-scm.com

b) Escoja dependiendo de Windows, Mac, Linux

2.5 Configuración

Abrir terminal, consola, bash

						$ git --version
					

					$ git config --global user.name "TU NOMBRE"
					

					$ git config --global user.email "TU CORREO DE GITHUB"
					

					$ git config --global color.ui true
					

					$ git config --global --list
					

Actividad Nº1

• Esntrar a https://github.com/platzi/mejorandogit descargar el proyecto en ZIP en nuestra máquina local, luego realizar iteraciones utilizando los siguientes comandos:
• $ git help
• $ git add --all
• $ git commit -m "Mensaje"
• $ git status
• $ git git log
• $ git diff
• $ git checkout
• $ git reset

Ejercicio (70% de git)

Ejercicio (70% de git)

Ejercicio (70% de git)

Contenidos

• 3.1 Propuestas de proyectos
• 3.2 Ramas (Branches)
• 3.3 Fusiones (Merge)

3.1 Propuestas de Proyectos

• ¿Cómo puedo intervenir positivamente en el proyecto sin afectarlo?
• ¿Cómo puedo enfocarme en resolver un bug, un problema, sin afectar el avance de mi equipo?
• Como profesionales, proponer es una de las habilidades más importantes para crecer

3.1 Propuestas de Proyectos

Por ello, en GIT, existen las ramas, también conocidos como "branches".

3.2 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.

3.2 Ramas

3.2 Ramas

3.2 Ramas

3.2 Ramas

3.2 Ramas

3.2 Ramas

3.2 Ramas

El concepto HEAD

¿En qué punto de la historia de nuestro proyecto nos encontramos?

3.2 Ramas

Practiquemos ramas

git branch [nombre]

3.2 Ramas

git log --oneline --graph --all

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

3.3 Fusiones

Repitamos el proceso de la fusión

3.3 Fusiones

git checkout [branch]

3.3 Fusiones

git checkout [branch]

3.3 Fusiones

git checkout [branch]

3.3 Fusiones

Hagamos la fusión

3.3 Fusiones

Fu...

3.3 Fusiones

...sión!

3.3 Fusiones

La fusión tiene la mezcla de los cambios de ambas ramas

3.3 Fusiones

Lo mejor de ambas, establecidas por el gestor del proyecto

3.3 Fusiones

Solución de conflictos

a) Fast-Forward

b) Manual Merge

3.3 Fusiones

Solución de conflictos

Fast-Forward

Los gestores trabajaron archivos diferentes al repositorio

3.3 Fusiones

Solución de conflictos

Manual Merge

¿Qué pasa cuando 2 desarrolladores trabajan el mismo archivo en la fusión?

Actividad Nº2

Con nuestro proyecto, generar 3 versiones. Una estable, una experimental y una que fusionemos.

Contenido

1) GitHub & Workflows

2) Repositorios propios

3) Repositorios "forked"

GitHub

• "Una plataforma de desarrollo colaborativo de software para alojar proyectos utilizando el sistema de control de versiones Git"
• - Es una plataforma social para crear proyectos tecnológicos
• - Es un servicio de “hosting" de repositorios, a través de una interfaz web gráfica

Workflows

Flujos de trabajo colaborativos.

Workflows

¿Cómo logro que varios profesionales web trabajen sobre un mismo proyecto, sin morir en el intento?

Workflows

Exploración: Git Clone

$ git clone [https or SSH]

$ git log (comprobar commits)

Git Clone

Git Clone

Git Clone

GitHub Workflows

1) Repositorios propios (Sólo YO)

• - Ustedes son los dueños de su proyecto
• - Si alguien decide participar, ustedes deciden si aceptan sus propuestas
• - Sirve para guardar proyectos, regularmente personales

1) Crear un repositorio

2) Vincularlo con nuestra PC

3) Generar cambios y subirlos a GitHub

Subir cambios a GitHub

Subir cambios a GitHub

Subir cambios a GitHub

Subir cambios a GitHub

Subir cambios a GitHub

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 (Mi equipo y yo)

• 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

Git Fetch & Git Merge

Creamos ó entramos a la carpeta de nuestro proyecto

$ git init

$ 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)

Repositorios "forked"

Necesitamos conectar 2 repositorios.

• 1) Su repositorio forked (el que se clonó 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")

Actividad Nº3

3.1) Crear un repositorio en GitHub y vincularlo en local.

3.2) Subir nuestro proyecto2 a nuestro repositorio "forked" en GitHub.

Contenidos

1) Deployment.

2) Ambientes

3) GitHub Pages.

4) Manual Deployment

1) Deployment

"Es la manera de llevar tus proyectos al mundo"

Todas las actividades que hacen a un proyecto de software disponible para su uso

1) Deployment

2) Ambientes

2) Ambientes Óptimos

2) Ambientes FTP

- Se pierde el código, se pierde todo

- Como no hay un SCV, el equipo puede encimar sus avances

- Si el código falla en producción, regresar al momento anterior es un caos.

3) GitHub Pages

3) GitHub Pages

3) GitHub Pages

4) Manual Deployment

4) Manual Deployment

4) Manual Deployment

4) Manual Deployment

4) Manual Deployment

4) Manual Deployment

SSH

Secure Shell

Autenticación - "Are you the owner?"

Actividad Nº4

- Subir nuestro proyecto a través de un GitHub Pages.

Actividad Nº5

Referencias

• http://librosweb.es/libro/pro_git/
• https://git-scm.com/
• https://github.com
• https://github.com/MiguelNieva/presentacion-mejorandogit