control de versiones con git y github
DESCRIPTION
Charla impartida durante las II Jornadas de Conocimiento Libre de la Universidad Europea de Madrid (primavera 2009)TRANSCRIPT
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