Rubén Sierra Asturias 13 de Marzo de 2013

1. with gifs

2. Sistemas de
control de versiones
Gestionan los cambios realizados
sobre diversos elementos a lo
largo del tiempo.

3. Git
• Diseñado por Linus Torvalds para
Linux.
• Git: distribuido, rápido y
eficiente.

5. Conceptos básicos
• Branches: ramas del repositorio.
• Commits: guardado de cambios.
• Merge: mezcla de los commits de
distintas ramas.
• Push/Pull: sincronización con el
repositorio remoto.

6. No tenemos nada
en contra de SVN
pero...

7. ...cuando un nuevo
empleado dice que
prefiere usar SVN
antes que Git...

9. Workflow ideal
• Desarrollo en ramas de largo recorrido
(master/develop).
• Rama master para versiones estables.
• Ramas puntuales:
o features: nuevas funcionalidades.
o releases: para congelar una versión.
o fixes: corrección de bugs.

10. Desarrollo
• Nunca commits directos
sobre master.
• Develop estable
=> merge a master.

11. Features
• Nuevas features siempre
nacen de develop.
• Features finalizadas siempre
vuelven a develop y se borran.

12. Releases
• Nuevas releases siempre nacen de develop.
• Releases finalizadassiempre vuelven a
master y develop.
• Se congela la release
en un tag.

13. Fixes
• Fixes siempre nacen
de master.
• Fixes vuelven amaster y develop.
• Se genera unanueva versión.

14. Siguiendo esto...

16. ...pero no siempre
es aplicable.

17. Una mañana
cualquiera en
Simplelógica...

19. Tenemos marrones

20. Muchas veces nos
gustaría...

22. Pero es nuestro
trabajo...

23. Con clientes
• Periodo de desarrollo menos
prolongado.
• Cambios imprevistos.
• Entorno de pre-producción para el
cliente.

24. Nuestro workflow
• Desarrollo en ramas de largo recorrido
(master/staging).
• Rama master para entorno en producción.
• Rama staging para pre-producción.
• Ramas puntuales:
o features: nuevas funcionalidades.
o fixes: corrección de bugs.

25. Diferencias
• Nuevas features nacen de master.
• Features finalizadas se pasan a staging
para que las pruebe el cliente.
• Fixes vuelven a master y staging.
• Nunca commits directos en staging.
• Staging totalmente desechable.

27. Buenas prácticas

28. git stash
• Almacena los cambios actuales en
una pila independiente.
• Te deja en el último commit.
• Puede recuperarse más tarde.

29. Cuando lo
descubres...

31. Cuando lo
controlas...

33. Y para lo que lo
acabas usando...

35. Es útil
• Cuando tenemos algo a medias y
hay que hacer un cambio urgente.
• Cuando no estamos trabajando en
la rama adecuada.
• Para desechar rápido las últimas
modificaciones.

36. Organiza tu trabajo
• Crea siempre ramas puntuales para hacer
commits ¡Son gratis!
• Haz commits pequeños que abarquen lógica
común ¡También son gratis!
• Configura los merges con --no-ff,
aportan estructura, +info y salud.

37. Evitarás
cosas como...

39. git blame
• Indica el último autor de un
cambio en una línea de código.
• Permite culpar a otro cuando el
código apesta.

40. Cuando alguien
va a hacer un
git blame...

42. ...si el autor es un
compañero...

44. ...pero la mayoría de
las veces...

46. git rebase
También permite mezclar ramas,
pero reescribe la historia.

48. Mola pero...

50. el problema de rebase
No hagas rebase a commits que ya
estén distribuidos.
Podríamos crear una paradoja
espacio-temporal y que el
universo se plegara sobre sí
mismo.

51. Haz caso a Doc,
sabe mucho
del tiempo

53. pull y push
• Configura el rebase por defectode
pull (por una historia más
bonita).
• Haz pull siempre antes de push.

54. Evitarás
cosas como...

56. Y siempre puedes
cagarla...

58. Cuando todo se rompe
• git reflog: rebusca
• git reset: reinicia
• git revert: deshaz

60. Seguramente
tenga solución

62. ¡GRACIAS!

63. ¿Preguntas?

64. http://goo.gl/49vdf
(Presentación)
https://twitter.com/maguilag
https://github.com/rsierra