Flujo de trabajo básico con git

1. Flujo de trabajo básico con GIT

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.  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.  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.  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. 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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  Máso menos así quedaría la estructura de
nuestro repositorio Git local.
Master
Development
task#4000
bug#4001

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.  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.  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.  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.  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.  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.  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.  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.  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