SVN y Git provienen de dos modelos distintos de control de versiones: el centralizado y el distribuido, en la práctica son similares, sin embargo existen marcadas diferencias que hacen que la elección de cuál usar en un proyecto, dependen de varios factores.
Ventajas y desventajas del modelo centralizado
- Luce mas simple
- Existen muchas herramientas para trabajar con repositorios centralizados, ya que llevan mas años y fueron muy difundidos
- Muchas IDEs tienen soporte completo
- No pueden haber commits offline
- Dificultades para trabajar con branchs
- Dificultades para trabajar en equipos grandes.
Ventajas y desventajas del modelo distribuido
- Modelo simple de colaboración
- Permite trabajar offline
- La instalación es sencilla y hay muchos servicios de hosting
- Copia completa del repositorio en cada clon
- Todo el trabajo casi es local.
- Tiene flujo de trabajo mas complejo, sobre todo en equipos grande, y con diferentes permisos por usuario.
- Una curva de aprendizaje mas grande
Diferencias principales:
El modo de guardar la historia: Para SVN la historia de un proyecto nunca cambia, sin embargo Git permite modificar commits anteriores usando por ejemplo: git rebase. A pesar de que puedan haber maneras de editar el mensaje de un commit en SVN, esto requiere permisos de administrador, algo que no es recomendable si hay que darle permisos de administrador con equipos de trabajo grande.
Estructura del directorio: Para SVN se deben tener carpetas distintas para trunk, branches, y tags, en Git todo esta en una sola carpeta y Git se encarga de ocultar el master, branches y tags.
Subproyectos: Un subproyecto permite compartir código o módulos entre proyectos, para SVN se usa el svn-external y en git existen los Git submodels, comparten el mismo concepto pero el uso y el flujo de trabajo es el mismo.
Este artículo de Github amplia esta breve explicación de las diferencias: https://help.github.com/articles/what-are-the-differences-between-svn-and-git
¿Por qué combinar SVN y Git? Mi caso de éxito
Hay casos específicos en los cuales su combinación de verdad que resuelve muchos problemas, sobre todo aprovechando que el uso de Git para ramas locales es fantástico.
Actualmente trabajo en Belatrix y por motivos de contrato con el cliente (confidencialidad), no puedo mencionar detalles, nombres, mucho menos información privada del proyecto, sin embargo puedo explicar el flujo de trabajo que usamos y que se puede replicar en otros proyectos.
Mi cliente es una compañía multinacional que tiene un producto muy bueno de banca móvil, completamente configurable y adaptable a los sistemas bancarios actuales, lo que hace que tenga a su vez miles de clientes (entidades financieras) que usan su producto y por lo tanto al final el producto que ayudamos a construir es usado por millones de personas alrededor del mundo, para lograr y mantener ese éxito tan grande que están teniendo ahora, se necesitan muchas personas involucradas en el desarrollo del producto, decenas de desarrolladores usando los mismos repositorios, las mismas ramas, con diferentes permisos de acceso y demás. Mi cliente ha elegido SVN como gestor de sus repositorios, por diversas razones técnicamente justificables.
A pesar de que la tendencia se da hacia modelos distribuidos de control de versiones (Git y Mercurial en su mayoría), el uso de SVN sigue siendo masivo en muchas empresas y proyectos.
En este proyecto Belatrix lleva aproximadamente 4 años y nuestro equipo en particular lleva un año y medio aproximadamente, al principio mi equipo empezó a utilizar git-svn para manejar ramas locales y funcionaba muy bien, el cliente tenia una rama principal, una rama para el proyecto, una rama para el modulo que estábamos desarrollando, y nosotros gracias a git-svn teníamos ramas para lo que queramos: bugs, User Stories, improvements, cleanups y encontramos un flujo de trabajo muy bueno y simple de mantener.
Para lograr esto usábamos git-svn (https://www.kernel.org/pub/software/scm/git/docs/git-svn.html), todo iba bien hasta que en el lado del SVN se empezó a usar svn-externals, a partir de entonces dejo de funcionar git-svn y si hubiéramos querido forzarlo, hubiéramos complicado el flujo de trabajo y probablemente hubiéramos aumentando las probabilidades a cometer errores.
Es aquí donde encontramos una forma simple de continuar con nuestro flujo de trabajo y este fue un par de cambios en el .gitignore, el flujo de trabajo es como el que describo a continuación:
- svn checkout <ruta_del_servidor_SVN>
- git init (en la carpeta donde se hizo el checkout)
- Agregar .svn/ al .gitignore (para que Git ignore a la carpeta principal del SVN, este es un paso muy importante, de no hacerlo correctamente todo el flujo fallará.)
- Agregar */.svn/ al .gitignore (para que Git ignore a multiples carpetas).
- Continuar el desarrollo con Git, creando ramas locales y usarlo como se acostumbra.
- Actualizar y mantener sincronizado el Git master antes de hacer un commit al SVN
- Los commits siempre van al Git master para evitar errores y desde el Git master se hacen los commits al SVN.
- Los updates desde el SVN siempre se hacen al Git master, de manera tal que el master siempre tiene una copia actualizada.
Si te sirve sienteté libre de comentar, sugerir una mejora para este flujo y compartirlo 🙂
Me gusta:
Me gusta Cargando...
