Charla impartida durante las II Jornadas de Conocimiento Libre de la Universidad Europea de Madrid (primavera 2009)

1. Control de versiones
con Git y GitHub
Raúl Murciano
Desarrollador Web Freelance
II Jornadas Conocimiento Libre
Universidad Europea de Madrid - GLUEM

2. Índice
•Control de versiones
• Git
• GitHub

3. Copyleft Vicente J. Ruiz Jurado
Creative Commons, atribución, comparte por igual.

4. CONOCIMIENTO LIBRE
SOFTWARE LIBRE
HERRAMIENTAS LIBRES

5. EQUIPO

6. SOLO

7. Ventajas del Control de Versiones:
Almacenamiento y Backup

8. Ventajas del Control de Versiones:
Control de Acceso mediante permisos

9. Ventajas del Control
de Versiones:
Deshacer
ILIMITADO

10. Ventajas del Control
de Versiones:
Deshacer
ILIMITADO

12. Ventajas del Control de Versiones:
Mezclar aportaciones
de distintos colaboradores

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

14. Ventajas del Control de Versiones:
Histórico de Cambios
• Quién
• Qué
• Cuándo
• Para Qué

15. Ventajas del Control de Versiones:
Versiones en paralelo

16. Copiar y Pegar archivos
Practica1
Practica1_enero_14_fulano
Practica1_enero_14_final
Practica1_enero_14_final_de_verdad
NO
es Control de Versiones

17. Batallita

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

20. Ejemplo: lista de la compra
versión 0
(vacía)
(vacía) (vacía)

21. Ejemplo: lista de la compra
versión 0
(vacía)
hamburguesa (vacía)

22. Ejemplo: lista de la compra
versión 0
hamburguesa
commit
hamburguesa (vacía)

23. Ejemplo: lista de la compra
versión 1
hamburguesa
hamburguesa hamburguesa

24. Ejemplo: lista de la compra
versión 1
hamburguesa
hamburguesa
hamburguesa verdura

25. Ejemplo: lista de la compra
versión 2
verdura
commit
hamburguesa
hamburguesa verdura

26. Ejemplo: lista de la compra
versión 2
verdura
hamburguesa verdura
cerveza

27. Ejemplo: lista de la compra
versión 2
intenta enviar un
commit pero no lo verdura
consigue: hay
conflictos
hamburguesa verdura
cerveza

28. Ejemplo: lista de la compra
versión 2
tiene que actualizar
su versión local,
resolver los verdura
conflictos y volver a
enviar un nuevo
commit
hamburguesa verdura
cerveza

29. Ejemplo: lista de la compra
versión 2
verdura
hamburguesa
verdura verdura
cerveza

30. Ejemplo: lista de la compra
versión 3
verdura
commit cerveza
hamburguesa
verdura verdura
cerveza

31. Ejemplo: lista de la compra
El repositorio almacena todas las versiones y los cambios
(vacía)
10:30 “Para cenar, hamburguesas...”
hamburguesa
“¿Con esa panza? ¡Más
10:35 verdura y menos grasa!”
verdura
“Al menos que sea con
10:40 una cervecita...”
verdura
cerveza

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

33. Otro ejemplo:
editor de textos
1 2 3 4

34. Otro ejemplo:
editor de textos
1 2 3 4
Tag v0.1
Se pueden etiquetar versiones
concretas, para localizarlas fácilmente
en la historia del repositorio.

35. Otro ejemplo:
editor de textos
1 2 3 4
Tag v0.1
¿Qué ocurre si mientras estamos desarrollando la funcionalidad
4 se descubre un bug en alguna de las anteriores?

36. Otro ejemplo:
editor de textos
rama
4
desarrollo
rama
1 2 3 3a
producción
Tag v0.1 Tag v0.1.1
Para evitar esto se suele trabajar en “ramas”

