Un flujo de trabajo ágil con git y github.

Un flujo de trabajo ágil con git y github.

Plática dada en Devnights

Bd7f0e0118a2ea635b5a06d84cbab283?s=128

Noé Domínguez Porras

May 19, 2016
Tweet

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
  4. None
  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.
  12. None
  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.
  14. None
  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.
  16. None
  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.
  18. None
  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.
  20. None
  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.
  22. None
  23. None
  24. None
  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.
  26. None
  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.
  28. None
  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

  31. None
  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.
  33. None
  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.
  35. None
  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.
  37. None
  38. Lo que nos importa de Waffle.io Escribir, escribir, comentar, poner

    imágenes e ilustrar.
  39. None
  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