+ - 0:00:00
Notes for current slide
Notes for next slide

Taller Git y GitHub II

Herramientas informáticas para trabajos colaborativos

Matías Frugone-Álvarez

1 / 57

Tabla de Contenido

1. Fundamentos de Git

2. Fundamentos de GitHub

3. Fundamentos básicos sobre construcción de bases de datos

2 / 57

1. Fundamentos de Git

3 / 57

¿Qué es un control de versiones, y por qué debería importarte?

Un control de versiones es un sistema que registra los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante.


Si eres diseñador gráfico, de web o administrador de cualquier proyecto y quieres mantener cada versión (es algo que sin duda vas a querer), usar un sistema de control de versiones (VCS por sus siglas en inglés) es una decisión muy acertada.


Dicho sistema te permite regresar a versiones anteriores de tus archivos o proyecto completo, comparar cambios a lo largo del tiempo, ver quién modificó por última vez, ver quién introdujo un problema y cuándo, y mucho más.

4 / 57

1.1 Métodos de control de versiones

5 / 57

- Sistema control de versiones local (VCSL)

6 / 57

- Sistema control de versiones centralizado (CVCS)

7 / 57

- Sistemas de Control de Versiones Distribuidos (DVCS; como Git, Mercurial, Bazaar o Darcs)

8 / 57

¿Qué es Git?

9 / 57

Tres Estados de Git

1 Confirmado (committed) : significa que los datos están almacenados de manera segura en tu base de datos local.


2 Modificado (modified) : significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos.


3 Preparado (staged) : significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.

10 / 57

Las tres secciones principales de un proyecto de Git

  • El directorio de Git (Git directory) es donde se almacenan 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 otra computadora.

  • El directorio de trabajo (working directory) 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.

  • El área de preparación (staging area) es un 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.

11 / 57

El flujo de trabajo básico en Git es algo así:


  1. Modificas una serie de archivos en tu directorio de trabajo.

  2. Preparas los archivos, añadiéndolos a tu área de preparación.

  3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación y almacena esa copia instantánea de manera permanente en tu directorio de Git.


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

12 / 57

¿Qué es Git en pocas palabras?

13 / 57

1.2 Control de Versiones - La Línea de Comandos

14 / 57

Si quieres comprobar tu configuración, puedes usar el comando git config --list para mostrar todas las propiedades que Git ha configurado:

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
$ git config user.name
John Doe
15 / 57

¿Cómo obtener ayuda?

Si alguna vez necesitas ayuda usando Git, existen tres formas de ver la página del manual (manpage) para cualquier comando de Git:

$ git help <verb>
$ git <verb> --help
$ man git-<verb>
$ git help config
16 / 57

Obteniendo un repositorio Git

Puedes obtener un proyecto Git de dos maneras.

$ git init
#Esto crea un subdirectorio nuevo llamado .git,
# el cual contiene todos los archivos necesarios del repositorio – un
# esqueleto de un repositorio de Git.
# Si deseas obtener una copia de un repositorio Git existente
# — por ejemplo, un proyecto en el que te gustaría contribuir —
# el comando que necesitas es git clone.
$ git clone [url]
# Puedes clonar un repositorio con git clone [url].
# Por ejemplo, si quieres clonar la librería de Git llamada libgit2:
$ git clone https://github.com/libgit2/libgit2

Git te permite usar distintos protocolos de transferencia. El ejemplo anterior usa el protocolo https://, pero también puedes utilizar git:// o usuario@servidor:ruta/del/repositorio.git que utiliza el protocolo de transferencia SSH.

17 / 57

Guardando cambios en el Repositorio

El siguiente paso es realizar algunos cambios y confirmar instantáneas de esos cambios en el repositorio cada vez que el proyecto alcance un estado que quieras conservar.

Recuerda que cada archivo de tu repositorio puede tener dos estados: rastreados y sin rastrear.

Los archivos rastreados (tracked files en inglés) son todos aquellos archivos que estaban en la última instantánea del proyecto; pueden ser archivos sin modificar, modificados o preparados. Los archivos sin rastrear son todos los demás - cualquier otro archivo en tu directorio de trabajo que no estaba en tu última instantánea y que no está en el área de preparación (staging area). Cuando clonas por primera vez un repositorio, todos tus archivos estarán rastreados y sin modificar pues acabas de sacarlos y aun no han sido editados.

18 / 57

Guardando cambios en el Repositorio

19 / 57

Revisando el Estado de tus Archivos

La herramienta principal para determinar qué archivos están en qué estado es el comando git status.

$ git status
# Si ejecutas este comando ($ git status) inmediatamente después
# de clonar un repositorio, deberías ver algo como esto:
On branch master
nothing to commit, working directory clean

