Escenarios de trabajo en Git

Transcripción

1 Escenarios de trabajo en Git by kotov - Miércoles, marzo 06, Kindle 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 con Git y por último, se mostraran diversos escenarios de trabajos y que configuraciones de Git 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 / 0

2 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 parrado 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 2 / 0

3 ramas Filosofía de 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. Genera un parche(parche.txt) con los cambios que se han producido en el commit indicado, si deseamos 3 / 0

4 generar un parche con varios commit. Genera un parche con los cambios de los cuatro últimos commits de la rama master. Para aplicar un parche. Otra forma de generar parches es con el comando git format-patch. Este comando genera un parche con información adicional como el nombre del autor Para aplicar un parche generado por format-patch. 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. Crea un fichero(copia) con el contenido de la rama desarrollo. Para recuperar el repositorio. 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. 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. 4 / 0

5 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: Desventajas Fácil de crear y utilizar. Rápido, todas las operaciones son locales. 5 / 0

6 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 remoto. deberá clonar el repositorio Disponibilidad, tenemos el código en varios repositorios. Desventajas 6 / 0

7 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 7 / 0

8 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. Fuente: ProGit (git-scm.com/book) 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 ( Pequeño tutorial de Git enfocado en Windows geeks.ms/blogs/etomas/archive/20/0/8/git-para-dummies-pero-dummies-dummies-eh.aspx 8 / 0

9 Dentro de la página oficial de Git hay una serie de videos sobre diferentes aspecto básico de Git ( Git Magic (www-cs-students.stanford.edu/~blynn/gitmagic/intl/es) Pro Git ( 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: ( Git inmersion ( tutorial sobre Git. Curso interactivo de Github sobre Git Git guys ( Página web con mucha información sobre Git. Guía de referencia para comandos de Git Como utilizar Rebase en Git ( Manual sobre Git ( 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í. 9 / 0

10 Powered by TCPDF ( Escenarios de trabajo en Git Clientes gráficos para Git SmartGit (Git y Mercurial) para Win/Mac/Linux ( SourceTree (Git y Mercurial) para Mac y en un futuro para Win ( Alternativas a Git Team Fondation server, Herramienta de Microsoft que incluye control de versiones. Plastic SCM, DVCS que tiene una versión gratuita ( Mercurial ( Bazzar ( Para diseñadores Pixelapse ( TimeLine Adobe Version Cue LayerVault layervault.com PDF generated by Kalin's PDF Creation Station 0 / 0