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. 1.
  2. 3.

    Agenda • Git • Principios del diseño de Git •

    Lo que nos importa de Github • Waffle.io • A successful Branching Model
  3. 4.
  4. 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!
  5. 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
  6. 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.
  7. 12.
  8. 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.
  9. 14.
  10. 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.
  11. 16.
  12. 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.
  13. 18.
  14. 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.
  15. 20.
  16. 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.
  17. 22.
  18. 23.
  19. 24.
  20. 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.
  21. 26.
  22. 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.
  23. 28.
  24. 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
  25. 31.
  26. 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.
  27. 33.
  28. 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.
  29. 35.
  30. 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.
  31. 37.
  32. 39.
  33. 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
  34. 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
  35. 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’ ?
  36. 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