Git vs Subversion

Hace ya un tiempo que el control de versiones del código fuente es más que obligatorio, se ha convertido en una necesidad inimaginable sobre todo porque te permite realizar guardar las versiones del código fuente administrarlas, etiquetarlas y tener con ello un mejor control del código fuente de nuestra aplicación, Sin embargo en este artículo no nos centraremos en las ventajas de un sistema de control de versiones sino más bien analizaremos las diferencias que existen entre los Sistemas de control de versiones Distribuidos y los Centralizados.

Más que analizar Git vs Subversion nos centraremos en analizar de una forma más subjetiva las diferencias entre los sistemas de control de versiones distribuidos y centralizados ya que de esta manera analizamos Git vs Subversion así como distintos clientes de Git y Subversion.

Sistemas de control de versiones Centralizados (Subversion)

Como su no nombre lo indica, este tipo de sistemas de control de versiones tiene como principal característica la centralización de los repositorios el cual llamamos Master Repository o Repositorio Maestro, en el cual guardamos todos nuestros cambios a la vez que descargamos los cambios de los demás, en este tipo de repositorio todos los participantes del proyecto afectan directamente al repositorio maestro y los cambios realizados por algún de ellos afecta directamente al resto de colaboradores que utilizan este mismo repositorio.

La forma de trabajar es la siguiente:

En un sistema de control de versiones centralizados los usuarios tiene básicamente dos (Relevantes para esta explicación) opciones:

• Commit: Esta operación nos permite subir los cambios realizados de forma local en nuestro equipo al repositorio maestro de tal forma que el resto de participantes puedan ver los cambios y descargarlos.
• Updadate: Esta opción nos permite descargar los cambios realizados por otros miembros del equipo, con la finalidad integrar sus cambios a la versión que tenemos en nuestro equipo.

Derivados de estas dos opciones surgen algunos problemas como pueden ser que dos personas hayan modificado el mismo archivo al mismo tiempo provocando un conflicto de versiones que hay que corregir de forma manual o en el mejor de los casos la misma herramienta o cliente nos ayuda a corregir este problema de forma automática. Existen sistemas de control de versiones como DTR de SAP o SourceSafe de Microsoft que nos permiten bloquear un archivo para impedir que otros usuarios modifiquen el mismo archivo al mismo tiempo.

Para este tipo de repositorio no entrare mucho en detalle debido a que es el más común y es al que estamos más acostumbrados.

Para más información de Subversion podemos ver la siguiente página https://es.wikipedia.org/wiki/Subversion_(software)

Sistemas de control de versiones Distribuidos (Git)

Este tipo de sistemas de control de versiones(SCV) trabaja de forma muy distinta a como trabajan los SCV Centralizados ya que estos tiene la peculiaridad de que los repositorios son distribuidos, a diferencia de los SCV centralizados donde cada persona baja un copia del código fuente del repositorio en los SCV distribuidos en realidad lo que hacemos es clonar el repositorio, y cuando decimos clonar queremos decir que en realidad tú tienes de forma local una repositorio en lugar de solo una copia.

Los SCV distribuidos nacen de la necesidad de mantener equipos de trabajo distribuidos por varias partes del mundo, algo muy común en los proyectos OpenSource como es el caso de Linux, donde tienes equipos de trabajo que diversos en lugar muy distantes, esto ocasionaba un gran problema y es que cualquier persona podía afectar el repositorio maestro causando graves problemas sobre la versión final. Para comprender mejor esto veamos la siguiente imagen:

Como podemos ver en la imagen, esta forma de trabajar se ve más complicada sin embargo no lo es, de hecho este esquema ofrece ventajas que los SCV Centralizados no ofrecen, en este tipo de SCV se pueden realizar las siguientes operaciones:

