Control de versiones con Git y Github

Control de versiones con Git y GitHub

Raúl MurcianoDesarrollador Web Freelance

II Jornadas Conocimiento Libre Universidad Europea de Madrid - GLUEM

Índice

•Control de versiones

•Git

•GitHub

Copyleft Vicente J. Ruiz JuradoCreative Commons, atribución, comparte por igual.

HERRAMIENTAS LIBRES

CONOCIMIENTO LIBRE

SOFTWARE LIBRE

EQUIPO

SOLO

Ventajas del Control de Versiones:Almacenamiento y Backup

Ventajas del Control de Versiones:Control de Acceso mediante permisos

Ventajas del Control de Versiones:

Deshacer ILIMITADO

Ventajas del Control de Versiones:

Deshacer ILIMITADO

Ventajas del Control de Versiones:Mezclar aportaciones

de distintos colaboradores

Ventajas del Control de Versiones:Todos se mantienen sincronizados fácilmente

Ventajas del Control de Versiones:Histórico de Cambios

• Quién

• Qué

• Cuándo

• Para Qué

Ventajas del Control de Versiones:Versiones en paralelo

Copiar y Pegar archivos

NOes Control de Versiones

Practica1

Practica1_enero_14_fulano

Practica1_enero_14_final

Practica1_enero_14_final_de_verdad

Batallita

Vocabulario Básico:

• “repositorio”: almacén de datos que guarda cada versión de nuestro proyecto, incluyendo los datos asociados a cada commit

• “commit”: cambio de una versión a otra

Ejemplo: lista de la compra

versión 0

(vacía)

(vacía) (vacía)

Ejemplo: lista de la compra

versión 0

(vacía)

hamburguesa (vacía)

Ejemplo: lista de la compra

versión 0

hamburguesa

hamburguesa (vacía)

commit

Ejemplo: lista de la compra

versión 1

hamburguesa

hamburguesa hamburguesa

Ejemplo: lista de la compra

versión 1

hamburguesa

hamburguesahamburguesa

verdura

Ejemplo: lista de la compra

versión 2

verdura

hamburguesahamburguesa

verdura

commit

Ejemplo: lista de la compra

versión 2

verdura

hamburguesacerveza

verdura

Ejemplo: lista de la compra

versión 2

verdura

hamburguesacerveza

verdura

intenta enviar un commit pero no lo

consigue: hay conflictos

Ejemplo: lista de la compra

versión 2

verdura

hamburguesacerveza

verdura

tiene que actualizar su versión local,

resolver los conflictos y volver a

enviar un nuevo commit

Ejemplo: lista de la compra

versión 2

verdura

hamburguesaverduracerveza

verdura

Ejemplo: lista de la compra

versión 3

verduracerveza

hamburguesaverduracerveza

verdura

commit

Ejemplo: lista de la compraEl repositorio almacena todas las versiones y los cambios

(vacía)

hamburguesa

verdura

verduracerveza

10:30

10:35

10:40

“Para cenar, hamburguesas...”

“¿Con esa panza? ¡Más verdura y menos grasa!”

“Al menos que sea con una cervecita...”

Otro ejemplo: editor de textos

Planificación del desarrollo: se especifican las primeras funcionalidades y se priorizan.

1. Abrir/Guardar archivo

2. Edición

3. Copiar/Pegar

4. Formato negrita/cursiva/subrayado

5. ...

Otro ejemplo: editor de textos

1 2 3 4

Otro ejemplo: editor de textos

1 2 3 4

Se pueden etiquetar versiones concretas, para localizarlas fácilmente en la historia del repositorio.

Tag v0.1

Otro ejemplo: editor de textos

1 2 3 4

¿Qué ocurre si mientras estamos desarrollando la funcionalidad 4 se descubre un bug en alguna de las anteriores?

Tag v0.1

Otro ejemplo: editor de textos

1 2 3

4

Para evitar esto se suele trabajar en “ramas”

Tag v0.1

3a

Tag v0.1.1

rama producción

rama desarrollo

Otro ejemplo: editor de textos

1 2 3

Cuando la rama de desarrollo sea estable la fusionaremos con la de producción

Tag v0.1

3a

Tag v0.1.1

4 5

6

Tag v0.2

Toque final: permisos

• Normalmente los proyectos libres permiten que cualquiera pueda leer (descargar) el contenido del repositorio

• ...pero no escribir. Para contribuir hay que enviar parches que serán aplicados por el equipo de desarrollo oficial

• Si alguien aporta muchos parches se le termina dando permiso de escritura

Integration Manager

Scott Chacon, Scotland on Rails Mar’09

integration manager

blessedrepository

developerprivate

developerprivate

Scott Chacon, Scotland on Rails Mar’09

Integration Manager

developerpublic

developerpublic

integration manager

blessedrepository

developerprivate

developerprivate

Scott Chacon, Scotland on Rails Mar’09

Dictador/Tenientes

developerdeveloper

dictator

developer

lieutenant

blessed repository

developer

lieutenant

Scott Chacon, Scotland on Rails Mar’09

Dictador/Tenientes

developerdeveloper

dictator

