Uf2216 04-git

Programación de Sistemas IFCT0609
Profesor: Manel Montero

Programación de Sistemas IFCT0609 – Sistemas de Gestión IFCD0211
Profesor: Manel
Montero

INDICE
• Sistemas de Control de Versiones
Profesor: Manel

Control de Versiones
¿Qué es el control de versiones?
El control de versiones es un sistema que registra los
cambios realizados sobre un archivo o conjunto de
archivos a lo largo del tiempo, de modo que puedas
recuperar versiones específicas más adelante.
Profesor: Manel
Introducción

Cualquier tipo de archivo que encuentres en un
ordenador puede ponerse bajo control de versiones
Profesor: Manel
Introducción

Si eres diseñador gráfico o web, y quieres mantener cada
versión de una imagen o diseño (algo que sin duda quieres),
un sistema de control de versiones (Version Control System o
VCS en inglés) es una elección muy sabia.
Profesor: Manel
Introducción

Te permite revertir archivos a un estado anterior,
revertir el proyecto entero a un estado anterior,
comparar cambios a lo largo del tiempo,
ver quién modificó por última vez algo que puede estar
causando un problema,
quién introdujo un error
y cuándo, y mucho más.
Profesor: Manel
Introducción

Usar un VCS también significa generalmente que si fastidias o
pierdes archivos, puedes recuperarlos fácilmente.
Además, obtienes todos estos beneficios a un coste muy bajo.
Profesor: Manel
Introducción

Un método de control de versiones usado por mucha gente es
copiar los archivos a otro directorio (quizás indicando la fecha
y hora en que lo hicieron, si son avispados).
Este enfoque es muy común porque es muy simple, pero
también tremendamente propenso a errores.
Profesor: Manel
LOS METODOS DE LA GENTE…

Es fácil olvidar en qué directorio te encuentras, y guardar
accidentalmente en el archivo equivocado o sobrescribir
archivos que no querías.
Profesor: Manel

Para hacer frente a este problema, los programadores
desarrollaron hace tiempo VCSs locales que contenían una
simple base de datos en la que se llevaba registro de todos los
cambios realizados sobre los archivos.
Profesor: Manel

El siguiente gran problema que se encuentra la gente es que
necesitan colaborar con desarrolladores en otros sistemas. Para
solventar este problema, se desarrollaron los sistemas de
control de versiones centralizados (Centralized Version Control
Systems o CVCSs en inglés).
Profesor: Manel
Sistemas de Control de Versiones Centralizados

Estos sistemas, como CVS y Subversion tienen un único
servidor que contiene todos los archivos versionados, y varios
clientes que descargan los archivos desde ese lugar central.
Durante muchos años éste ha sido el estándar para el control
de versiones
Profesor: Manel

Profesor: Manel
Montero

Sin embargo, esta configuración también tiene serias
desventajas. La más obvia es el punto único de fallo que
representa el servidor centralizado. Si ese servidor se cae
durante una hora, entonces durante esa hora nadie puede
colaborar o guardar cambios versionados de aquello en que
están trabajando.
Profesor: Manel

Si el disco duro en el que se encuentra la base de datos central
se corrompe, y no se han llevado copias de seguridad
adecuadamente, pierdes absolutamente todo
—toda la historia del proyecto salvo aquellas instantáneas que
la gente pueda tener en sus máquinas locales.
Los VCSs locales sufren de este mismo problema— cuando
tienes toda la historia del proyecto en un único lugar, te
arriesgas a perderlo todo.
Profesor: Manel

Es aquí donde entran los sistemas de control de versiones
distribuidos (Distributed Version Control Systems o DVCSs en
inglés).
En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes
no sólo descargan la última instantánea de los archivos:
replican completamente el repositorio.
Profesor: Manel
Sistemas de Control de Versiones Distribuidos

Así, si un servidor muere, y estos sistemas estaban
colaborando a través de él, cualquiera de los repositorios de
los clientes puede copiarse en el servidor para restaurarlo.
Cada vez que se descarga una instantánea, en realidad se hace
una copia de seguridad completa de todos los datos
Profesor: Manel

Profesor: Manel
Montero

Profesor: Manel
Montero
GIT fue lanzado en 2005 por Linus Torvalds, el creador de
Linux, para mantener el código del propio Linux entre los
miles de Programadores que trabajan en su mantenimiento
actualmente.

