Flujo de trabajo básico con GIT
 Gites un software de control de versiones creado por Linus Torvalds, pensado en la eficiencia y la confiabilidad del des...
 Existe       para poder realizar un desarrollo no-lineal. Incluye        herramientas específicas para navegar y visual...
 Su   licencia es GNU GPL. Gestión   distribuida. Cada  desarrollador tiene una copia local del historial del desarroll...
 Los cambios se importan como ramas adicionales y pueden ser fusionados de la misma forma que se hace con la rama local....
Cuando hay muchas y existe mucha  documentación en la red? Fácil,       se hizo para proponer un flujo de trabajo básico,...
 Estaparte no la expondremos aquí ya que existe mucha documentación en la red sobre eso como por ejemplo: http://goo.gl/...
 Porlo general nosotros desarrollamos sobre la rama master, es allí donde realizamos nuestros cambios y los vemos refleja...
 A lomucho realizamos nuestros cambios en un entorno local(nuestra pc), por ejemplo:  http://local.mipagina.pe Y solo hac...
 Loque a su vez nos trae problemas porque yo subí mis cambios pero pepito también subió los suyos y para colmo de males e...
 Me tomó horas resolver la tarea asignada, lo trabajé en local todo el día, trabajo así porque pierdo tiempo haciendo pus...
 Por lo cual proponemos un flujo eficiente para sacarle provecho a Git. Para este flujo de trabajo básico necesitaremos ...
 Estandoactualmente en la rama master procedemos a crear la rama development: (master)> git checkout –b development Cone...
 Sénombrará las ramas momentáneas según el tipo del ticket(este puede ser una tarea, mejora o un error). Porejemplo el n...
 Encambio el nombre de una rama momentánea creada para resolver el error del ticket #4001 será: bug#4001 Esta convención...
 Estandoactualmente en la rama local development procedemos a crear la rama local task#4000 (development)> git checkout –...
 Ahora   ya estamos en la rama local task#4000 (task#4000)> En esta rama tenemos una instancia de la rama master, y pode...
 Máso menos así quedaría la estructura de nuestro repositorio Git local.        Master                   Development     ...
 Sobre esta rama trabajaremos nuestra tarea actual, una vez terminada y testeada en nuestro entorno local(nuestra pc) pro...
 Luego ingresaremos a la rama development, el código es el siguiente: (task#4000)> git checkout development Pararealizar...
 Habiendo  hecho esto hemos fusionado la rama task#4000 con la rama development, lo que quiere decir que hemos traído tod...
 Nos   posicionamos en la rama local master:    (development)> git checkout master   Para traer los últimos cambios de l...
   Hacemos el merge estando en la rama local    master(actualizada), traemos los cambios desde la    rama local developme...
   El uso de gitk no se explicará en esta    presentación pero si estas interesado en aprender    sobre gitk puedes pasar...
   Si llegaste a esta parte de la presentación    entonces solo nos queda hacer el push hacia la    rama master remota.  ...
   Debido al HEAD debemos actualizar la rama    development para que se mantenga exactamente    igual a la rama local mas...
   Una vez realizado esto, culminamos el proceso    eliminando la rama local task#4000, escribiendo    el siguiente códig...
Upcoming SlideShare
Loading in …5
×

Flujo de trabajo básico con git

2,645 views

Published on

Flujo de trabajo básico con git

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,645
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
44
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Flujo de trabajo básico con git

  1. 1. Flujo de trabajo básico con GIT
  2. 2.  Gites un software de control de versiones creado por Linus Torvalds, pensado en la eficiencia y la confiabilidad del desarrollo y mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente.
  3. 3.  Existe para poder realizar un desarrollo no-lineal. Incluye herramientas específicas para navegar y visualizar un historial de desarrollo no-lineal. Loscambios son fusionados frecuentemente.
  4. 4.  Su licencia es GNU GPL. Gestión distribuida. Cada desarrollador tiene una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales.
  5. 5.  Los cambios se importan como ramas adicionales y pueden ser fusionados de la misma forma que se hace con la rama local. Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos.
  6. 6. Cuando hay muchas y existe mucha documentación en la red? Fácil, se hizo para proponer un flujo de trabajo básico, para usar GIT, pero bien! y aprovechar el gran poder que tiene para poder realizar un desarrollo en paralelo.
  7. 7.  Estaparte no la expondremos aquí ya que existe mucha documentación en la red sobre eso como por ejemplo: http://goo.gl/E0gng http://goo.gl/GRT3Q http://goo.gl/pr0GD
  8. 8.  Porlo general nosotros desarrollamos sobre la rama master, es allí donde realizamos nuestros cambios y los vemos reflejados en el dominio de desarrollo, por ejemplo: http://dev.mipagina.pe
  9. 9.  A lomucho realizamos nuestros cambios en un entorno local(nuestra pc), por ejemplo: http://local.mipagina.pe Y solo hacemos push a la rama master para subir los cambios que realizamos en nuestro entorno local.
  10. 10.  Loque a su vez nos trae problemas porque yo subí mis cambios pero pepito también subió los suyos y para colmo de males el también modificó layout.phtml, grrr… Muyprobablemente alguno de los 2 perderá todo su avance. En el mejor de los casos Git nos mostrará un HEAD.
  11. 11.  Me tomó horas resolver la tarea asignada, lo trabajé en local todo el día, trabajo así porque pierdo tiempo haciendo push a la rama master cada vez que quiero ver un cambio en el dominio de desarrollo. Si trabajamos de esta forma… continuamente perderemos tiempo y muchas cosas más…
  12. 12.  Por lo cual proponemos un flujo eficiente para sacarle provecho a Git. Para este flujo de trabajo básico necesitaremos crear además de la rama master, una rama llamada development y ramas momentáneas(todas estas ramas adicionales serán locales).
  13. 13.  Estandoactualmente en la rama master procedemos a crear la rama development: (master)> git checkout –b development Conesta línea de código creamos la rama local development y accedemos automáticamente a ella.
  14. 14.  Sénombrará las ramas momentáneas según el tipo del ticket(este puede ser una tarea, mejora o un error). Porejemplo el nombre de una rama momentánea creada para resolver la tarea del ticket #4000 será: task#4000
  15. 15.  Encambio el nombre de una rama momentánea creada para resolver el error del ticket #4001 será: bug#4001 Esta convención nos ayudará a distinguir cada rama momentánea por su origen(tarea, mejora o error).
  16. 16.  Estandoactualmente en la rama local development procedemos a crear la rama local task#4000 (development)> git checkout –b task#4000 Conesta línea de código creamos la rama local task#4000 y accedemos automáticamente a ella.
  17. 17.  Ahora ya estamos en la rama local task#4000 (task#4000)> En esta rama tenemos una instancia de la rama master, y podemos modificar el código que deseemos y olvidarnos de esperar que pepito acabe de editar el mismo archivo con el que nosotros deseamos trabajar.
  18. 18.  Máso menos así quedaría la estructura de nuestro repositorio Git local. Master Development task#4000 bug#4001
  19. 19.  Sobre esta rama trabajaremos nuestra tarea actual, una vez terminada y testeada en nuestro entorno local(nuestra pc) procederemos a fusionar(hacer merge con la rama development), para lo cual commitearemos nuestros cambios una sola vez a la rama task#4000, el código es el siguiente: (task#4000)> git add .; git commit -am “done”
  20. 20.  Luego ingresaremos a la rama development, el código es el siguiente: (task#4000)> git checkout development Pararealizar el merge de nuestra tarea completada sobre development escribimos lo siguiente: (development)> git merge task#4000
  21. 21.  Habiendo hecho esto hemos fusionado la rama task#4000 con la rama development, lo que quiere decir que hemos traído todos los archivos modificados desde la rama task#4000 y los hemos reemplazado por sus similares en la rama development, con esto ya tenemos todos nuestros cambios en la rama development. Luego ingresaremos a la rama local master y traeremos los últimos cambios que se hayan realizado sobre la rama remota master.
  22. 22.  Nos posicionamos en la rama local master: (development)> git checkout master Para traer los últimos cambios de la rama remota master hacia la rama local master escribimos el siguiente código: (master)> git pull origin master Con esto habremos actualizado nuestra rama local master y ahora procederemos a realizar el merge desde la rama development hacia la rama local master.
  23. 23.  Hacemos el merge estando en la rama local master(actualizada), traemos los cambios desde la rama local development con el siguiente código. (master)> git merge development Lo normal sería que este proceso no nos de un HEAD, pero si se diera ese caso entonces tendríamos que resolver los conflictos manualmente. Nota: si deseamos ver información gráfica sobre las actividades del repositorio podemos usar gitk: (master)> gitk
  24. 24.  El uso de gitk no se explicará en esta presentación pero si estas interesado en aprender sobre gitk puedes pasar por este enlace http://goo.gl/jBSEf y luego continuar con la presentación. Si resolviste el HEAD(problema que se dio porque alguno o muchos de los archivos que modificaste también fue modificado por algún desarrollador más) o mejor aún si no tuviste ningún HEAD, entonces podemos continuar…
  25. 25.  Si llegaste a esta parte de la presentación entonces solo nos queda hacer el push hacia la rama master remota. (master)> git push origin master Con esto tus cambios finalmente suben hacia la rama remota master y puedes visualizarlos en tu dominio de desarrollo. Si tuviste un HEAD entonces tienes un motivo más para seguir en esta presentación… y si no también porque aún nos falta eliminar la rama task#4000
  26. 26.  Debido al HEAD debemos actualizar la rama development para que se mantenga exactamente igual a la rama local master. (master)> git checkout development (development)> git merge master Con la primera línea ingresamos a la rama development y con la segunda hacemos el merge trayendo todos los cambios desde la rama local master hacia la rama local development, con esto trajimos las ultimas correcciones manuales que realizaste luego del HEAD.
  27. 27.  Una vez realizado esto, culminamos el proceso eliminando la rama local task#4000, escribiendo el siguiente código: (development)> git branch –d task#4000 Con esto habremos culminado este proceso básico correctamente. Gracias por su atención. @jansanchez

×