Git

Desarrollo colaborativo
 ● ¿Qué es?

Git ● ¿Para qué lo usamos?

Preguntas
● ¿Cómo lo usamos?
 ● Linus Torvalds

Git ● Trabajo colaborativo

Control de versiones
● Registro y control de versiones
Control de
versiones ¿Qué es la versión de un archivo?

¿Por qué nos interesa llevar control

Concepto de esto?
 Desarrollo ¿Qué es?

colaborativo ¿Cómo se puede lograr?

¿Ejemplos de programas que

Concepto
permitan el desarrollo colaborativo?
 ● Desarrollo de software

Desarrollo ● trabajo colectivo

colaborativo ● Gestión eficiente de los

recursos
puntos clave
● Reducción de errores

● Compartir con la comunidad

Descarga e instalación
Git para windows
 Descarga https://gitforwindows.org
Para los que usen linux:
La mayoría de las distribuciones ya vienen con git
 Guía subida en el Alumni:
Instalación https://docs.google.com/document/d/e/2PACX-1vRPG
BV3mb85RvjdAsMLvYUuUhGCWLNDYvdCloRZT-Teb3
Siguiendo los pasos Jup1rozoHnJWYH3x9Sow/pub
Links de interés
Git Book:

https://git-scm.com/book/es/v1/Empezando-Instalando-Git

Interfaz gráfica:

https://desktop.github.com/
Repositorios
y sus diferentes tipos
Repositorio ¿Qué es?

¿Para qué lo usamos?

Concepto
Repositorio git
Estructura
 Los archivos del proyecto y sus versiones son
gestionadas de manera local (en una única
computadora).
Repositorio Este tipo de repositorio es mucho más simple
de gestionar, pero no permite el trabajo
local colaborativo.

Concepto y diagrama
 Ahora los cambios se almacenan en una servidor central, y los
usuarios se conectan a él para consultar y subir cambios.

Este modelo presenta nuevos desafíos:

¿Cómo trabajan múltiples usuarios en un mismo archivo al mismo

tiempo?

Repositorio La conexión con el servidor central es curical, sin acceso a el, no

es posible trabajar.

centralizado
Concepto y diagrama
 Nos alejamos de la idea de un solo repositorio
centralizado y optamos por darle a cada desarrollador una
copia local de todo el proyecto.

de esta manera se construyó una red distribuida de

repositorios, en la que cada desarrollador podía trabajar

Repositorio
de manera aislada pero teniendo un mecanismo de
resolución de conflictos mucho más elegante que un su
versión anterior.

distribuido
Concepto y diagrama
 ● committed

Estados ● modified
principales de un repositorio GIT
● staged
 ● committed
○ los datos se almacenan de forma
segura en su base de datos local.

● modified
Estados ○ ha cambiado un archivo pero aún
no lo ha confirmado en su base de
datos.
principales de un repositorio GIT
● staged
○ ha marcado un archivo modificado
en su versión actual para pasar a
su próximo snapshot de
confirmación.
 Las distintas operaciones avanzan el
estado de los archivos en alguna
dirección.

Operaciones
Locales
Grafos
Un poco de matemática no viene mal
 Típicamente, un grafo se representa
gráficamente como un conjunto de
puntos (vértices o nodos) unidos por
líneas (aristas).
Grafo
Concepto
 La principal diferencia entre GIT y cualquier otro SCV es la forma
en que GIT piensa acerca de sus datos. La mayoría de los
sistemas almacenan información como una lista de cambios
basados en archivos.

Control de Estos sistemas (CVS, Subversion, Perforce, Bazaar, etc.) piensan

en la información que mantienen como un conjunto de archivos y
los cambios realizados en cada archivo a lo largo del tiempo.

versiones
Git vs el mundo
 En cambio, GIT piensa en sus datos más como un conjunto de
snapshots (instantáneas) de un mini sistema de archivos. Cada vez
que confirma o guarda el estado de su proyecto en GIT,
básicamente toma una fotografía de cómo se ven todos sus
archivos en ese momento y almacena una referencia a esa
instantánea.

Control de Para ser eficiente, si los archivos no han cambiado, GIT no

almacena el archivo nuevamente, solo un enlace al archivo
idéntico anterior que ya ha almacenado.

versiones
Git vs el mundo
 GIT reconsidera casi todos los aspectos del control de versiones que la mayoría de los
otros sistemas copian de la generación anterior.

Se parece más un mini sistema de archivos con algunas herramientas increíblemente

poderosas construidas sobre él, en lugar de simplemente un SCV.

Control de Consideramos entonces que la manera de representación de cada versión creada en

nuestro repositorio corresponde a la de un sistema de grafos.