Esto significa que tienes un directorio de trabajo limpio - en otras palabras, que no hay archivos rastreados y modificados. Además, Git no encuentra archivos sin rastrear, de lo contrario aparecerían listados aquí. Finalmente, el comando te indica en cuál rama estás y te informa que no ha variado con respecto a la misma rama en el servidor. Por ahora, la rama siempre será “master”, que es la rama por defecto

20 / 57

Realizando un cambio de tus Archivos

Supongamos que añades un nuevo archivo a tu proyecto, un simple README. Si el archivo no existía antes y ejecutas git status, verás el archivo sin rastrear de la siguiente manera:

$ echo 'My Project' > README
$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)

Puedes ver que el archivo README está sin rastrear porque aparece debajo del encabezado “Untracked files” (“Archivos no rastreados” en inglés) en la salida. Sin rastrear significa que Git ve archivos que no tenías en el commit anterior. Git no los incluirá en tu próximo commit a menos que se lo indiques explícitamente. Se comporta así para evitar incluir accidentalmente archivos binarios o cualquier otro archivo que no quieras incluir. Como tú sí quieres incluir README, debes comenzar a rastrearlo.

21 / 57

Rastrear Archivos Nuevos

Para comenzar a rastrear un archivo debes usar el comando git add. Para comenzar a rastrear el archivo README, puedes ejecutar lo siguiente:

$ git add README
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README

Puedes ver que está siendo rastreado porque aparece luego del encabezado “Cambios a ser confirmados” (“Changes to be committed” en inglés). Si confirmas commit en este punto, se guardará en el historial la versión del archivo correspondiente al instante en que ejecutaste git add.

22 / 57

Preparar Archivos Modificados

echo 'My Project' > CONTRIBUTING.md
$ git status
$ git add CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md

Ambos archivos están preparados y formarán parte de tu próxima confirmación. En este momento, supongamos que recuerdas que debes hacer un pequeño cambio en CONTRIBUTING.md antes de confirmarlo. Abres de nuevo el archivo, lo cambias y ahora estás listos para confirmar. Sin embargo, ejecutemos git status una vez más:

$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md

Ahora CONTRIBUTING.md aparece como preparado y como no preparado. ¿Cómo es posible? Resulta que Git prepara un archivo de acuerdo al estado que tenía cuando ejecutas el comando git add. Si confirmas ahora, se confirmará la versión de CONTRIBUTING.md que tenías la última vez que ejecutaste git add y no la versión que ves ahora en tu directorio de trabajo al ejecutar git status. Si modificas un archivo luego de ejecutar git add, deberás ejecutar git add de nuevo para preparar la última versión del archivo:

$ git add CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
23 / 57

Estado Abreviado

Si bien es cierto que la salida de git status es bastante explícita, también es verdad que es muy extensa. Git ofrece una opción para obtener un estado abreviado, de manera que puedas ver tus cambios de una forma más compacta.

$ git status -s
$ git status --short

Los archivos nuevos que no están rastreados tienen un ?? a su lado, los archivos que están preparados tienen una A y los modificados una M. El estado aparece en dos columnas - la columna de la izquierda indica el estado preparado y la columna de la derecha indica el estado sin preparar.

24 / 57

Ver los Cambios Preparados y No Preparados

Si el comando git status es muy impreciso para ti - quieres ver exactamente que ha cambiado, no solo cuáles archivos lo han hecho - puedes usar el comando git diff. Git diff te muestra las líneas exactas que fueron añadidas y eliminadas, es decir, el parche.

$ git diff

Este comando compara lo que tienes en tu directorio de trabajo con lo que está en el área de preparación. El resultado te indica los cambios que has hecho pero que aun no has preparado.

Si quieres ver lo que has preparado y será incluido en la próxima confirmación, puedes usar git diff --staged. Este comando compara tus cambios preparados con la última instantánea confirmada.

git diff --staged

Es importante resaltar que al llamar a git diff sin parámetros no verás los cambios desde tu última confirmación - solo verás los cambios que aun no están preparados. Esto puede ser confuso porque si preparas todos tus cambios, git diff no te devolverá ninguna salida.

25 / 57

Confirmar tus Cambios

Ahora que tu área de preparación está como quieres, puedes confirmar tus cambios. Recuerda que cualquier cosa que no esté preparada - cualquier archivo que hayas creado o modificado y que no hayas agregado con git add desde su edición - no será confirmado. Se mantendrán como archivos modificados en tu disco.

$ git commit