Algunos de los objetivos del nuevo sistema fueron los
siguientes:
Velocidad
Diseño sencillo
Fuerte apoyo al desarrollo no lineal (miles de ramas
paralelas)
Completamente distribuido
Capaz de manejar grandes proyectos (como el núcleo de
Linux) de manera eficiente (velocidad y tamaño de los
datos)

Desde su nacimiento en 2005, Git ha evolucionado y
madurado para ser fácil de usar y aún conservar estas
cualidades iniciales.
Es tremendamente rápido, muy eficiente con grandes
proyectos, y tiene un increíble sistema de ramificación
(branching) para desarrollo no lineal

La principal diferencia entre Git y cualquier otro VCS
(Subversion y compañía incluidos) es cómo Git modela sus
datos.
Conceptualmente, la mayoría de los demás sistemas
almacenan la información como una lista de cambios en los
archivos. Estos sistemas (CVS, Subversion, Perforce, Bazaar,
etc.) modelan la información que almacenan como un
conjunto de archivos y las modificaciones hechas sobre
cada uno de ellos a lo largo del tiempo.

Git no modela ni almacena sus datos de este modo. En
cambio, Git modela sus datos más como un conjunto de
instantáneas de un mini sistema de archivos. Cada vez que
confirmas un cambio, o guardas el estado de tu proyecto en
Git, él básicamente hace una foto del aspecto de todos tus
archivos en ese momento, y guarda una referencia a esa
instantánea. Para ser eficiente, si los archivos no se han
modificado, Git no almacena el archivo de nuevo, sólo un
enlace al archivo anterior idéntico que ya tiene almacenado

La mayoría de las operaciones en Git sólo necesitan archivos
y recursos locales para operar. No se suele necesitar
información de ningún otro ordenador de tu red. Si estás
acostumbrado a un CVCS donde la mayoría de operaciones
tienen el retardo de red, este aspecto de Git te va a hacer
pensar que Git es maravilloso.
Como tienes toda la historia del proyecto ahí mismo, en tu
disco local, la mayoría de las operaciones parecen
prácticamente inmediatas.

GIT
Por ejemplo, para navegar por la historia del proyecto,
Git no necesita salir al servidor para obtener la historia y
mostrártela,
simplemente la lee directamente de tu base de datos local.

GIT
Si quieres ver los cambios introducidos en un archivo entre
la versión actual y la de hace un mes,
Git puede buscar el archivo hace un mes y hacer un cálculo
de diferencias localmente,
en lugar de tener que pedirle a un servidor remoto que lo
haga,
u obtener una versión antigua desde la red y hacerlo de
manera local.

GIT
Esto también significa que hay muy poco que no puedas
hacer si estás desconectado o sin VPN. Si te subes a un
avión o a un tren y quieres trabajar un poco, puedes
confirmar tus cambios felizmente hasta que consigas una
conexión de red para subirlos. Si te vas a casa y no
consigues que tu cliente VPN funcione correctamente,
puedes seguir trabajando. En muchos otros sistemas, esto
es imposible o muy doloroso. En Perforce, por ejemplo, no
puedes hacer mucho cuando no estás conectado al servidor;
y en Subversion y CVS, puedes editar archivos, pero no
puedes confirmar los cambios a tu base de datos (porque tu
base de datos no tiene conexión). Esto puede no parecer
gran cosa, pero te sorprendería la diferencia que puede
suponer.

GIT
Todo en Git es verificado mediante una suma de
comprobación (checksum en inglés) antes de ser
almacenado, El mecanismo que usa Git para generar esta
comprobación se conoce como hash SHA-1.
Se trata de una cadena de 40 caracteres hexadecimales (0-9
y a-f), y se calcula en base a los contenidos del archivo o
estructura de directorios. Un hash SHA-1 tiene esta pinta:
24b9da6552252987aa493b52f8696cd6d3b00373

GIT
Git guarda todo no por nombre de archivo, sino por el
valor hash de sus contenidos

PERDER DATOS !!!
Puedes perder o estropear cambios que no has confirmado
todavía;
pero después de confirmar una instantánea en Git, es muy
difícil de perder,
especialmente si envías (push) tu base de datos a otro
repositorio con regularidad

