28 November 2016

GIT: Comparación de metodologías de trabajo

Traducido del documento original en inglés "Comparing Workflows." Traducción por Alejandro Egas e ideaPort LLC con autorización de Atlassian.




La variedad de posibles metodologías de trabajo hace difícil saber por dónde empezar cuando se implementa Git en el lugar de trabajo. Esta página ofrece un punto de partida revisando las metodologías de trabajo más comunes de Git para equipos al interior de empresas.

Mientras lees, ten en cuenta que estas metodologías de trabajo están diseñadas como directrices generales y no como reglas estrictas. Queremos mostrar lo que se puede hacer para que tú tomes, mezcles y acoples aspectos de distintas metodologías de trabajo adecuándolas a tus necesidades individuales.

Metodología de Trabajo Centralizada





La transición a un sistema de control de versiones distribuido puede parecer una tarea de enormes proporciones, pero no es a fuerzas necesario cambiar la metodología de trabajo ya existente para sacar provecho a Git. Tu equipo puede desarrollar sus proyectos tal como lo hace con Subversion.

Sin embargo, el uso de Git en el trabajo de desarrollo evidencia varias ventajas con respecto a SVN. La primera es que cada desarrollador recibe su propia copia local del proyecto completo. Este entorno aislado le permite a cada desarrollador trabajar independiente de todos los demás cambios que se hagan al proyecto. Pueden añadir commits a su repositorio local y olvidarse por completo lo que se esté desarrollando en el resto del proyecto hasta que les resulte conveniente.

La segunda ventaja es que Git da acceso a un robusto modelo de ramas (branchs) y fusión (merging). A diferencia de SVN, las ramas de Git están diseñadas para ser un proceso seguro para la integración de código y para compartir los cambios entre repositorios.

Cómo funciona


Al igual que en Subversion, la metodología de trabajo centralizada utiliza un repositorio central como punto de entrada único para todos los cambios del proyecto. En lugar de trunk, la rama de desarrollo por defecto se llama master, y todos los cambios son agregados como commits a esta rama. Esta metodología de trabajo no requiere de ninguna rama aparte de master.

Para empezar, los desarrolladores deben clonar el repositorio central. Luego, en sus propias copias locales del proyecto, se editan los archivos y se agregan commits tal como se hace en SVN. Sin embargo, estos nuevos cambios son guardados de manera local. Están completamente aislados del repositorio central. Esto le permite a los desarrolladores aplazar la sincronización con upstream hasta que lleguen a un punto conveniente.

Leer más...

Git: Comparing Workflows

Source: Atlassian Git Tutorials. Read it in Spanish: En español.




The array of possible workflows can make it hard to know where to begin when implementing Git in the workplace. This page provides a starting point by surveying the most common Git workflows for enterprise teams.

As you read through, remember that these workflows are designed to be guidelines rather than concrete rules. We want to show you what’s possible, so you can mix and match aspects from different workflows to suit your individual needs.

Centralized Workflow




Transitioning to a distributed version control system may seem like a daunting task, but you don’t have to change your existing workflow to take advantage of Git. Your team can develop projects in the exact same way as they do with Subversion.

However, using Git to power your development workflow presents a few advantages over SVN. First, it gives every developer their own local copy of the entire project. This isolated environment lets each developer work independently of all other changes to a project—they can add commits to their local repository and completely forget about upstream developments until it's convenient for them.

Second, it gives you access to Git’s robust branching and merging model. Unlike SVN, Git branches are designed to be a fail-safe mechanism for integrating code and sharing changes between repositories.

How It Works


Like Subversion, the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. Instead of trunk, the default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master.

Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point.

Read more...