1. Control de versiones
con Git y GitHub
Raúl Murciano
Desarrollador Web Freelance
II Jornadas Conocimiento Libre
Universidad Europea de Madrid - GLUEM
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
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. ...
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
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í....
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
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...
