Git: Aprovecha las ventajas del control de versiones distribuido

Iñaki [email protected]

https://twitter.com/iarenazahttps://linkedin.com/in/iarenaza

Creative CommonsAttribution Non-commercial Share Alike3.0 Spain License

Aprovecha las ventajas del control de versiones distribuido

2

Descargar la presentación

Puedes descargar la presentación desde http://www.slideshare.net/iarenaza/git-aprovecha-las-ventajas-del-control-de-versiones-distribuido

O puedes usar el siguiente código QR:

3

Objetivos

Proporcionar una base teórica y práctica de los conceptos en los que se basan los SCM distribuidos.

Ser capaz de realizar las tareas habituales de un SCM con Git.

Conocer y aplicar las ventajas del modelo de trabajo de los SCM distribuidos.

4

Programa

Características principales de Git

Introducción a los conceptos manejados por Git: repositorios, objetos, estados, referencias, ramas, etc.

Instalación de Git en Windows y Linux

Configuración básica de Git en Windows y Linux

Creación de repositorios nuevos con Git

Operaciones básicas con Git

Trabajo con repositorios "remotos"

Propuesta de un modelo de trabajo distribuido

Otras operaciones con Git

5

Sistemas de Control de Versiones Centralizados (CVCS)

Ejemplos: CVS, Subversion, Perforce, SourceSafe, ...

Fuente: http://progit.org/book/ch1-1.html (CC-BY-NC-SA 3.0)

6

Sistemas de Control de Versiones Distribuidos (DVCS)

Ejemplos: git, Mercurial, Bazaar, BitKeeper,...


7

Diferencias versus instantáneas

git,Mercurial*

Bazaar,Mercurial*



8

(Algunas) características de git

(Casi) todas las operaciones son locales

Git tiene integridad fuerte (sha1)

Git (generalmente) sólo añade datos al

repositorio

9

Los tres espacios y tres estados

Modified* Staged Committed


10

Los tres espacios

El directorio git (repositorio) es donde git almacena los metadatos y la base de datos de objetos para tu proyecto.

El directorio de trabajo es una copia de trabajo de una versión del proyecto.

El área de preparación (staging area) es un archivo que almacena información sobre lo que se guardará en el próximo commit. Antes se le llamaba “el índice” (index).

11

Los tres estados

Confirmado/no modificado (committed): los datos están almacenados de manera segura en el repositorio.

Modificado (modified): se ha modificado el archivo pero todavía no se ha confirmado.

Preparado (staged): se ha marcado para confirmación un archivo modificado en su versión actual.

12

Los “tres + 1” estados


El estado3+1

13

Terminología de git

En los ejemplos siguientes $GIT_DIR contiene la ruta de un repositorio git dado

objeto: unidad de almacenamiento en git. Se identifica de forma unívoca por el SHA1 de su contenido.

Por tanto, un objeto es inmutable.

14

Terminología de git (cont.)

nombre de objeto o identificador de objeto: identificador único del objeto (de 40 octetos con

la representación hexadecimal del SHA1 de su contenido)

base de datos de objetos: almacena un conjunto de objetos (habitualmente en

$GIT_DIR/objects/).

ref o referencia: cadena de 40 octetos con el identificador de un objeto, o un nombre simbólico (que se almacena en $GIT_DIR/refs/) que denota o “apunta” un objeto particular.

15


revisión: estado concreto de una serie de ficheros y directorios que ha sido almacenado en la base de datos de objetos. Se hace referencia a él por medio de un objeto de tipo commit (ver más adelante)

padre: un objeto commit contiene una lista (potencialmente vacía) de objetos commit que representan a sus predecesores lógicos en la línea de desarrollo, esto es, sus los objetos commit padre.

16


Repositorio (directorio git): colección de referencias y base de datos de objetos (alcanzables desde dichas referencias).

Puede contener además algunos meta datos adicionales usados por determinas órdenes de git.

Puede contener una copia de trabajo de una revisión.

repositorio desnudo (bare): repositorio que no tiene una copia de trabajo.

Los ficheros de git que normalmente estarían presentes en el subdirectorio oculto .git están presentes en el propio directorio del repositorio.

17


árbol de trabajo o copia de trabajo: Una revisión extraida (checked out) del repositorio, para poder trabajar con ella.

índice: una colección de ficheros con información de stat(2)*, cuyos contenidos están almacenados como objetos.

El índice es una versión almacenada intermedia del árbol de trabajo.

* stat(2) es la llamada del sistema Unix que nos proporciona información de un fichero como su tamaño, sus fechas de creación, modificación y acceso, sus permisos, etc.

18

Tipos de objetos de git

blob: objeto sin tipo, para representar una ristra de octetos (un fichero)

tree: lista de nombres y permisos, junto con las referencias de objetos blob (un directorio)

También puede tener referencias a otros objetos de tipo tree asociados, con lo que puede representar árboles de directorios con ficheros.

IMPORTANTE: Si un directorio en disco no contiene ningún fichero (“blob”) git no creará un objeto de tipo “tree” para representarlo ni guardará su existencia o estado.

19

Tipos de objetos de git (cont.)

commit: información de una revisión dada guardada en el repositorio. Incluye:

los identificadores de los padres del objeto,

la persona que ha realizado el commit de la revisión (nombre + email),

el autor de la revisión (nombre + email),

la fecha de la misma,

un mensaje de texto arbitrariamente largo asociado,

el objeto tree que corresponde al directorio raíz de la revisión.

20


tag: identifica de forma simbólica a otros objetos y puede ser usado para firmar éstos. Contiene:

el nombre y tipo de otro objeto,

un nombre simbólico (el de la propia tag)

puede contener un mensaje asociado.

opcionalmente puede incluir una firma digital (en formato PGP). En este último caso se denomina un "objeto de etiqueta firmada".

Las etiquetas normales se pueden modificar (para que apunten a otro objeto), pero las firmadas no.

21



22



23


rama: línea activa de desarrollo.El commit más reciente de una rama se denomina la punta de dicha rama. La punta de la rama se referencia por medio de una cabeza.

La copia de trabajo está siempre asociada a una rama (la rama "actual" o "checked out") y la cabeza especial “HEAD” apunta a esa rama.

cabeza: una referencia con nombre, que apunta al objeto commit de la punta de una rama.

Las cabezas se almacenan en $GIT_DIR/refs/heads/, (salvo que se usen referencias empaquetadas).

24


checkout: acción de actualizar parte o todo el árbol de trabajo con un objeto árbol o blob desde la base de datos de objeto

Además actualiza el índice y la referencia HEAD si se ha cambiado de rama.

25


Supongamos este estado “inicial”1


26



Ejecutamos:$ git branch testing

2

27



master sigue siendo la rama activa en la copia de trabajo

3

28



Ejecutamos:$ git checkout testing

testing pasa a ser la rama activa en la copia de trabajo

4

29


Ejecutamos:$ git add some-file(s)$ git commit -m ...

1


30


Ejecutamos:$ git checkout master

2


31


Ejecutamos:$ git add some-file(s)$ git commit -m ...

3


32


merge: fusionar los contenidos de otra rama (potencialmente desde un repositorio externo) en la rama actual.

Si la rama es de otro repositorio, primero se hace un fetch* de la rama y después se fusiona en la rama actual.

La fusión puede crear un nuevo objeto commit si una de las ramas no es un ancestro de la otra.

Si una es ancestro de la otra, simplemente se mueve la referencia de la cabeza de la rama fusionada (fast-forward merge).

33

merge: escenario 1

1


Supongamos este estado “inicial”

34

merge: escenario 1

2


Ejecutamos:$ git branch hotfix master$ git checkout hotfix$ git add ...$ git commit

35

merge: escenario 1

3


Ejecutamos:$ git checkout master$ git merge hotfix

36

merge: escenario 2

1


Ejecutamos:$ git checkout -b iss53 master$ git add ...$ git commit$ git checkout master$ git add ….$ git commit

37

merge: escenario 2

2


Ejecutamos:$ git merge iss53

38

merge: escenario 2

3


El resultado es:

39

Operaciones en el área de trabajo

Crear nuevas ramas locales (ultra rápido y baratísimo en disco):

Extraer una rama al área de trabajo:

Consultar la rama activa:

Mostrar el estado del área de trabajo:

Marcar cambios para commit:

$ git branch ref-nueva-rama ref-o-etiqueta-existente

$ git checkout ref--existente

$ git branch (es la que aparece marcada con un '*')

$ git status

$ git add fichero1 fichero2 ...$ git rm fichero3 fichero4 ...

40


Mostrar diferencias con el área de preparación o con HEAD:

Mostrar diferencias con otras ramas:

Hacer commit de los cambios (marcados):

Usar gitk para visualizar el historial de una rama:

Usar gitk para visualizar el historial de todas las ramas:

$ git diff$ git diff HEAD

$ git diff ref-existente$ git diff ref-existente-1..ref-existente-2

$ git commit

$ gitk ref-existente

$ gitk --all

41


Resetear el área de trabajo y el área intermedia al estado de HEAD (o cualquier otra referencia):

Resetear el área de preparación al estado de HEAD (o cualquier otra referencia):

Mover la referencia de HEAD a otro commit sin tocar ni el área de trabajo ni el área intermedia:

$ git reset --hard HEAD

$ git reset --mixed HEAD

$ git reset --soft HEAD~

42

Trabajo con repositorios remotos

clone: obtener una copia local completa* de un repositorio git remoto.


* las cabezas de las ramas remotas son inamovibles** en la copia local

43

Trabajo con repositorios remotos (cont.)

fetch: obtener la cabeza de una rama (o varias) desde un repositorio remoto, copiando los objetos falten y moviendo la(s) cabeza(s) remota(s).


44


Fetch: alguien hace cambios en el repositorio remoto


1

45


Fetch: ejecutamos fetch e incorporamos esos cambios en nuestro repositorio


2

46


pull: hacer un fetch seguido de un merge en la rama local con la rama remota configurada.

push: enviar los objetos de la rama local que no están en la rama remota a la que hace referencia el pull, y actualizar la cabeza de la rama remota.

Es la acción complementaria de pull.

Si la cabeza de la rama remota no es un ancestro de la cabeza de la rama local, el push falla*.

(*) Podemos forzar el push, pero rescribimos el historial del repositorio (¡es una posible fuente de problemas si el repositorio es compartido!)

47

Clonar un repositorio “remoto” (usando diferentes transportes):

$ git clone git://git.moodle.org/moodle.git

$ git clone ssh://[email protected]/moodle.git

$ git clone http://git.moodle.org/moodle.git

$ git clone [email protected]:iarenaza/moodle.git

$ git clone /ruta/a/moodle.git /ruta/a/otro-moodle.git

$ git clone -o moodle.git [email protected]:iarenaza/moodle.git


48

Incorporar nueva rama del repositorio remoto al repositorio local:

Enviar ramas locales al repositorio remoto:

Configurar rama para poder hacer pull desde repositorio remoto:

$ git push moodle.git ref-nueva-o-existente$ git push moodle.git +ref-nueva-o-existente$ git push moodle.git ref-nombre-local:ref-nombre-remoto

$ git config branch.ref-local.remote moodle.git$ git config branch.ref-local.merge refs/heads/ref-remota

$ git fetch moodle.git$ git branch ref-nueva moodle.git/ref-existente


49

Ejemplo de modelo de trabajo distribuido

Para mantener modificaciones locales de

Moodle en Mondragon Unibertsitatea

50

Premisas del modelo de trabajo

Repositorio 'compartido' de referencia

51


Aprovechar el repositorio de git.moodle.org

No usar 'git clone' para la importación desde

git.moodle.org

52


Repositorio compartido sólo con ramas locales

53


Desarrollo siempre en las ramas locales

54


Ramas estándar sólo en repositorios de los

desarrolladores

55

git.moodle.org

repositorio [email protected]

copia de trabajo

+repositorio

desarrollador

git-remote+ git-push git-fetch

git-push

git-pullgit-fetch

git-push

git-pull

git-remote + git-fetchgit-fetch / git-pull

git-clone git-clone


git-fetch

git-push

git-pull

56

git.moodle.org


copia de trabajo

+repositorio

desarrollador


git-push

git-pullgit-fetch

git-push

git-pull


git-clone git-clone


git-fetch

git-push

git-pull

Creación repositorio compartido

$ git config --global user.name 'Desarrollador-1'$ git config --global user.email '[email protected]'$ cd /ruta/repositorio/desarrollador$ mkdir desarrollador-1.git$ cd desarrollador-1.git$ git init

Crear repositorio primer desarrollador

57

git.moodle.org


copia de trabajo

+repositorio

desarrollador


git-push

git-pullgit-fetch

git-push

git-pull


git-clone git-clone


git-fetch

git-push

git-pull


Importar repositorio de moodle.org

