Aviso de cookies

Estoy de acuerdo Este sitio web guarda pequeños fragmentos de información (cookies) en su dispositivo con la finalidad de ofrecer un mejor contenido y para finalidades estadísticas. Usted puede desactivar el uso de cookies modificando la configuración de su navegador. Navegar por nuestro sitio web sin cambiar la configuración del navegador hace que usted nos esté autorizando a guardar esta información en su dispositivo.

Escenarios de trabajo en Git

6 de Marzo de 2013 a las 17:00| git

En este artículo se explican diferentes configuraciones de Git aplicadas a diversos escenarios de trabajo que nos podemos encontrar. Este artículo esta estructurado  en varias partes, una primera parte se explican algunos conceptos de Git, una segunda parte se verán diversas formas de trabajar y por último, se mostraran diversos escenarios de trabajos y que configuraciones podemos aplicar.

 

Conceptos

Git es un sistema de control de versiones distribuido, software que gestiona los diferentes cambios que se produce en  el desarrollo. Git proporciona una serie de características  muy interesantes como: 

  • La información se almacena como instantáneas, de esta forma se reduce el espacio de almacenamiento.
  • Rápido, la mayoría de las operaciones son locales.
  • Es distribuido con lo que aporta mas disponibilidad del código.
  • Gestión de ramas  fácil y  con poca carga de procesamiento.
  • Muy versátil y configurable.

El lugar donde se almacena los datos se denomina repositorio , es un directorio donde Git crea una estructura propia (directorio .git) para  almacenar  componentes  como commit,ramas,historial...etc. Todo es transparente para el usuario.

Hay dos tipos de repositorios:

  • Local: se crea  en el ordenador donde trabaja el usuario, con una zona de trabajo donde se realizan la mayoría de tareas de Git.
  • Remoto: se crea en un ordenador accesible por el repositorio local, se utiliza para compartir código con otros usuarios y trabajar en equipo. Hay una serie de comando específicos para este tipo de repositorios.

En los repositorios se almacenan los diferentes cambios que se producen en el desarrollo del software, Git  almacena estos cambios en un historial. Para almacenar un conjunto de cambios en Git  se utiliza el siguiente comando:

  • Commit (git commit): se utiliza para almacenar un conjunto de cambios en el historial, esta compuesto por un enlace al commit ancestro, un mensaje para describir el contenido y un hash (código alfanúmerico) que se utiliza para identificarlo.

Cuando se crea un repositorio, por defecto se crea una rama ,denominada master, donde se podemos ver de forma lineal todos los commit que realizamos. Técnicamente una rama  en Git es un puntero a un commit, con lo que el trabajo con ramas es muy rápido, podemos crear mas ramas que nos permitirán tener un flujo de trabajo en "paralelo" pudiendo trabajar en varias ramas. También podemos fusionar dos ramas en una, con lo que el contenido de las dos ramas también se fusionara. Mas adelante se explicaran como trabajar con ramas.

Podemos tener ramas locales, explicadas en el parrafo anterior, y ramas remotas.

  • Rama remota: rama del repositorio local que hace referencia a otra rama que se encuentra en un repositorio remoto. Con este tipo de rama tenemos una referencia del estado de una rama en el repositorio remoto. Para poder trabajar con datos de una rama remota se debe fusionar con una rama local.

 

Trabajo con Git

Uno de los conceptos mas útiles para los usuarios es el trabajo con ramas, se pueden utilizar diversas configuraciones de ramas. Por ejemplo, podemos tener una rama estable(master), rama desarrollo y ramas puntuales

Tenemos por defecto una rama principal(master) que se utilizara para almacenar código estable(rama estable) y  no se trabajara directamente en esta rama. Para desarrollar se creara una rama (rama desarrollo) donde se trabajara habitualmente, cuando el código de esta rama se considere estable, se fusionara con la rama estable. Para tareas mas puntuales como arreglar un error o  probar funcionalidades, se creara una rama de corta duración , si el código de esta rama se considera correcto se fusionara con la rama de desarrollo, sino se puede borrar la rama.

Con esta configuración de ramas,siempre tendremos código estable mientras seguimos desarrollando en otras ramas

 

Filosofía del commit

La principal tarea que se realiza en Git son los commit, estos se almacenan en el historial y es conveniente que  estén los mas "limpio" posible, Git no impone ninguna restricción de cuando hacer commit, es el usuario el que decide cuando realizarlo. No conviene realizar commit cada vez que escribas una linea de código porque tendrás el historial lleno de commit que no aportan nada. Una serie de normas que se pueden utilizar son las siguientes:

  • Realizar commit que engloben partes completas, como una funcionalidad nueva,arreglo de un error o añadir una nueva función.
  • No introducir errores con los commit. Si he añadido una nueva función al código, probar antes que funciona correctamente.
  • Todos los commit deben tener un mensaje claro y breve del contenido de los cambios.

 

Compartir en Git

Cuando deseamos compartir nuestro código para trabajar con otros desarrolladores. Git proporciona diferentes métodos para compartir código.

