Flujo de trabajo básico con GIT

Git es 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.

Existe para poder realizar un desarrollo no-lineal.

Incluye herramientas específicas para navegar y visualizar un historial de desarrollo no-lineal.

Los cambios son fusionados frecuentemente.

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.

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.

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.

Esta parte no la expondremos aquí ya que existe mucha documentación en la red sobre eso como por ejemplo:

http://goo.gl/E0gnghttp://goo.gl/GRT3Qhttp://goo.gl/pr0GD

Por lo 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

A lo mucho 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.

Lo que 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…

Muy probablemente alguno de los 2 perderá todo su avance.

En el mejor de los casos Git nos mostrará un HEAD.

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…

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

Estando actualmente en la rama master procedemos a crear la rama development:

(master)> git checkout –b development

Con esta línea de código creamos la rama local development y accedemos automáticamente a ella.

Sé nombrará las ramas momentáneas según el tipo del ticket(este puede ser una tarea, mejora o un error).

Por ejemplo el nombre de una rama momentánea creada para resolver la tarea del ticket #4000 será:

task#4000

En cambio 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).

Estando actualmente en la rama local development procedemos a crear la rama local task#4000

(development)> git checkout –b task#4000

Con esta línea de código creamos la rama local task#4000 y accedemos automáticamente a ella.

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.

Más o menos así quedaría la estructura de nuestro repositorio Git local.

Master

Development

task#4000

bug#4001

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”

Luego ingresaremos a la rama development, el código es el siguiente:

(task#4000)> git checkout development

Para realizar el merge de nuestra tarea completada sobre development escribimos lo siguiente:

(development)> git merge task#4000

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.

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.

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

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…

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

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.

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