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

No comments: