SVN vs Git: Lo que os estáis perdiendo por usar SVN y no Git. Desde que empecé a trabajar en Prodevelop, siempre habíamos usado SVN como sistema de control de versiones.
Para mis proyectos personales tanto los que quiero liberar como los que no, suelo usar Git (tanto a través de Github como de Bitbucket).
En este mes que llevo trabajando en CARTO, me ha llamado la atención los usos que se le puede dar a Git en general y Github en concreto, en un entorno empresarial. Sobretodo viniendo de haber usado durante tanto tiempo SVN.
Así que he decidido hacer una pequeña lista de motivos de “lo que os estáis perdiendo por usar SVN y no Git”, especialmente orientado a mis antiguos compañeros 🙂 (o a empresas que aún usan SVN)
SVN vs Git
Voy a asumir que da igual Github, Gitlab o cualquier otro servidor de Git (sin saber muy bien si todas tienen las mismas características) y lo voy a orientar desde el punto de vista del día a día de desarrolladores (sin entrar en detalles de backups, migraciones, ni historias de sistemas)
Ramas bien con “pull requests” y code reviews
El primer concepto que no existe en SVN y sí en Git es el de “pull request” o qué coño, el de las ramas en general.
Hablemos claro: el soporte a ramas en SVN es una ñapa (leed sobre la historia de SVN y es así, literal).
Un workflow típico para trabajar con Git es el siguiente:
- Hay una rama principal con el código que va a producción
- Un desarrollador hace una rama para desarrollar algo nuevo o corregir un bug (asociados a una issue)
- El desarrollador, cuando termina, hace una pull request para mezclar sus cambios en al rama principal
- Otro desarrollador revisa el código y da el OK (o no)
- El desarrollador original hace el merge y el código pasa a producción
Esto en SVN no existe y me da un poco de rabia lo mal que se pueden llegar a hacer las cosas por no tener las herramientas adecuadas.
Issues: Comunicación + trazabilidad
Una pregunta a la que no se puede responder si trabajas con SVN es: “¿Por qué se ha hecho este commit?”.
Es decir, cuál es el bug o la incidencia que está relacionado con este o estos commits, para saber el motivo por el cual se ha hecho ese cambio en el código.
Los servidores de Git, ofrecen el concepto de “issue“, que permite tener una trazabilidad completa de commits a un bug o incidencia concreta. Además, una issue es casi como una conversación entre los desarrolladores para resolver algo relacionado con el código.
Sinceramente, ahora que lo he vivido, no sé cómo se puede trabajar de otra manera. Aún así, el concepto de “issue“, no creo que sea exclusivo de servidores Git, pero sí que es verdad que está incluido en el workflow de trabajo de manera natural.
Una “issue” permite tener una trazabilidad completa de commits a un bug o incidencia de un proyecto
Por otra parte, puesto que las issues son tan cómodas, facilitan la conversación y la trazabilidad, no es descabellado utilizarlas para gestionar muchas otras tareas que no llevan implicado código o desarrolladores.
Si a esto le añades el soporte a Kanban que ofrecen algunos servidores Git, tienes un sistema completo de gestión del ciclo de vida de tus proyectos, que funciona “out of the box”
Forks bien
Otro tema aparte son los forks.
Como ya conté aquí, los forks son la manera natural en que personas externas a una organización contribuyen a un proyecto en Git. Ojo a lo de “personas externas” porque dentro de la propia organización no se suelen usar.
Git es un sistema distribuido y esto permite que tu “copia” local de un repositorio la puedas conectar a varias copias remotas, facilitando la gestión del código y la colaboración (otra vez).
Esto en SVN simplemente no existe. Un fork es otra cosaColaboración
Por lo que he comentado hasta ahora, la idea de que Git es un sistema de control de versiones “colaborativo”, no parece sólo una frase de marketing sino es que está diseñado así:
- Personas externas a la organización pueden colaborar fácilmente a través de forks
- Personas de la organización colaboran, comentan y se puede trazar la historia completa de una tarea o issue
- Los desarrolladores colaboran continuamente y es muy fácil revisar el código que pasa a producción
Nada de esto funciona así en SVN.
Ahora dime, ¿cuántos proyectos en tu organización (y hablo del código fuente) hay, de los que no sabes absolutamente nada ni tienes forma de saberlo? Es más, en los proyectos que trabajas, ¿realmente sabes lo que están haciendo tus compañeros?
¿Por qué debéis dejar de usar SVN mañana mismo?
Si todo esto te da igual porque trabajas en una organización cerrada, porque usas SVN y “te funciona” o porque no puedes asumir hacer el cambio, aún hay 3 motivos más por los que debes de dejar de usar SVN y empezar a usar Git mañana mismo:
- Integraciones: Esto ya depende del servidor o SaaS Git que utilices, pero por ejemplo en el caso de Github hay integraciones para cualquier cosa que te quieras imaginar a través de su API y marketplace, pero además ofrece algunas características intersantes (Markdown para documentar, soporte nativo a GeoJSON, gh-pages, etc.)
- Git como sistema de control de versiones es más robusto, más rápido, funciona en local y en general está mejor diseñado
- Hay tanto servidores Git libres como SaaS de pago para las que no se quieran calentar la cabeza (ahora mismo no conozco ningún SaaS de SVN que me convenza)
Un par de advertencias
Dicho todo esto, sí que hay dos cosas que hay que tener en cuenta, en esta comparación SVN vs Git:
Por una parte, Git es algo más complejo que SVN (tampoco mucho), en el sentido de que hay comandos un poco enrevesados (aunque no son los que se usan en el día a día)
Por otra parte, para un equipo que esté acostumbrado a trabajar exclusivamente con SVN sí que creo que igual haría falta un mínimo de formación para que todo el mundo entienda bien los conceptos de Git desde el primer día (son los que he contado) y sacarle el máximo partido.
Ojo con esto último, porque es muy fácil cometer el error de usar Git como un SVN y quedarte igual que estabas.
En fin, qué pena haber estado tantos años haciendo el inútil con SVN 🙁
Hace años quería hacer el cambio, pero hacer la migración en un entorno con tantos repositorios SVN y tan pocos recursos se antojaba un tanto complicada. Buen artículo, si lo hubiera leído hace tiempo seguro nos hubieras convencido a hacer la migración. Crack!
Buenas!
Sí… Por eso pongo que no tengo en cuenta el curro del lado de sistemas, porque seguro que es un dolor de cabeza… Pero cuando te lo dan todo hecho mola!
Un abrazo!