Los tres estados de git
Git tiene tres estados principales en los que se pueden
encontrar tus archivos:
confirmado (committed),
modificado (modified), y
preparado (staged).

PERDER DATOS !!!
Confirmado significa que los datos están almacenados de
manera segura en tu base de datos local.
Modificado significa que has modificado el archivo pero
todavía no lo has confirmado a tu base de datos.
Preparado significa que has marcado un archivo modificado
en su versión actual para que vaya en tu próxima
confirmación.

3 ESTADOS!!!

PERDER DATOS !!!
El directorio de Git es donde Git almacena los metadatos y
la base de datos de objetos para tu proyecto.
Es la parte más importante de Git, y es lo que se copia
cuando clonas un repositorio desde otro ordenador.

PERDER DATOS !!!
El directorio de trabajo es una copia de una versión del
proyecto.
Estos archivos se sacan de la base de datos comprimida en
el directorio de Git, y se colocan en disco para que los
puedas usar o modificar.

PERDER DATOS !!!
El área de preparación es un sencillo archivo, generalmente
contenido en tu directorio de Git,
que almacena información acerca de lo que va a ir en tu
próxima confirmación.
A veces se le denomina índice, pero se está convirtiendo en
estándar el referirse a ella como el área de preparación.

COMO SE TRABAJA EN GIT
El flujo de trabajo básico en Git es algo así:
Modificas una serie de archivos en tu directorio de trabajo.
Preparas los archivos, añadiendolos a tu área de
preparación.
Confirmas los cambios, lo que toma los archivos tal y como
están en el área de preparación, y almacena esas
instantáneas de manera permanente en tu directorio de Git.

ESTADOS DE UN FICHERO O VERSION DE UN ARCHIVO
Si una versión concreta de un archivo está en el directorio
de Git, se considera confirmada (committed).
Si ha sufrido cambios desde que se obtuvo del repositorio,
pero ha sido añadida al área de preparación, está preparada
(staged).
Y si ha sufrido cambios desde que se obtuvo del
repositorio, pero no se ha preparado, está modificada
(modified).

INSTALACION DE GIT
En Linux, instalamos GIT
En Ubuntu / Debian
$> sudo apt install git
En Windows:
Descargando e instalando desde su página
http://msysgit.github.com/

INSTALACION DE GIT
Una vez instalado, tendrás tanto la versión de línea de comandos (incluido
un cliente SSH que nos será útil más adelante) como la interfaz gráfica de
usuario estándar.
Nota para el uso en Windows: Se debería usar Git con la shell provista por
msysGit (estilo Unix), lo cual permite usar las complejas líneas de comandos
de este libro.
Si por cualquier razón se necesitara usar la shell nativa de Windows, la
consola de línea de comandos, se han de usar las comillas dobles en vez de
las simples (para parámetros que contengan espacios) y se deben
entrecomillar los parámetros terminándolos con el acento circunflejo (^) si
están al final de la línea, ya que en Windows es uno de los símbolos de
continuación.

USUARIO
Tu identidad
Lo primero que deberías hacer cuando instalas Git es
establecer tu nombre de usuario y dirección de correo
electrónico.
Esto es importante porque las confirmaciones de cambios
(commits) en Git usan esta información, y es introducida de
manera inmutable en los commits que envías:
$ git config --global user.name “Pepe Martin"
$ git config --global user.email pepe@gmail.com

USUARIO
Ahora que tu identidad está configurada, puedes elegir el
editor de texto por defecto que se utilizará cuando Git
necesite que introduzcas un mensaje. Si no indicas nada, Git
usa el editor por defecto de tu sistema, que generalmente
es Vi o Vim. Si quieres usar otro editor de texto, como
nano, puedes hacer lo siguiente:
$ git config --global core.editor nano

USUARIO
Tu herramienta de diferencias
Otra opción útil que puede que quieras configurar es la herramienta de diferencias
por defecto, usada para resolver conflictos de unión (merge). Digamos que quieres
usar vimdiff:
$ git config --global merge.tool vimdiff

USUARIO
Si quieres comprobar la configuración
$ git config --list

USUARIO
Ayuda
$ git help config

FUNDAMENTOS DE GIT
Inicializando un repositorio en un directorio existente
Si estás empezando el seguimiento en Git de un proyecto
existente, necesitas ir al directorio del proyecto y escribir:
$ git init

