Un flujo de trabajo ágil con git y github.

Plática dada en Devnights

Transcript

1. V 0.2
2. # Hola Noé Domínguez
3. Agenda • Git • Principios del diseño de Git • Lo que nos importa de Github • Waffle.io • A successful Branching Model
5. ---- Linus Torvalds "The information manager from hell"
6. commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Author: Linus Torvalds <torvalds@ppc970.osdl.org> Date: Sat Apr 16 15:20:36 2005 -0700 Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history,even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
7. ---- Git "17291 files changed, 6718755 insertions(+), 0 deletions(-)"
8. Principios del diseño de Git.
9. Principios de Git • Facilitar el desarrollo distribuido • Escalar para manejar miles de desarrolladores • Desempeño rápido y eficiente • Mantener la integridad y la confianza • Promover la transparencia • Inmutabilidad • Transacciones atómicas • Soporta y promueve el desarrollo en capas • Promueve los repositorios completos • Un diseño interno Limpio
10. Lo que nos importa de Github
11. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
13. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
15. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
17. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
19. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
21. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
25. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
27. Lo que nos importa de Github • Issues: para llevar una lista de tareas a hacer. • Milestones: para agrupar tareas a realizar. • Labels en Issues y milestones para indicar el tipo de trabajo a realizar. • Muchos comentarios en Issues para enriquecer la plática técnica • Manejo de branches: semántico con referencia a issues. • Pull Requests: una manera ordenada de agregar código. • Wiki / Documentación en MarkDown. • Tags/Releases para tener versionamiento de la base de código.
29. 1. $ git tag 1.2.4 // Se crea a partir del HEAD 2. $git push github 1.2.4 //Se sube al remoto github 3. voilà Haciendo una tag en git
30. Waffle.io Define un Kanban
32. Lo que nos importa de Waffle.io • Crear un board para un proyecto de Github. • Las columnas estilo Kanban: ◦ Backlog ◦ Ready ◦ In progress ◦ Done ◦ Pueden ser personalizables, agrega un estado al flujo. • Las tarjetas deben de: ◦ Estimarse en puntos o estrellas. ◦ Etiquetarse sobre el trabajo que necesitan. ◦ Deben de cerrarse con Pull Requests.
34. Lo que nos importa de Waffle.io • Crear un board para un proyecto de Github. • Las columnas estilo Kanban: ◦ Backlog ◦ Ready ◦ In progress ◦ Done ◦ Pueden ser personalizables, agrega un estado al flujo. • Las tarjetas deben de: ◦ Estimarse en puntos o estrellas. ◦ Etiquetarse sobre el trabajo que necesitan. ◦ Deben de cerrarse con Pull Requests.
36. Lo que nos importa de Waffle.io • Crear un board para un proyecto de Github. • Las columnas estilo Kanban: ◦ Backlog ◦ Ready ◦ In progress ◦ Done ◦ Pueden ser personalizables, agrega un estado al flujo. • Las tarjetas deben de: ◦ Estimarse en puntos o estrellas. ◦ Etiquetarse sobre el trabajo que necesitan. ◦ Deben de cerrarse con Pull Requests.
38. Lo que nos importa de Waffle.io Escribir, escribir, comentar, poner imágenes e ilustrar.
40. Branching Model
41. A successful Git branching model By Vincent Driessen
42. 1. $ git init 2. (master)$ git checkout -b develop Varios Commits 3. (develop)$ git add path/al/archivo.txt 4. (develop)$git commit -m “Tu mensaje describiendo lo que cambiaron y porqué lo cambiaron” Si se te olvidó algo usa: $ git reset hash-del-commit $ git stash A successful Git branching model By Vincent Driessen
43. 1. $ git init 2. (develop) $ git checkout -b 123-el- feature Varios Commits (otra vez) 3. (feature)$ git add path/al/archivo.txt 4. (feature)$git commit -m “Tu mensaje describiendo lo que cambiaron y porqué lo cambiaron” Al termino: 1. Manda Pull-Request a ‘develop’ A successful Git branching model By Vincent Driessen
44. A successful Git branching model By Vincent Driessen
45. 1. Se guarda historia de cuando hiciste Merge y de dónde. 2. Puedes hacer ‘git reset md5-hash’ para regresar a una versión ‘estable’ o una referencia en el tiempo. 3. Decimos estable, porque asumimos que en algún momento antes de aceptar un Pull-Request hubo code review con alguien más. 4. Si eres de los que manda 5 commits con el mismo mensaje, al menos tiene una referencia más amable. ;P ¿por qué ‘--no-ff’ ?
46. ¿por qué ‘--no-ff’ ?
47. ¿por qué ‘--no-ff’ ? Así es mucho más fácil hacer backtracking
48. Creando tags 1. (master)$ git tag 0.1 2. (master)$git push remote nombre- de-la-tag 3. voilà A successful Git branching model By Vincent Driessen
49. A successful Git branching model By Vincent Driessen
50. Modelo por Vincent Driessen http://nvie.com/posts/a-successful-git-branching-model/ Más información:
51. Join www.codersmexico.com www.scala.org.mx www.scala.org.mx/scala_school
52. @noe_dgz noe@hackersandfounders.com https://poguez.github.io