Al hacerlo, arrancará el editor de tu preferencia. (El editor se establece a través de la variable de ambiente $EDITOR de tu terminal - usualmente es vim o emacs, aunque puedes configurarlo con el editor que quieras usando el comando git config --global core.editor. El editor mostrará el siguiente texto (este ejemplo usa Vim):

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# new file: README
# modified: CONTRIBUTING.md
~
".git/COMMIT_EDITMSG" 9L, 283C

Es importante resaltar que al llamar a git diff sin parámetros no verás los cambios desde tu última confirmación - solo verás los cambios que aun no están preparados. Esto puede ser confuso porque si preparas todos tus cambios, git diff no te devolverá ninguna salida.

26 / 57

Confirmación directa

Otra alternativa es escribir el mensaje de confirmación directamente en el comando commit utilizando la opción -m:

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
2 files changed, 2 insertions(+)
create mode 100644 README

¡Has creado tu primera confirmación (o commit)! Puedes ver que la confirmación te devuelve una salida descriptiva: indica cuál rama has confirmado (master), que checksum SHA-1 tiene el commit (463dc4f), cuántos archivos han cambiado y estadísticas sobre las líneas añadidas y eliminadas en el commit.

$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
1 file changed, 5 insertions(+), 0 deletions(-)

Si quieres saltarte el área de preparación, Git te ofrece un atajo sencillo. Añadiendo la opción -a al comando git commit harás que Git prepare automáticamente todos los archivos rastreados antes de confirmarlos, ahorrándote el paso de git add:

27 / 57

1.3 Fundamentos de Git - Trabajar con Remotos

28 / 57

Ver Tus Remotos

Los repositorios remotos son versiones de tu proyecto que están hospedadas en Internet o en cualquier otra red. Colaborar con otras personas implica gestionar estos repositorios remotos enviando y trayendo datos de ellos cada vez que necesites compartir tu trabajo.

29 / 57

Ver Tus Remotos

Para ver los remotos que tienes configurados, debes ejecutar el comando git remote. Si has clonado tu repositorio, deberías ver al menos origin - este es el nombre que por defecto Git le da al servidor del que has clonado:

$ git remote
origin
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)

Si tienes más de un remoto, el comando los listará todos. Por ejemplo, un repositorio con múltiples remotos para trabajar con distintos colaboradores podría verse de la siguiente manera.

$ cd grit
$ git remote -v
bakkdoor https://github.com/bakkdoor/grit (fetch)
bakkdoor https://github.com/bakkdoor/grit (push)
cho45 https://github.com/cho45/grit (fetch)
cho45 https://github.com/cho45/grit (push)
defunkt https://github.com/defunkt/grit (fetch)
defunkt https://github.com/defunkt/grit (push)

Esto significa que podemos traer contribuciones de cualquiera de estos usuarios fácilmente. Es posible que también tengamos permisos para enviar datos a algunos, aunque no podemos saberlo desde aquí.

30 / 57

Añadir Repositorios Remotos

Para añadir un remoto nuevo y asociarlo a un nombre que puedas referenciar fácilmente, ejecuta git remote add [nombre] [url]:

$ git remote
origin
$ git remote add pb https://github.com/paulboone/ticgit
$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)

A partir de ahora puedes usar el nombre pb en la línea de comandos en lugar de la URL entera. Por ejemplo, si quieres traer toda la información que tiene Paul pero tú aún no tienes en tu repositorio, puedes ejecutar git fetch pb:

$ git fetch pb
remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
From https://github.com/paulboone/ticgit
* [new branch] master -> pb/master
* [new branch] ticgit -> pb/ticgit

La rama maestra de Paul ahora es accesible localmente con el nombre pb/master - puedes combinarla con alguna de tus ramas, o puedes crear una rama local en ese punto si quieres inspeccionarla.

31 / 57

Traer, Combinar y Enviar a Tus Remotos

Para añadir un remoto nuevo y asociarlo a un nombre que puedas referenciar fácilmente, ejecuta git remote add [nombre] [url]:

Para obtener datos de tus proyectos remotos puedes ejecutar:

git fetch [remote-name]

Si has configurado una rama para que rastree una rama remota, puedes usar el comando git pull para traer y combinar automáticamente la rama remota con tu rama actual.

$ git pull

Cuando tienes un proyecto que quieres compartir, debes enviarlo a un servidor. El comando para hacerlo es simple: git push [nombre-remoto] [nombre-rama].

$ git push origin master

Si quieres ver más información acerca de un remoto en particular, puedes ejecutar el comando git remote show [nombre-remoto].

$ git remote show origin
32 / 57

1.4 Fundamentos de Git -Ramificaciones

33 / 57

¿Qué es una rama?

Cuando hablamos de ramificaciones, significa que tú has tomado la rama principal de desarrollo (master) y a partir de ahí has continuado trabajando sin seguir la rama principal de desarrollo.

34 / 57

¿Por qué esto es tan importante?

- Permite la colaboración increíblemente rápida

- Permite el avance o el retroceso entre ramas

- Permite crear y unir ramas entre sí

35 / 57