FUNDAMENTOS DE GIT
Esto crea un nuevo subdirectorio llamado .git que contiene
todos los archivos necesarios del repositorio —un esqueleto
de un repositorio Git.
Todavía no hay nada en tu proyecto que esté bajo
seguimiento.

FUNDAMENTOS DE GIT
Hemos creado un directorio proyectos/proyecto1 en /home/usuario con anterioridad
$mkdir /home/usuario/proyectos/proyecto1

FUNDAMENTOS DE GIT
Si deseas empezar a controlar versiones de archivos
existentes (a diferencia de un directorio vacío),
probablemente deberías comenzar el seguimiento de esos
archivos y hacer una confirmación inicial. Puedes
conseguirlo con unos pocos comandos git add para
especificar qué archivos quieres controlar, seguidos de
un commit para confirmar los cambios:
$ git add *.py
$ git add README
$ git commit –m 'versión inicial del proyecto'

FUNDAMENTOS DE GIT

FUNDAMENTOS DE GIT
Ahora traemos 3 archivos Python desde el puente
dado1.py
dado2.py
dado3.py

FUNDAMENTOS DE GIT
Para colaborar con un proyecto git, lo que hay que hacer es
un clone.
$>git clone git://github.com/schacon/grit.git
Si queremos darle otro nombre al proyecto.
$ git clone git://github.com/schacon/grit.git miproyectogrit

FUNDAMENTOS DE GIT
Para colaborar con un proyecto git, lo que hay que hacer es
un clone.
Por ejemplo también
El ejemplo anterior usa el protocolo
git://
http(s)://
usuario@servidor:/ruta.git
http(s):// o usuario@servidor:/ruta.git,

IMPORTAR UN PROYECTO- CLONE
En este caso
Git clone
usuario@192.168.1.140:/home/usuario/proyectos/proyecto
profe/.git

GUARDAR ESTADO NUEVO DE TU PROYECTO
Tienes un repositorio Git completo, y una copia de trabajo
de los archivos de ese proyecto.
Necesitas hacer algunos cambios, y confirmar instantáneas
de esos cambios a tu repositorio cada vez que el proyecto
alcance un estado que desees grabar.

Recuerda que cada archivo de tu directorio de trabajo
puede estar dos estados:
bajo seguimiento (tracked),
o sin seguimiento (untracked).
Los archivos bajo seguimiento existían en la última
instantánea; pueden estar sin modificaciones, modificados,
o preparados.
Los archivos sin seguimiento son todos los demás —
cualquiera que no estuviese en tu última instantánea ni está
en tu área de preparación—.
La primera vez que clonas, todos tus archivos estarán bajo
seguimiento y sin modificaciones, ya que los acabas de
copiar y no has modificado nada.

A medida que editas archivos, Git los ve como modificados,
porque los has cambiado desde tu última confirmación.
Preparas estos archivos modificados y luego confirmas
todos los cambios que hayas preparado, y el ciclo se repite

Ver el estado
$>git status
# On branch master nothing to commit, working directory clean
Esto significa que todo ok, sin cambios

Ignorar archivos
A menudo tendrás un tipo de archivos que no quieras que
Git añada automáticamente o te muestre como no
versionado. Suelen ser archivos generados
automáticamente, como archivos de log, o archivos
generados por tu compilador. Para estos casos puedes crear
un archivo llamado .gitignore, en el que listas los patrones
de nombres que deseas que sean ignorados.
He aquí un archivo .gitignore de ejemplo:
$ cat .gitignore
*.[oa]
*~
Ignorando archivos
A menudo tendrás un tipo de archivos que no quieras que Git añada automáticamente o te muestre como no versionado. Suelen ser archivos generados automáticam
$ cat .gitignore *.[oa] *~

Ignorar archivos
# a comment – this is ignored
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files
above
!lib.a
# only ignore the root TODO file, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .txt files in the doc/ directory
doc/**/*.txt

DIFERENCIAS DE ARCHIVOS
Para saber las diferencias de Archivos que has cambiado,
dispones del comando
$>git diff --staged
Compara la versión estable, con la ultima preparada
Ignorando archivos

DIFERENCIAS DE ARCHIVOS
Tienes que haber puesto git add para que se incluyan para
la siguiente confirmación.
Ignorando archivos