$ git remote add -t master -t MOODLE_21_STABLE \ -m master moodle-org \ git://git.moodle.org/moodle.git$ git fetch moodle-org

58


Ramas locales de seguimiento (opcional)

$ git branch --track master moodle-org/master$ git branch --track MOODLE_22_STABLE \ moodle-org/MOODLE_22_STABLE

59


Crear ramas locales de trabajo

$ git branch mdl22-ldap-refactor moodle-org/MOODLE_22_STABLE

60

git.moodle.org


copia de trabajo

+repositorio

desarrollador


git-push

git-pullgit-fetch

git-push

git-pull


git-clone git-clone


git-fetch

git-push

git-pull


Crear repositorio compartido en servidor Linux/Unix

$ cd /ruta/repositorio/compartido$ mkdir compartido.git$ cd compartido.git$ git --bare init --shared=all$ chmod g=rwxs,o=rx .$ sudo chgrp -R git-moodle .

61

git.moodle.org


copia de trabajo

+repositorio

desarrollador


git-push

git-pullgit-fetch

git-push

git-pull


git-clone git-clone


git-fetch

git-push

git-pull


Enviar rama local al repositorio compartido

$ cd /ruta/repositorio/desarrollador/desarrollador-1.git$ git remote add compartido \ /ruta/repositorio/compartido/compartido.git$ git push compartido mdl22-ldap-refactor

62


Configurar rama local para hacer pull desde repositorio compartido

$ git config branch.mdl22-ldap-refactor.remote \ compartido$ git config branch.mdl22-ldap-refactor.merge \ refs/heads/mdl22-ldap-refactor

63

git.moodle.org


copia de trabajo

+repositorio

desarrollador


git-push

git-pullgit-fetch

git-push

git-pull


git-clone git-clone


git-fetch

git-push

git-pull

Creación repo nuevo desarrollador

Clonar repositorio compartido

$ git config --global user.name 'Desarrollador-2'$ git config --global user.email '[email protected]'$ cd /ruta/repositorio/desarrollador$ git clone -o compartido \ /ruta/repositorio/compartido/compartido.git \ desarrollador-2.git

64

git.moodle.org


copia de trabajo

+repositorio

desarrollador


git-push

git-pullgit-fetch

git-push

git-pull


git-clone git-clone


git-fetch

git-push

git-pull


Importar ramas estándar (opcional)

$ cd desarollador-2.git$ git remote add -t master -t MOODLE_22_STABLE \ -m master moodle-org \ git://git.moodle.org/moodle.git$ git fetch moodle-org

65


Crear ramas locales de trabajo

$ git branch mdl22-ldap-refactor \ compartido/mdl22-ldap-refactor$ git checkout mdl22-ldap-refactor

66

Una propuesta de modelo de trabajo con las ramas

Propuesto por Vincent Driessen en su blog http://nvie.com/posts/a-successful-git-branching-model/

Se puede descargar el PDF (licencia CC-BY) con el esquema de ramas propuesto desde http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf

La descripción del modelo en el blog explica no sólo los “cómos” sino también los “porqués”.

67

Otras operaciones con git

Reescritura del historial de una rama (“haciendo limpieza”).

rebase: re-aplicar una serie de cambios desde una rama en la cabeza de otra rama diferente, y hacer que la cabeza de esa otra rama apunte al resultado.

¡OJO! Reescribe el historial de la rama.

Puede ser problemático en ramas publicadas en repositorios compartidos.

68

rebase: reescritura del historial

1 Estado “inicial”. master esla rama activa en el directoriode trabajo.


69

rebase: reescritura del historial (cont.)

2 merge tradicional de “master” y “experiment”:$ git merge experiment


70


3 rebase de “experiment” sobre “master”$ git checkout experiment$ git rebase master


71


4 merge de “master” y “experiment” tras el rebase:$ git merge experiment(es un simple 'fast-forward')


72

Reescritura del historial

IMPORTANTE: No hace rebase de los cambios de una rama si ésta ha sido publicada en otro repositorio, a menos que se sea consciente de las implicaciones.

Estamos creando nuevos objetos y cambiando los ancestros de los commits existentes en la rama.

Creará confusión y caos a quienes hayan clonado nuestro rama (repositorio) si han creado sus propios commits a partir de nuestra rama.

73

Reescritura del historial

Conviene aplicarla sólo a la rama activa (evita sorpresas):