developer

lieutenant

blessed repository

developer

lieutenant

Scott Chacon, Scotland on Rails Mar’09

Tipos de Sistemas de Control de Versiones

• Incrementales vs basados en snapshots (“instantáneas”)

• Centralizados vs Distribuidos

!"#$%

&$'(%)"

!"#$% !&

!"#$'

!"#$(

(& () (* (+ (,

!)

!& !)

!& !) !*

%

'

(

(& () (* (+ (,

%&

'

(&

%&

'

()

%)

'&

()

%)

')

(*

&*%+&,'$

&$'(%)"

Scott Chacon, Scotland on Rails Mar’09

!"#$%

&$'(%)"

!"#$% !&

!"#$'

!"#$(

(& () (* (+ (,

!)

!& !)

!& !) !*

%

'

(

(& () (* (+ (,

%&

'

(&

%&

'

()

%)

'&

()

%)

')

(*

&*%+&,'$

&$'(%)"

Scott Chacon, Scotland on Rails Mar’09

Git es distribuido

• Aunque se trabaje con un repositorio remoto, siempre se tiene uno en local

directorio local de trabajo

área de cambios (“staging”)

repositoriolocal (privado)

repositorioremoto(público)

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositoriolocal (privado)

repositorioremoto(público)

En el dir. local se programan nuevas funcionalidades, se

corrigen errores, etc

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositoriolocal (privado)

repositorioremoto(público)

Cuando se termina una funcionalidad se marcan los cambios que se quieren aplicar y quedan registrados en el área

de cambios

git statusgit addgit rm

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositoriolocal (privado)

repositorioremoto(público)

Para aplicar los cambios se envían al

repositorio local. (Si hay conflictos Git nos echa una mano)

git commit

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositorio local (privado)

repositorioremoto(público)

En este punto Git es especialmente

potente: permite reorganizar commits,

agruparlos, ...

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositorio local (privado)

repositorioremoto(público)

Se pueden enviar cambios al repositorio público y mantener

el local actualizado.git pullgit push

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositorio local (privado)

repositorioremoto(público)

Casi siempre se trabaja en local: • mucho más rápido, • se puede trabajar offline, • todo colaborador tiene una copia local que sirve de backup• se puede replicar el proyecto completo de manera trivial

Git es distribuido

directorio local de trabajo

área de cambios (“staging”)

repositorio local (privado)

repositorioremoto(público)

ramaslocales

ramasremotas

Se pueden llevar ramas para el desarrollo en local, otras en remoto para manejar las

versiones del programa, sincronizarlas entre sí....

Git es distribuido

repositorio local (privado)

repositorioremoto(público)

Git-svn

directorio local de trabajo

área de cambios (“staging”)

repositorio local (privado)

repositorioremoto(público)

Git subversion

Git

• Basado en instantáneas

• Muy cómodo para trabajar con ramas

• Distribuido

• Popular: Gnome, Perl, Linux, Ruby on Rails...

• Alternativas: subversion con git-svn, Mercurial

• Potente (más difícil de aprender que svn)

• Aún no hay un cliente gráfico para todo

GitHub

• Acceso web a repositorios Git

• Gratuito para proyectos libres

• Antepasados similares: sourceforge, savannah, gforge

• “Red social” para programadores, el código es la estrella

GitHub

GitHub

GitHub

GitHub

GitHub

GitHub

• mantenimiento cero: backups, disponibilidad (seguridad rep. privados)

• acceso visual a los proyectos y a los cambios

• interacción con desarrolladores (consultar su trabajo, qué proyectos siguen, mensajería...)

• interacción con proyectos (comentarios en los cambios, colaboración en los wikis, pull request...)

GitHubDatos Febrero 2009:

- 47.000 repositorios públicos, 17.000 (36%) creados el último mes

- 6.200 proyectos forkeados

- 4.600 recibieron contribuciones desde forks

- 18.000 proyectos con al menos un observador el 25% fue forkeado y recibió contribuciones

- no sólo de software vive el hacker: documentación, diseño, música...

Recursos

• git-scm.com

• gitready.com

• gitcasts.com

• book.git-scm.com

• “Pragmatic Version using Git” Ed. Pragmatic Programmers

• “Pro Git” Ed. APress

• github.com

¿Preguntas?

[3] http://homes.ourproject.org/~vjrj/blog/2006/04/12/software-libre-una-mudanza-necesaria/

[5] http://www.flickr.com/photos/wwworks/1384952210/

[6] http://www.flickr.com/photos/manel/303802658/

[7] http://www.flickr.com/photos/jm3/330155936/

[8] http://www.flickr.com/photos/jdelgama/3292355641/

[9] http://www.flickr.com/photos/patrigimeno/2061904821/

[11] http://apple.com

[12] http://www.flickr.com/photos/darthkao/2407993334/

[13] http://www.flickr.com/photos/xanboozled/1325199806

[14] http://www.flickr.com/photos/knoizki/3271782221/

[15] http://www.flickr.com/photos/guille/8066414/

[17] http://www.flickr.com/photos/manel/303802658/ (modificada)

Imágenes