CONFIRMACION DE ARCHIVOS
Para confirmar LOS CAMBIOS EN EL SERVIDOR,
REALIZAREMOS
$>git commit
Cuando haces el git commit te pregunta que
“Cadena de texto a escribir para validar”
Escribes una cadena y guardas
Posteriormente se guardan los cambios validados en local.
Si quieres publicarlos se hará con “git push”
Ignorando archivos

CONFIRMACION DE ARCHIVOS
Si quieres confirmar directamente sin hacer el git add
$>git commit –a –m ‘Nuevos cambios’
Cuando haces el git commit te pregunta que
“Cadena de texto a escribir para validar”
Escribes una cadena y guardas
Posteriormente se guardan los cambios validados en local.
Si quieres publicarlos se hará con “git push”
Ignorando archivos

ELIMINACION DE ARCHIVOS
Si quieres ELIMINAR un archivo de GIT
$>git rm fichero
$>git rm log/*.log
Para eliminar un archivo de Git, debes eliminarlo de tus
archivos bajo seguimiento (más concretamente, debes
eliminarlo de tu área de preparación), y después confirmar.
El comando git rm se encarga de eso, y también elimina el
archivo de tu directorio de trabajo, para que no lo veas
entre los archivos sin seguimiento.
Con el parámetro –f se fuerza la eliminación

ELIMINACION DE ARCHIVOS
Si quieres eliminar el archivo del seguimiento de Git, pero
que siga en el área de trabajo
$>git rm --cached readme.txt

RENOMBRAR ARCHIVOS
$ git mv FICHERO_VIEJO_NOMBRE FICHERO_NUEVO_NOMBRE

Proyecto Para pruebas
git clone git://github.com/schacon/simplegit-progit.git
Probar después el “$>git log” para ver la secuencia de
commits sobre el proyecto. Aparecen en orden inverso
$>git log –p -2
-p muestra los mensajes
-2 muestra los dos últimos commits

Para visualizar el log más fácil
Gitk

Para visualizar el log más fácil
Si haces un commit y por ejemplo te has dejado un fichero
$ git commit -m ‘Commit inicial del martes 15’
$ git add fichero_olvidado
$ git commit –amend
Estos tres comandos acabarán convirtiéndose en una única confirmación —la
segunda confirmación reemplazará los resultados de la primera

Para sacar del área de preparacion
Preparas 2 archivos y quieres quitar uno
$>git add fichero1
$>git add fichero2
$> git status  Están los 2 ficheros
$>git reset HEAD fichero2
$git status  Solo estará el fichero1 ahora

Para volver a la antigua versión de un archivo
$>git checkout -- fichero.txt
Volverá a la versión validada ultima de fichero.txt

TRABAJAR CON REPOSITORIOS REMOTOS

Con repositorios remotos
Puedes tener varios,
Cada uno de los cuales puede ser de sólo lectura, o de
lectura/escritura, según los permisos que tengas.
Colaborar con otros implica gestionar estos repositorios
remotos, y
mandar (push) y
recibir (pull)
datos de ellos

Para saber los remotos, hacemos git remote
Si no sale nada, estamos en el servidor
Si sale origin (Es el servidor del que clonamos. Por defecto)
Si sale otra cosa, es el servidor del que clonamos
$ git remote -v

Si hay más de un remoto, se listan todos: (Pero solo se puede enviar al
remoto origen)

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

Enviar Info al servidor
$>git push origin master
Manda la información del Proyecto principal (master)
al Repositorio origin

Enviar Info al servidor
$>git push origin master
Este comando funciona únicamente si has clonado de un servidor en el
que tienes permiso de escritura, y nadie ha enviado información mientras
tanto. Si tú y otra persona clonais a la vez, y él envía su información y
luego envías tú la tuya, tu envío será rechazado. Tendrás que bajarte
primero su trabajo e incorporarlo en el tuyo para que se te permita hacer un
envío. para ver en detalle cómo enviar a servidores remotos.

FIN
Gracias por la atención !!!
Profesor: Manel
Montero
Gracias por la atención.

Uf2216 04-git

Más contenido relacionado

Similar a Uf2216 04-git (20)

Más de Manel Montero (7)

Último (20)

Uf2216 04-git