• Commit: El commit lo que hace es guardar la versión en nuestro repositorio local, el cual clonamos para poder trabajar, este commit afecta únicamente a nuestro repositorio local de tal manera que nadie más podrá ver estos cambios.
• Update: Nos permite obtener una versión determinada del repositorio local.
• Pull: Nos permite descargar cambios de otros repositorios, mediante esta opción podríamos descargar los cambios de más de un repositorio a la vez y juntar estos cambios para crear una nueva versión.
• Push: Nos permite enviar nuestros cambios a otros repositorios.
• Clone: Clonar un repositorio de forma local.

Una vez explicadas las operaciones disponibles las analizaremos con un ejemplo:

Imaginemos que estamos desarrollando un proyecto de gran envergadura, el cual tiene muchos módulos y se requiere de la participación de un gran equipo de trabajar, el proyecto esta tan grande que tu como arquitecto necesitas dividir los módulos y asignar a un responsable, este responsable tendrá a su vez un equipo de trabajo a cargo de el a esto le llamaremos células de trabajo, ahora bien algunas de estas células probablemente requerirán la subcontratación de otras empresas especializadas en temas muy concretos como por ejemplo la seguridad, base de datos, etc. esta relación se empieza a complicar debido a que a ti como arquitecto te interesa que en el repositorio central exista únicamente versiones terminadas que puedan servir como releaces para el cliente.

La forma de trabajar será la siguiente:

Tus líderes de célula clonarán el repositorio maestro (Clone) en algún servidor local para que su equipo de trabajo pueda interactuar con él, el equipo de trabajo de nuestro líder clonara (Clone)a su vez el repositorio del líder para poder iniciar con su desarrollo, este desarrolladores realizaran sus cambios, probaran su código y terminarán su trabajo finalizando con un commit en su repositorio local, estos tendrán que ponerse de acuerdo con el líder para subir los cambios al repositorio del líder(Push) el cual tendrá que hacer el merge de todos los cambios de sus subordinados, cuando tenga el merge listo realizara sus pruebas para asegurarse de que todos los cambios funcionan correctamente y es entonces cuando este tendrá que hablar con nosotros (Arquitecto) para solicitar subir la versión al repositorio central (Push), nosotros solo aceptaremos los Push de la gente de nuestra confianza ya que estamos seguros de que son los expertos de cada tema y podremos estar seguro de que las versiones funcionarán, sin embargo si cualquier por debajo intenta hacer un Push será rechazado.

Ahora bien, que pasa con las empresas subcontratadas, estas tendrán que clonar el repositorio de nuestro líder para empezar a trabajar y repetirán el mismo proceso descrito anteriormente, ellos tendrán que solicitar el push al líder de la célula para afectar ese módulo. Ahora pensemos si esta empresa a su vez subcontrata a otras personas o divide su trabajo en grupo, esto los obligaría a repetir el flujo

Bien, pero ¿qué pasa si una célula depende del trabajo de otra célula?, existen dos opciones la primera es que la celular que tiene este cambio suba los cambios al repositorio en común para que la otra célula los descargue (Pull) o bien, la segunda célula podría enviar los cambios directamente al repositorio de la otra célula solicitando un Push al repositorio de la primera célula.

Para más información de Git podemos ver la siguiente página https://es.wikipedia.org/wiki/Git

Finalmente Git vs Subversion

Subversion es ideal cuando

• Tenemos equipos de trabajo pequeños.
• Conocemos a todos los involucrados en el desarrollo del proyecto.
• Cuando no necesitamos un repositorio complejo.
• No se tiene una infraestructura para mantener varios repositorios

Git es ideal cuando

• Cuando tenemos equipos muy medianos a grandes.
• No conocemos a todos los involucrados en el desarrollo del proyecto.
• Cuando mantener es necesario mantener una jerarquía de confianza en las personas que afectan el repositorio.
• Cuando nuestro proyecto está enfocado a la comunidad y que estamos dispuesto a compartir nuestro código.

Básicamente estas son las razones por las que yo me inclinaría a elegir alguno.

Espero que este articulo les sirva de ayuda para comprender mejor el funcionamiento de estos dos tipos de SCV, si esta información te fue de ayuda no dudes en compartirlo y suscribirse para recibir nuevas entradas de mi blog.