Si hay conflictos, solucionar a mano, y decirle a git qué hemos arreglado y que continue el proceso:

Podemos abortar en todo momento:

$ git checkout wip-mdl22-enrol-db-refactor$ git rebase MOODLE_22_STABLE

$ editar enrol/database/config.html$ git add enrol/database/config.html enrol/database/enrol.php$ editar xxxx$ git add xxxxx$ git rebase --continue

$ git rebase --abort

74

Rescritura “interactiva” del historial

Permite elegir (¡y reordenar!) los commits que vamos a rebasar.

Nos deja en un editor con la lista de los commits y unas palabras clave para indicar como tratar cada commit.

Además de usar las operaciones marcadas por las palabras clave, podemos reordenar los commits simplemente cambiando el orden de las líneas.

$ git checkout wip-mdl22-enrol-db-refactor$ git rebase -i MOODLE_22_STABLE

75

Rescritura “interactiva” del historial

pick 72ed614 MDL-30935_in_lti_change_role_from_instructorpick 3360b13 MDL-31251 documentation : fix incorrect docspick 8150fd9 Automatically generated installer lang filespick a97d4da Automatically generated installer lang filespick 0dde394 weekly release 2.3devpick 45b6c23 MDL-28585 LDAP doesn't handle password expiration

# Rebase 1609f3c..45b6c23 onto 1609f3c## Commands:# p, pick = use commit# r, reword = use commit, but edit the commit message# e, edit = use commit, but stop for amending# s, squash = use commit, but meld into previous commit# f, fixup = like "squash", but discard this commit's log message## If you remove a line here THAT COMMIT WILL BE LOST.# However, if you remove everything, the rebase will be aborted.

76

Otras operaciones con git

Creación de parches monolíticos:

Creación de series de parches:

$ git checkout mdl22-enrol-db-refactor$ git diff MOODLE_22_STABLE > mdl22-enrol-db-refactor.diff

$ git checkout mdl22-enrol-database-refactor$ git format-patch -o serie-enrol-db MOODLE_22_STABLE$ git format-patch -o -s -10 MOODLE_22_STABLE

77

Algunos trucos bajo la manga(bonus track ☺)

git add --interactive

git cherry-pick

git stash [save | list | show | apply | remove | clear]

git bisect

git blame

git gc, git prune, git fsck

.git/hooks/*

78

Algunas direcciones de interés

Página oficial de Git:

http://www.git-scm.org/

Libro Pro Git:

http://progit.org/book/

Página de msysgit (Git para Windows)

http://code.google.com/p/msysgit/

Página de TortoiseGit (GUI para Windows):

http://code.google.com/p/tortoisegit/

http://code.google.com/p/tortoisegit/wiki/UsingPuTTY

Página de Egit (plugin para Eclipse):

http://www.eclipse.org/egit/

http://www.eclipse.org/downloads/compare.php

Página de SourceTree (Git para MacOSX):

http://www.sourcetreeapp.com/

http://www.git-scm.org/

http://progit.org/book/

http://code.google.com/p/msysgit/

http://code.google.com/p/tortoisegit/

http://code.google.com/p/tortoisegit/wiki/UsingPuTTY

http://www.eclipse.org/egit/

http://www.eclipse.org/downloads/compare.php

http://www.sourcetreeapp.com/

79

Algunas direcciones de interés

Git Cheat Sheets:

http://devcheatsheet.com/tag/git/

A successful Git branching model

http://nvie.com/posts/a-successful-git-branching-model/

github/GITORIOUS:

https://github.com/ y https://gitorious.org/

gitosis:

https://secure.wikimedia.org/wikibooks/en/wiki/Git/Gitosis

http://thinkshout.com/blog/2011/03/lev/redmine-and-gitosis-project-management-nirvana

gitolite:

https://github.com/sitaramc/gitolite

Gerrit:

https://code.google.com/p/gerrit/

http://devcheatsheet.com/tag/git/

http://nvie.com/posts/a-successful-git-branching-model/

https://github.com/

https://gitorious.org/

https://secure.wikimedia.org/wikibooks/en/wiki/Git/Gitosis

http://thinkshout.com/blog/2011/03/lev/redmine-and-gitosis-project-management-nirvana

https://github.com/sitaramc/gitolite

https://code.google.com/p/gerrit/

Technology

Git: Aprovecha las ventajas del control de versiones distribuido