¿Cómo funciona?

En cada commit, Git almacena una instantánea de tu trabajo preparado. Dicha instantánea contiene además metadatos con el autor y el mensaje explicativo, y uno o varios apuntadores a las confirmaciones (commit) que sean padres directos de esta (un padre en los casos de confirmación normal, y múltiples padres en los casos de estar confirmando una fusión (merge) de dos o más ramas).

36 / 57

Un ejemplo

Vamos a generar tres archivos que prepararemos (stage) y los confirmaremos (commit).

$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'

En este momento, el repositorio de Git contendrá cinco objetos:

37 / 57

Un ejemplo

El repositorio de Git contendrá cinco objetos: un "blob" para cada uno de los tres archivos, un árbol con la lista de contenidos del directorio (más sus respectivas relaciones con los "blobs"), y una confirmación de cambios (commit) apuntando a la raíz de ese árbol y conteniendo el resto de metadatos pertinentes.

38 / 57

Un ejemplo

Si haces más cambios y vuelves a confirmar, la siguiente confirmación guardará un apuntador a su confirmación precedente.

39 / 57

¿Qué es una rama?

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.

40 / 57

Crear una Rama Nueva

¿Qué sucede cuando creas una nueva rama? Bueno…​, simplemente se crea un nuevo apuntador para que lo puedas mover libremente.

41 / 57

Crear una Rama Nueva

Por ejemplo, supongamos que quieres crear una rama nueva denominada "testing". Para ello, usarás el comando git branch:

$ git branch testing

42 / 57

Crear una Rama Nueva

Y, ¿cómo sabe Git en qué rama estás en este momento? Pues…​, mediante un apuntador especial denominado HEAD.

43 / 57

Cambiar de 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

44 / 57

¿Cuál es el significado de todo esto?

Bueno..., lo veremos tras realizar otra confirmación de cambios:

git commit -a -m 'made a change'

La rama testing avanza

45 / 57

Mientras

... la rama master permanece en la confirmación donde estaba cuando lanzaste el comando git checkout para saltar. Volvamos ahora a la rama master:

$ git checkout master

46 / 57

Haz algunos cambios más y confírmalos:

git commit -a -m 'made other changes'

Ahora el historial de tu proyecto diverge (ver Los registros de las ramas divergen). Has creado una rama y saltado a ella, has trabajado sobre ella; has vuelto a la rama original, y has trabajado también sobre ella. Los cambios realizados en ambas sesiones de trabajo están aislados en ramas independientes: puedes saltar libremente de una a otra según estimes oportuno. Y todo ello simplemente con tres comandos: git branch, git checkout y git commit.

47 / 57

Tres comandos: git branch, git checkout y git commit.

48 / 57

2. Fundamentos de GitHub

49 / 57

Participando en Proyectos: Bifurcación (fork)

Podemos bifurcar un proyecto, enviar tus propios cambios a tu copia y luego remitir esos cambios al repositorio original para su aprobación; creando lo que se llama un Pull Request

50 / 57

Para bifurcar un proyecto, visita la página del mismo y pulsa sobre el botón “Fork” del lado superior derecho de la página.

51 / 57

El Flujo de Trabajo en GitHub

Receta: FORK + Upstream + Pull Request

  1. Forkear un Repo

  2. Clonar el Repo a nuestro PC

  3. Crear una rama Upstream

    • git remote add upstream [el url oficial]
    • git remote -v (para ver las nuevas v.)
    • git fetch upstream
    • git rebase upstream/main
    • git push origin main --force
  4. Hacer los cambios y Push los cambios

  5. Hacer Pull Request

52 / 57

53 / 57

También puedes ir a la página “Branches” en https://github.com///branches para localizar la rama y abrir el Pull Request desde ahí.

54 / 57

Si pulsamos en el botón verde, veremos una pantalla que permite crear un título y una descripción para darle al propietario original una buena razón para tener en cuenta nuestro cambio.

55 / 57

Cuando seleccionas el botón Create pull request, el propietario del proyecto que has bifurcado recibirá una notificación de que alguien sugiere un cambio junto a un enlace donde está toda la información.

56 / 57
57 / 57

Tabla de Contenido

1. Fundamentos de Git

2. Fundamentos de GitHub

3. Fundamentos básicos sobre construcción de bases de datos

2 / 57
Paused

Help

Keyboard shortcuts

, , Pg Up, k Go to previous slide
, , Pg Dn, Space, j Go to next slide
Home Go to first slide
End Go to last slide
Number + Return Go to specific slide
b / m / f Toggle blackout / mirrored / fullscreen mode
c Clone slideshow
p Toggle presenter mode
t Restart the presentation timer
?, h Toggle this help
oTile View: Overview of Slides
sToggle scribble toolbox
Esc Back to slideshow