Repositorio remoto: Con este método creamos un servidor con Git donde alojamos el código, se utilizan una serie comandos para poder sincronizar el contenido de un repositorio local con el remoto:

  • clonar: Es la acción de descargarse todo el contenido de un repositorio remoto. Cuando queremos compartir nuestro código, creamos un repositorio remoto donde subiremos nuestro código y si un desarrollador quiere ese código, necesitara copiar ese repositorio remoto a un repositorio local y esa acción es clonar un repositorio. Cuando se clona se crea un repositorio local, se descarga el contenido a ese repositorio y se crea una rama remota(origin) donde se hace seguimiento del repositorio remoto.
  • push: nos permite subir los cambios de nuestro repositorio local.
  • pull: descarga los cambios del repositorio remoto y los integra(fusiona) con nuestro repositorio.
  • fetch: actualiza  los cambios pero no los integra con nuestro repositorio, la fusión se debe realizar de forma manual.

Parches. Es un fichero con un conjunto de cambios que se han realizado en el repositorio. Dicho de otro modo, almacena uno o un conjunto de commit en un fichero en un formato que pueda aplicarse de forma fácil en un repositorio Git .

git diff hash_commit  parche.txt

Genera un parche(parche.txt) con los cambios que se han producido en el commit indicado, si deseamos generar un parche con varios commit.

git diff master~4  parche2.txt

Genera un parche con los cambios de los cuatro últimos commits de la rama master.

git apply  parche.txt

Otra forma de generar parches es con el comando git format-patch.

git format-patch hash_commit

Este comando genera un parche con información adicional como el nombre del autor

Para aplicar un parche generado por format-patch.

git am parche

Bundle:  nos permite guardar un repositorio o una parte  en un fichero, esto es útil cuando queremos transferir un repositorio a otro ordenador que no esta accesible por red.

git bundle create copia desarrollo

Crea un fichero(copia) con el contenido de la rama desarrollo.

Para recuperar el repositorio.

git clone /ruta/donde/esta/fichero -b master nombre_repo

Cuando no tenemos un repositorio, clonamos el repositorio especificando el fichero creado con bundle, añadir la opción "-b master" para crear la referencias adecuadas y especificamos un nombre. Creara un repositorio con el nombre especificado.

Si tenemos un repositorio y deseamos recuperar los commits.

git pull fichero_bundle

Este comando se debe realizar en el repositorio donde  deseamos recuperar el fichero.

Bundle se suele utiliza cuando necesitamos transferir gran cantidad de datos entre dos repositorios, pero si los datos son pequeños se pueden utilizar los parches. Otra diferencia es que los bundle mantienen la estructura original del repositorio.

 

Escenarios de trabajo en Git

En este apartado se verán diferentes configuraciones de Git y en que tipo de escenarios de trabajos se pueden aplicar, viendo las ventajas y desventajas de cada uno.

Escenario con repositorio local

El primer escenario es el típico para un usuario que empieza con Git, tiene un ordenador donde esta desarrolla software y crea un repositorio para ver probar Git.

Creamos un repositorio vació y empezamos a desarrollar un proyecto , o creamos el repositorio en el   directorio donde almacenamos el código de algún proyecto.

Un repositorio local de Git esta compuesto esta compuesto de tres zonas:

zona de trabajo: contiene el código del programa,es donde programamos con nuestro editor de código.

repositorio: esta zona es donde se almacenan los cambios en el historial de Git.

zona de preparación(staging): esta zona intermedia almacena los archivos pero todavía nos se encuentran en el historial de Git. En esta zona podemos preparar los commit con los cambios mas nos interesan.

Con git add -i ,salta al modo interactivo donde podemos escoger que cambios queremos en este commit.

Ventajas:

  • Fácil de crear y utilizar.
  • Rápido, todas las operaciones son locales.

Desventajas

  • Disponibilidad, el código esta en un solo repositorio.
  • Compartir código.

Esta configuración es ideal para un solo programador,si de forma puntual otro programador  va colaborar, hay diversas formas para compartir el código como  ramas remotas, bundle o parches. Pero si esa colaboración es de forma permanente o deseas que el código este accesible a mas desarrolladores es aconsejable el uso de un repositorio remoto.

Escenario centralizado (repositorio remoto)

Este escenario es útil para pequeños grupos de desarrolladores, requiere un recurso extra para el repositorio remoto donde se compartirá el código. Para aquellos equipos de desarrollo que vengan de un sistema de control centralizado( subversión o cvs) estarán familiarizado con esta configuración.

Cada desarrollador trabajara en su repositorio local y subirá los cambios al repositorio remoto para compartirlos con el resto de desarrolladores.

Cuando se utiliza un repositorio remoto, hay que tener en cuenta que antes de que un desarrollador suba cambios al repositorio remoto debe comprobar si tiene actualizado su repositorio local. Si un desarrollador A sube código al repositorio remoto y después un desarrollador B sube código al repositorio, Git mostrara un mensaje indicando que el desarrollador B no tiene los cambios introducidos por el desarrollador A. El desarrollador B deberá  descargarse los cambios  introducidos para tener en su código los cambios del desarrollador A antes de subir sus cambios.

