Control de versiones con Git y Github

11,955 views

Published on

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

2 Comments
7 Likes
Statistics
Notes
No Downloads
Views
Total views
11,955
On SlideShare
0
From Embeds
0
Number of Embeds
2,347
Actions
Shares
0
Downloads
289
Comments
2
Likes
7
Embeds 0
No embeds

No notes for slide

Control de versiones con Git y Github

  1. 1. Control de versiones con Git y GitHub Raúl Murciano Desarrollador Web Freelance II Jornadas Conocimiento Libre Universidad Europea de Madrid - GLUEM
  2. 2. Índice •Control de versiones • Git • GitHub
  3. 3. Copyleft Vicente J. Ruiz Jurado Creative Commons, atribución, comparte por igual.
  4. 4. CONOCIMIENTO LIBRE SOFTWARE LIBRE HERRAMIENTAS LIBRES
  5. 5. EQUIPO
  6. 6. SOLO
  7. 7. Ventajas del Control de Versiones: Almacenamiento y Backup
  8. 8. Ventajas del Control de Versiones: Control de Acceso mediante permisos
  9. 9. Ventajas del Control de Versiones: Deshacer ILIMITADO
  10. 10. Ventajas del Control de Versiones: Deshacer ILIMITADO
  11. 11. Ventajas del Control de Versiones: Mezclar aportaciones de distintos colaboradores
  12. 12. Ventajas del Control de Versiones: Todos se mantienen sincronizados fácilmente
  13. 13. Ventajas del Control de Versiones: Histórico de Cambios • Quién • Qué • Cuándo • Para Qué
  14. 14. Ventajas del Control de Versiones: Versiones en paralelo
  15. 15. Copiar y Pegar archivos Practica1 Practica1_enero_14_fulano Practica1_enero_14_final Practica1_enero_14_final_de_verdad NO es Control de Versiones
  16. 16. Batallita
  17. 17. 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
  18. 18. Ejemplo: lista de la compra versión 0 (vacía) (vacía) (vacía)
  19. 19. Ejemplo: lista de la compra versión 0 (vacía) hamburguesa (vacía)
  20. 20. Ejemplo: lista de la compra versión 0 hamburguesa commit hamburguesa (vacía)
  21. 21. Ejemplo: lista de la compra versión 1 hamburguesa hamburguesa hamburguesa
  22. 22. Ejemplo: lista de la compra versión 1 hamburguesa hamburguesa hamburguesa verdura
  23. 23. Ejemplo: lista de la compra versión 2 verdura commit hamburguesa hamburguesa verdura
  24. 24. Ejemplo: lista de la compra versión 2 verdura hamburguesa verdura cerveza
  25. 25. Ejemplo: lista de la compra versión 2 intenta enviar un commit pero no lo verdura consigue: hay conflictos hamburguesa verdura cerveza
  26. 26. 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
  27. 27. Ejemplo: lista de la compra versión 2 verdura hamburguesa verdura verdura cerveza
  28. 28. Ejemplo: lista de la compra versión 3 verdura commit cerveza hamburguesa verdura verdura cerveza
  29. 29. 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
  30. 30. 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. ...
  31. 31. Otro ejemplo: editor de textos 1 2 3 4
  32. 32. 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.
  33. 33. 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?
  34. 34. 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”
  35. 35. 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
  36. 36. 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
  37. 37. Integration Manager blessed repository developer developer integration manager private private Scott Chacon, Scotland on Rails Mar’09
  38. 38. Integration Manager blessed repository developer developer public public developer developer integration manager private private Scott Chacon, Scotland on Rails Mar’09
  39. 39. Dictador/Tenientes dictator blessed repository lieutenant lieutenant developer developer developer developer Scott Chacon, Scotland on Rails Mar’09
  40. 40. Dictador/Tenientes dictator blessed repository lieutenant lieutenant developer developer developer developer Scott Chacon, Scotland on Rails Mar’09
  41. 41. Tipos de Sistemas de Control de Versiones • Incrementales vs basados en snapshots (“instantáneas”) • Centralizados vs Distribuidos
  42. 42. (& () (* (+ (, !"#$% !& !) !"#$% &$'(%)" !"#$' !& !) !"#$( !& !) !* (& () (* (+ (, &*%+&,'$ % %& %& %) %) &$'(%)" ' ' ' '& ') ( (& () () (* Scott Chacon, Scotland on Rails Mar’09
  43. 43. (& () (* (+ (, !"#$% !& !) !"#$% &$'(%)" !"#$' !& !) !"#$( !& !) !* (& () (* (+ (, &*%+&,'$ % %& %& %) %) &$'(%)" ' ' ' '& ') ( (& () () (* Scott Chacon, Scotland on Rails Mar’09
  44. 44. 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)
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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, ...
  49. 49. 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.
  50. 50. 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
  51. 51. 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í....
  52. 52. Git es distribuido repositorio local (privado) repositorio remoto (público)
  53. 53. Git-svn repositorio directorio local área de cambios repositorio local remoto de trabajo (“staging”) (privado) (público) Git subversion
  54. 54. 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
  55. 55. 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
  56. 56. GitHub
  57. 57. GitHub
  58. 58. GitHub
  59. 59. GitHub
  60. 60. GitHub
  61. 61. 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...)
  62. 62. 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...
  63. 63. 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
  64. 64. ¿Preguntas?
  65. 65. 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)

×