You are currently browsing the monthly archive for May 2016.
Existen no sé cuántas páginas en Internet que te explican por qué el control de versiones git es mejor que Subversion. No quiero decir que git es peor, pero poco de lo que provee realmente necesitas en muchas ocasiones. Así quiero dar razones por qué quedar con Subversion – sobre todo para los proyectos que ya lo están usando.
Trabajar en Corea del Norte
El cambio más importante de git respecto a Subversion es tener múltiples repositorios en lugar de uno. Mientras en Subversion te puedes confundir, sobre qué rama trabaja tu copia de trabajo, con git te puedes confundir sobre la rama y, además, sobre si has publicados tus cambios locales a qué otro repositorio.
Ninguna página sobre git pierde advertir, que estos repositorios locales te permiten trabajar off-line. Esto habría sido una maravilla con la velocidad del internet en el siglo pasado. Hoy no conozco ninguna empresa informática donde los empleados serían capaces trabajar sin red. ¿Qué te sirve hacer un check-in local si no puedes compilar porque el compilador descarga bibliotecas de un disco en red? Por supuesto, otra cosa es si te envían frecuentemente a Corea del Norte u otro lugar, donde el WIFI de alta velocidad no suele ser la regla.
Copiar repositorios enteros en lugar de ramas
Otra publicidad para git suele ser el cheap branching (ramificación barata), es decir, crear ramas nuevas cuesta poco. Crear ramas es rápido en git porque sólo se crean en tu repositorio local. En Subversion debes crear la rama en el repositorio. No obstante, no ralentiza mucho. La mayor parte de la creación pasas tecleando el nombre de la nueva rama – algo que git no te ahorra tampoco.
Ahora depende como quieres trabajar con tu nueva rama. Una es reciclar tu copia de trabajo y hacerla apuntar a la nueva rama. Esto se hace con switch en Subversion y con checkout en git. Como git no accede a la red, es más rápido. No obstante la pregunta es, si realmente quieres trabajar así, porque puedes confundir la rama en que piensas trabajar con la en que realmente trabajas. Los ficheros modificados en tu copia de trabajo se mantienen y serán ahora ficheros modificaciones sobre la nueva rama a que cambiaste. Si la rama anterior era de una versión de hace un año, con un poco de suerte no sólo harás un check-in de las tres líneas que has modificado sino, además, del estado que tuve el fichero hace un año.
Por no provocar tu suerte decides a editar cada rama en un directorio aparte. Así el flujo de trabajo es así: en Subversion, creas la rama en el repositorio y haces un check-out de lo que necesitas. En git haces una copia (clone) del repositorio entero y creas la rama. Es decir, primero copias el repositorio entero y no sólo lo que necesitas. Pero luego crear la rama, esto, sí, es rápido.
Como no querrás esperar a tanto cheap branching para cada rama que creas, git invita a crear muchos repositorios de que cada uno contiene lo mínimo posible. Puedes crear repositorios pequeños también con Subversion, pero no lo necesitas. Puedes tener un mega-proyecto en un repositorio y no hace falta comprarte un nuevo disco duro para tu copia de trabajo, ya que sólo necesitas descargarte le parte que quieres modificar.
Guardarlo todo
Otra auto-publicidad de git es guardar ficheros enteros en lugar de diferencias. La ventaja: es más rápido al hacer un check-out, ya que git sólo necesita buscar el fichero dentro de un commit y copiarlo. Subversion, en cambio, debe reconstruir el fichero a base del primer check-in más todos los cambios de la historia.
La ventaja de Subversion es que descargas un fichero por la red. En git descargas el repositorio entero con todas las versiones enteras de todos los ficheros – y así lo tendrás también guardado en tu disco duro.
El directorio .git
Git usa una carpeta escondida den nombre «.git» en el directorio raiz para guardar sus datos. En muchas páginas puedes leer que Subversion no es así, porque guarda una carpeta escondida «.svn» en cada carpeta. Esto era cierto. No obstante, esto ha cambiado desde la versión 1.7 de Subversion. Ahora sólo hay una carpeta «.svn» en el directorio raiz – igual como en git.
Seguridad para la generación selfie
Git hace publicidad con la seguridad de los datos. Una revisión no tiene un número, sino un hash, es decir un número hexadecimal lo suficientemente largo, para que, con seguridad, no podrás memorizarlo. Esto es para que no se altere la integridad del commit. El hash se calcula a base de los datos que componen un commit. Cambiar un byte cambia el hash. Al mismo tiempo, git te permite unir varios commits en uno, mover el origin de una rama a otro commit y hacer desaparecer commits por completo. Lo importante es que los commits no aparezcan como si hubieras probado algo, sino que la historia del repositorio muestra que hiciste todos los cambios completos y correctos a la primera. Sólo falta el botón «me gusta».
En Subversion, en cambio, se queda la historia sin alterar. Lo que está dentro, se queda – a menos si lo quieres hackear. Si haces un merge de una rama, entonces no se copia la historia entera de la rama añadida sino se crear un nuevo commit, donde puedes poner todos los comentarios sensatos que el release manager necesita para decidir si tu cambio entra o no. Los comentarios y check-ins caóticos de tu rama de desarrollo no entran, porque se quedan únicamente en la rama de desarrollo.
Es cierto que tu repositorio de Subversion acumula ramas de desarrollo difuntas que ocupan espacio aunque ya no se necesitan. En git, el repositorio central sólo necesita guardar lo que realmente está terminado y funcionando. Pero esto surge porque estás dispuesto a jugar con dos repositorios a la vez. Lo puedes hacer también en Subversion. Exportas la rama de release, copias los ficheros a la copia de trabajo del repositorio bonito y haces un check-in.
Un repositorio para el back-up
Finalmente queda por hacer una copia de seguridad de tu repositorio, porque no quieres perder tus cambios si se rompe tu disco duro. Normalmente sólo se hace una copia de seguridad del repositorio central. En Subversion, todos los commits entran en la próxima copia de seguridad. En git, te debes pensar si haces un push al repositorio central o creas algún repositorio intermedio (probablemente en red), sobre qué el administrador de sistema hace una copia de seguridad. Así puedes elegir entre olvidar el push al repositorio central o intermedio o olvidar la copia de seguridad de tu repositorios locales.
Se puede argumentar que cualquier directorio de git es un back-up del repositorio central. Esto puede ser válido pero también puede que no. Es posible que sólo empujas commits buenos al repositorio central y el repositorio local contiene muchos más commits «de trabajo». Es posible que estos no quieres tener en el repositorio central. Además hay configuraciones que son locales a un repositorio determinado – por ejemplo los scripts (hooks) que se llaman en caso de un commit. En fin, es probable que todavía prefieres hacer un back-up del repositorio central como se hace con el repositorio de Subversion, porque la existencias de múltiples clones no te tranquiliza lo suficiente.
El pull request
Una ventaja en el ámbito de git es el pull request. Es un flujo de trabajo en que un desarrollador dice que ha terminado algo y pide al jefe de integrarlo en la rama de release. Antes unas cuantas personas más pueden dar su acuerdo o incluso añadir nuevos commits con cambios. Esta funcionalidad no es de git mismo, sino un software adicional que ofrecen servidores para proyectos en git como GitHub.
Los servidores de Subversion no suelen ofrecer esto aunque teóricamente podrían. Pero es cuestionable si hace falta. En muchos proyectos, los desarrolladores pueden comunicarse de otras formas, se puede convenir que nadie hace un check-in en la rama de release menos el autorizado y siempre es posible crear una rama de la rama para proponer modificaciones adicionales. No aparece todo tan bonito en una página web, pero posible, sí, que es.
Y claro, siempre es posible que alguién implemente algo parecido al pull request para Subversion.
Quédate con lo que tienes
Si ya trabajas en git, entonces déjalo. Git no es peor que Subversion. Pero antes de migrar mil proyectos a git, piénsatelo bien. La mayoría de los argumentos a favor de git se mueven en el nivel de alguien que quiere vender su coche normalito para comprarse un SUV. Como no hay razones de verdad a favor de un SUV, busca razones que, al menos para él, aparentan serlo. El SUV gasta más, cuesta más, ocupa más espacio y es tan estrecho por dentro que la rueda de repuesto no cabe. Pero es mejor porque tiene capabilidad de todo-terreno. Aunque esta nunca aprovecharé porque no quiero que me salpique la tierra a mi bonito coche.
Antes de invertir en git, aprende a diferenciar los usuarios de los creyentes en git. Haz un análisis sobre qué esperas de un control de versiones y piensa si el cambio vale la inversión. Si ni siquiera te convence su propia publicidad, entonces es mejor seguir con lo que tienes.
Los repositorios descentralizados son una ventaja cuando los desarrolladores están distribuidos sobre el planeta como suele ser en muchos proyectos de código abierto. No obstante, en las empresas, los desarrolladores suelen trabajar en la misma oficina. Y existe un buen compromiso: el programa git svn permite trabajar con Subversion como si fuera git y, al mismo tiempo, permite trabajar con Subversion como si fuera Subversion. Es decir, es como un coche normal pero con tracción de cuatro ruedas.
Referencias
- Página principal de Subversion
- Página principal de git. git svn es parte del paquete git.
- Página principal de GitHub
Trucos informáticos 