37. Otro ejemplo:
editor de textos
4 5
1 2 3 3a 6
Tag v0.1 Tag v0.1.1 Tag v0.2
Cuando la rama de desarrollo sea estable la
fusionaremos con la de producción

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

39. Integration Manager
blessed
repository
developer developer
integration manager
private private
Scott Chacon, Scotland on Rails Mar’09

40. Integration Manager
blessed
repository developer developer
public public
developer developer
integration manager
private private
Scott Chacon, Scotland on Rails Mar’09

41. Dictador/Tenientes
dictator blessed repository
lieutenant
lieutenant
developer developer developer developer
Scott Chacon, Scotland on Rails Mar’09

42. Dictador/Tenientes
dictator blessed repository
lieutenant
lieutenant
developer developer developer developer
Scott Chacon, Scotland on Rails Mar’09

43. Tipos de Sistemas de
Control de Versiones
• Incrementales vs basados en snapshots
(“instantáneas”)
• Centralizados vs Distribuidos

44. (& () (* (+ (,
!"#$% !& !)
!"#$%
&$'(%)"
!"#$' !& !)
!"#$( !& !) !*
(& () (* (+ (,
&*%+&,'$ % %& %& %) %)
&$'(%)"
' ' ' '& ')
( (& () () (*
Scott Chacon, Scotland on Rails Mar’09

45. (& () (* (+ (,
!"#$% !& !)
!"#$%
&$'(%)"
!"#$' !& !)
!"#$( !& !) !*
(& () (* (+ (,
&*%+&,'$ % %& %& %) %)
&$'(%)"
' ' ' '& ')
( (& () () (*
Scott Chacon, Scotland on Rails Mar’09

46. Git es distribuido
• Aunque se trabaje con un repositorio
remoto, siempre se tiene uno en local
repositorio
directorio local área de cambios repositorio
remoto
de trabajo (“staging”) local (privado)
(público)

47. Git es distribuido
repositorio
directorio local área de cambios repositorio
remoto
de trabajo (“staging”) local (privado)
(público)
En el dir. local se
programan nuevas
funcionalidades, se
corrigen errores, etc

48. Git es distribuido
repositorio
directorio local área de cambios repositorio
remoto
de trabajo (“staging”) local (privado)
(público)
Cuando se termina una funcionalidad
se marcan los cambios que se quieren
aplicar y quedan registrados en el área
de cambios
git status
git add
git rm

49. Git es distribuido
repositorio
directorio local área de cambios repositorio
remoto
de trabajo (“staging”) local (privado)
(público)
Para aplicar los
cambios se envían al
repositorio local.
(Si hay conflictos Git
nos echa una mano)
git commit

50. Git es distribuido
repositorio
directorio local área de cambios repositorio local
remoto
de trabajo (“staging”) (privado)
(público)
En este punto Git es
especialmente
potente: permite
reorganizar commits,
agruparlos, ...

51. Git es distribuido
repositorio
directorio local área de cambios repositorio local
remoto
de trabajo (“staging”) (privado)
(público)
Se pueden enviar cambios al
git pull repositorio público y mantener
git push el local actualizado.

52. Git es distribuido
repositorio
directorio local área de cambios repositorio local
remoto
de trabajo (“staging”) (privado)
(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

53. Git es distribuido
repositorio
directorio local área de cambios repositorio local
remoto
de trabajo (“staging”) (privado)
(público)
ramas ramas
locales remotas
Se pueden llevar ramas para el desarrollo en
local, otras en remoto para manejar las
versiones del programa, sincronizarlas entre sí....

54. Git es distribuido
repositorio local
(privado)
repositorio
remoto
(público)

55. Git-svn
repositorio
directorio local área de cambios repositorio local
remoto
de trabajo (“staging”) (privado)
(público)
Git subversion

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

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

58. GitHub

59. GitHub

60. GitHub

61. GitHub

62. GitHub

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

64. GitHub
Datos 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...

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

66. ¿Preguntas?

67. Imágenes
[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)