versiones
Git vs el mundo
Configuración inicial
personalizando nuestro entorno
Configuración git config --list --show-origin
Consultando las variables
seteadas
Nombre de
usuario git config --global user.name "Mi Nombre de Usuario"

Seteando username
 Correo
electrónico git config --global
user.email "mi.direccion.de.email@ejemplo.co
m"
Seteando email
Configuración
adicional git config --global core.editor
"'C:/Program Files/Notepad++/nodepad++.exe'"
Editor de texto
Configuración git config --list
Consultando la configuración
Configuración git config user.name
Consultando una variable
Nuestro primer repositorio
primeros pasos
Repositorio ● Convertir directorio local

● Clonar un repositorio existente

Formas de obtenerlo
Directorio local git init
Convirtiendo un proyecto
cualquiera
Acciones básicas
en nuestro nuevo repo
Consultando
estado 1. Crear el archivo info.txt

2. git status
de nuestro repo
 Creando Podemos ver que nuestro archivo info.txt no
tiene seguimiento ya que se encuentra debajo

snapshots del titular “Untracked files”.

Untracked significa que el archivo no estaba

en la versión anterior del proyecto
Untracked files (snapshot). GIT no lo va a incluir hasta que no
se lo digamos explícitamente.
 1. git add info.txt
Creando
2. git status
snapshots Vemos que nuestro archivo está bajo
seguimiento y listo para ser confirmado, es
Untracked files decir, formar parte de la nueva versión del
repositorio (commit).
 1. modificar el info.txt

Archivos con 2. git status

El archivo ahora aparece también bajo la

seguimiento sección llamada “Changes not staged for

commit”, lo cual significa que un archivo con
seguimiento ha sido modificado en el
directorio de trabajo (working directory) pero
tracked files no ha sido preparado aún.

Podemos preparar un archivo para el próximo

commit utilizando también el comando git add.
Confirmando
snapshots Ahora que nuestro archivo se encuentra en el
área de preparación(stage area), estamos
listos para confirmar los cambios, es decir,
realizar un commit.
commiteando los cambios.
Confirmando
snapshots git commit -m "Agrego cambios en el archivo"

commiteando los cambios.

Confirmando
snapshots Cada vez que hagamos un commit vamos a
estar generando una nueva versión del
proyecto, ó snapshot, la cual podemos revertir
o comparar luego.
commiteando los cambios.
 Corrigiendo
commits git commit --amend
Para cuando metemos la pata
 Registro de
cambios git log
Consultando el historial de
nuestro repo
Github
Repositorios remotos
 ¿qué es?
Github ¿por qué es útil?
Almacén de repositorios ¿cómo lo usamos?
 Repositorios
remotos https://github.com/
Crearse una cuenta en github
Repositorio
remoto Crear un repositorio nuevo
Github
Configurando el
repo remoto git remote add nombre_repo <link>

git remote -v
En nuestra pc
 git push origin master

Este comando va a funcionar sólo si tenemos

Push permiso de escritura y si nadie subió cambios

mientras realizamos y subimos los nuestros.

Si alguien más realizó un push antes que

Subiendo los cambios al repo nosotros, nuestra operación será rechazada.
remoto Tendremos primero que incorporar los
cambios nuevos subidos antes de poder
realizar un push.
Clone vs Fork
Trabajando en proyectos de terceros

Clone
Clonando repositorios de otros
podemos trabajar con clientes
de GIT tales como GitHub,
configurarlo como nuevo remoto y
empezar a compartir nuestro trabajo
con otros desarrolladores.
Veamos ahora el caso en donde
queremos empezar a colaborar con
alguien que ya tiene un proyecto
subido a algún cliente y donde no
tenemos la necesidad de comenzar
un repositorio nuevo vacío en
nuestra máquina local.
 Clone git clone <url>
Clonando repositorios de otros
 Cuando queremos contribuir con un proyecto
existente al cual no tenemos permisos de
escritura(push access) podemos realizar un fork de
dicho proyecto. Cuando realizamos un fork de un
repositorio, GitHub intentará hacer una copia entera
del proyecto en nuestra cuenta de usuario; vive en

Fork nuestro nombre de espacio, es decir que podemos

realizar cualquier cambio en él.

De esta manera, los proyectos no tienen que

Otra forma de colaborar con
proyectos de terceros
preocuparse por agregar usuarios como
colaboradores ni darles permisos especiales.
Cualquier persona puede entonces hacer un fork de
cualquier proyecto open-source, hacerle cambios y
contribuir con esos cambios al proyecto original
creando lo que se denomina un Pull Request.
 Para crear un fork de un repositorio,