Ventajas

  • Fácil de compartir código, si un desarrollador desea obtener el código solo deberá clonar el repositorio remoto.
  • Disponibilidad, tenemos el código en varios repositorios.

 Desventajas

  • No hay control del código que se sube.
  • Sincronización  de los repositorio.

Escenario con integrador

Cuando el número de desarrolladores aumenta, el tráfico de código entre los repositorios y es conveniente tener un poco de organización. En este escenario aparece la figura del gestor de integración(integrador) que se encarga de recibir los cambios introducido por los desarrolladores, realiza pruebas para comprobar el código de los desarrolladores, si todo esta correcto lo integra con su rama master y lo sube al repositorio remoto, desde donde los desarrolladores obtendrán nuevas versiones del código. El integrador es el único que tiene acceso de escritura al repositorio remoto, el resto de desarrolladores solo tienen acceso de lectura al repositorio remoto.

Ventajas

  • Control de código.
  • Seguridad. Todo el código es comprobado por el gestor integrador y los desarrolladores no tienen acceso a escritura al repositorio remoto.

Desventajas

  • Complejidad para el integrador.
  • Acceso al repositorio remoto, se debe aplicar alguna capa de acceso para que los desarrolladores no tenga acceso de escritura. Hay varias soluciones que facilitan la tarea al integrador.

Escenario dictador-tenientes

 Este escenario es utilizado en proyectos muy grandes, por ejemplo el Kernel de Linux, es una evolución del escenario anterior. Tenemos un repositorio remoto donde se almacena el código, de este repositorio los desarrolladores se descargan el código, cuando quieren entregar código al proyecto se lo envían a un gestor de integración que se denomina teniente, que se encarga de gestionar una parte del proyecto. Los tenientes comprueban el código, realizan las comprobaciones pertinentes y  envían el código a otro gestor que se denomina dictador que integra todas las partes y comprueba que todo funciona. Por último, el dictador enviá el código al repositorio central, es el único usuario con acceso de escritura a ese repositorio, desde donde todos los   desarrolladores se descargan el código actualizado.

Ventajas:

  • Control del código.
  • Organización, se divide el proyecto en varias partes y cada uno gestionada un Teniente.

Desventajas:

  • Complejidad, recomendado para proyectos grandes.
  • Recursos extras para implementar correctamente este escenario.

 

RECURSOS

He reunido un conjunto de enlaces que considero interesante para usuarios de diferentes niveles.

Manual oficial de Git (www.kernel.org/pub/software/scm/git/docs/user-manual.html)

Pequeño tutorial de Git enfocado en Windows

geeks.ms/blogs/etomas/archive/2011/01/18/git-para-dummies-pero-dummies-dummies-eh.aspx

Dentro de la página oficial de Git hay una serie  de videos sobre diferentes aspecto básico de Git (http://git-scm.com/videos)

Git Magic (www-cs-students.stanford.edu/~blynn/gitmagic/intl/es)

Pro Git (http://git-scm.com/book/es): Libro que explica para todos los niveles Git , se puede leer online de forma gratuita. Hay versión en español.

En esta página podemos ver una pequeña guiá con las principales opciones de Git: (http://overapi.com/git)

Git inmersion (http://gitimmersion.com/): tutorial sobre Git.

Curso interactivo de Github sobre Git http://try.github.com

Git guys (http://www.gitguys.com/): Página web con mucha información sobre Git.

Guía de referencia para comandos de Git http://gitref.org/

Como utilizar Rebase en Git (www.randyfay.com/node/91)

Manual sobre Git (http://newartisans.com/2008/04/git-from-the-bottom-up)

Herramientas

Diferentes herramientas para Git.

Migración de svn a Git (subgit.com)

GitHub (github.com), administración web de repositorio de Git y GitHub Enterprise (enterprise.github.com) versión para servidor local.

Bitbucket (bitbucket.org) alternativa a GitHub

Gitorious (gitorious.org) alternativa a GitHub

GitLab (gitlab.org/) administrador web de repositorio Git, un pequeño tutorial sobre este programa lo puedes encontrar en este blog, aquí.

Clientes gráficos para Git

SmartGit (Git y Mercurial) para Win/Mac/Linux (www.syntevo.com/smartgithg)

SourceTree (Git y Mercurial) para Mac y en un futuro para Win (http://sourcetreeapp.com)

Alternativas a Git

Team Fondation server, Herramienta de Microsoft que incluye control de versiones.

www.microsoft.com/visualstudio/esn/products/visual-studio-team-foundation-server-2012

Plastic SCM, DVCS que tiene una versión gratuita (http://www.plasticscm.com)

Para diseñadores

Pixelapse (www.pixelapse.com/)

TimeLine http://www.pixelnovel.com/

Adobe Version Cue www.adobe.com/products/creativesuite.html

LayerVault layervault.com

Mercurial (http://mercurial.selenic.com/wiki)

Bazzar (http://bazaar.canonical.com/en)

 

 

Generar PDF de Escenarios de trabajo en Git