solo tenemos que visitar la página del
proyecto original y hacer click en el
botón que dice “Fork” en el margen
superior derecho del sitio :

Fork
Otra forma de colaborar con Luego de unos instantes, vamos a ser
proyectos de terceros redirigidos a la página de nuestro
nuevo proyecto el cual contiene una
copia exacta del original a la cual
podemos hacerle cambios.
 GitHub está diseñado alrededor de
un flujo de trabajo focalizado en Pull
Requests, lo cual le permite a los

Fork desarrolladores a colaborar tanto en

repositorios unificados por grupo
como en aquellos que son
y el desarrollo colaborativo
distribuidos globalmente a través de
compañías o incluso personas
desconocidas.
 1. Hacemos un Fork de un proyecto

2. Creamos un branch nuevo desde el branch maste

Desarrollo 3. Hacemos algunos commits para mejorar el

proyecto

colaborativo 4. Hacemos un push de nuestro branch a

nuestro proyecto de GitHub

5. Abrimos un Pull Request en GitHub

Flujo habitual 6. Generamos una discusión al respecto de
nuestro trabajo realizado y
alternativamente seguimos haciendo más
commits

7. Sincronizamos el branch master

nuevamente a nuestro Fork
Fetch vs Pull
Actualizando los cambios locales

Fetch
obteniendo las referencias y
posibles cambios en el repo
Este comando nos va a traer todas las referencias a
objetos commit que estén presentes en el repositorio
remoto que no tengamos en el local. Esto nos da la
posibilidad de poder inspeccionarlo posteriormente o
bien, si estamos seguros de que es un trabajo testeado,
unirlo con nuestro trabajo actual.
En caso de estar trabajando con un repositorio clonado,
simplemente podemos correr el comando git fetch origin
(ya que como vimos, clonar un repositorio remoto nos
crea automáticamente un remoto local con alias “origin”).
El comando git fetch sólo descarga la información nueva a
nuestro repositorio local pero no junta este nuevo trabajo
traído con nuestro trabajo actual local. Para ello tenemos
que integrar ambas ramas de trabajo manualmente.
Fetch git fetch origin
comando
 Este comando va a descargar todos los
cambios nuevos que no tengamos en
nuestro repositorio local desde el
repositorio remoto y va a intentar
integrar automáticamente nuestro
Pull trabajo local actual con el que acaba
de traer.
Esto puede ser de gran ventaja a
Integrando los cambios en nuestro flujo de trabajo ya que no
nuestro repo local dependemos de una integración
manual en caso de estar seguros de lo
que estemos descargando desde el
proyecto remoto.
Pull git pull
comando
Ramas
Flujos de trabajo en con git
 Para entender realmente cómo ramifica Git, previamente
hemos de examinar la forma en que almacena sus datos.

Git no los almacena de forma incremental, sino que los

almacena como una serie de snapshots (copias puntuales
de los archivos completos, tal y como se encuentran en
ese momento).

Rama En cada confirmación de cambios (commit), Git almacena

un punto de control que conserva:

1. un apuntador a la copia puntual de los contenidos

o Branch 2.
preparados (staged),
unos metadatos con el autor y el mensaje
explicativo,
3. y uno o varios apuntadores a las confirmaciones
(commit) que sean padres directos de esta (un
padre en los casos de confirmación normal.
 Snapshots
Distintos commits de un archivo
 Un branch 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
Branch cambios que realicemos, se creará esta
rama principal master apuntando a
dicha confirmación.
Master
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.
 Branch
Al crear una nueva rama, se
obtiene un nuevo apuntador para
que lo puedas mover libremente
Branch git branch testing
comando
 Entre los archivos que maneja GIT
internamente, existe uno llamado

Checkout HEAD. Éste tiene una referencia al

branch actual.

como sabe git en que branch se Cuando cambiamos de branch,

encuentra usando el comando checkout, el
HEAD se actualiza.
Checkout git checkout testing
Comando
 Checkout
Alternando entre distintos
branches
 git commit -m ‘Un cambio nuevo’

Checkout
Hagamos un commit
 git checkout master

checkout
y ahora volvamos al branch
master
 Este comando realiza dos acciones:
Mueve el apuntador HEAD de nuevo a la
rama master, y revierte los archivos de tu
directorio de trabajo, dejándolos tal y
como estaban en la última instantánea
confirmada en dicha rama master. Esto
checkout supone que los cambios que hagas desde
este momento en adelante serán distintos
de la antigua versión del proyecto.
Entendiendo lo sucedido
Lo que se está haciendo es rebobinar el
trabajo que habías hecho temporalmente
en la rama testing, de tal forma que
puedas avanzar en otra dirección
diferente.