[03/07/2023] Git comenzó como un software de control de versiones desarrollado para administrar el código fuente del kernel de Linux. Desde entonces, se ha convertido en la herramienta de acceso predeterminada destinada a la administración de bases de código fuente para casi todos los proyectos de código abierto, y también para muchos de código cerrado.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
A pesar de toda su popularidad, Git también genera quejas profundas y legítimas. Su modelo para organizar el código es complejo, quizás demasiado complejo para su propio bien, y su conjunto de comandos puede ser confuso. Desafortunadamente, las GUI y los front ends simplemente enmascaran la complejidad subyacente en lugar de resolver el problema. Git tampoco funciona bien con ciertos tipos de archivos que se rastrean en proyectos de código abierto, como archivos binarios grandes y estructuras de datos complejas.
Si alguno de estos problemas le preocupa, es posible que tenga curiosidad acerca de las alternativas viables a Git. Estas existen, y muchas de ellas prosperan en sus propios espacios porque ofrecen características que Git no tiene. En este artículo, veremos tres de las mayores alternativas de Git: Fossil, Mercurial y Subversion. Cubriremos sus características y casos de uso y los proyectos en los que se están utilizando en este momento.
Fossil
D. Richard Hipp es mejor conocido como el creador de SQLite, el sistema de base de datos de código abierto integrable que es una de las piezas de software más utilizadas en el mundo. Pero Hipp no usa Git para el control de fuente en el proyecto SQLite. En cambio, usa Fossil, un sistema de control de fuente que creó específicamente para ayudar al desarrollo de SQLite.
La mayor diferencia entre Fossil y Git es que es un producto todo en uno. Git solo maneja el seguimiento y la anotación de cambios en una base de código a través de un sistema de archivos virtual. Fossil es más parecido a Bitbucket: es un sistema de alojamiento autónomo que no solo realiza un seguimiento de los cambios, sino que también integra la emisión de tickets y el seguimiento de errores, wikis, documentación y discusión en vivo para un proyecto. Todo esto está respaldado por la base de datos SQLite que -como el propio SQLite- se ejecuta desde un único ejecutable independiente con un espacio de aproximadamente 8MB.
Fossil usa una estructura de datos similar a Git; sin embargo, mientras que Git usa el propio sistema de archivos para almacenar cambios, Fossil mantiene todo en una base de datos SQLite. Las consultas sobre cambios -como examinar todos los cambios en un archivo determinado a lo largo del tiempo o gráficos detallados sobre el progreso de un proyecto- se pueden calcular rápidamente, ya que suman a consultas SQL.
Las diferencias de diseño y comportamiento en Fossil lo hacen, según Hipp, más adecuado para equipos más pequeños y cohesionados, como los que trabajan en SQLite y Fossil mismo. Fossil aún puede funcionar de manera descentralizada, pero la mayoría de los cambios remotos se sincronizan automáticamente con un repositorio principal, en lugar de desarrollarse por separado con el tiempo y luego reconciliarse (lo que Hipp llama la filosofía de "sincronización sobre inserción”). El proyecto Tcl/Tk utiliza Fossil, al igual que algunos otros proyectos relacionados con Tcl.
Hipp proporciona notas detalladas sobre cómo moverse entre Git y Fossil, o sincronizar un proyecto entre ambos sistemas. Tenga en cuenta que las funciones específicas de Fossil, como la wiki de un proyecto, no se transfieren a Git, al menos no automáticamente.
Mercurial
En el 2005, el sistema propietario de control de código fuente, BitKeeper, revocó su licencia gratuita para el kernel de Linux. Dos reemplazos surgieron a raíz de BitKeeper. Uno era Git, usado para el kernel de Linux -y más tarde, muchas otras cosas-. El otro fue Mercurial, que no terminó siendo utilizado por el proyecto del kernel de Linux, pero todavía lo utilizan los desarrolladores que trabajan en Facebook, Mozilla, el W3C y el proyecto PyPy.
Conceptualmente, Mercurial y Git funcionan de la misma manera. Ambos usan un gráfico de los cambios realizados en una base de código, y cualquier cambio puede tener muchos hijos. Pero el conjunto de comandos básicos de Mercurial para casos de uso común es más pequeño y fácil de dominar -son seis o siete comandos en comparación con los más de 12 usos en la mayoría de los escenarios de Git.
Una diferencia clave con Git es cómo funcionan las ramas en un árbol de fuentes. Cuando usted cambia de rama en Git, su directorio actual se reescribe para reflejar el contenido de la rama. En Mercurial, hay algunas estrategias diferentes para ramificar:
- Puede clonar el repositorio en otro directorio y trabajar en eso como una rama (fácil de cambiar de rama pero lento para crearlas).
- Puede marcar diferentes puntos en un conjunto de cambios y usarlos como base para los cambios, lo que se parece mucho al propio comportamiento de Git.
- Puede usar una "rama con nombre”, donde el nombre se convierte en una parte permanente del conjunto de cambios, útil porque el nombre se refleja en cada cambio futuro en esa rama, pero puede crear desorden.
- Puede crear ramas anónimas y sin nombre, que son convenientes para cambios rápidos pero pueden resultar confusos si no explica correctamente lo que ha hecho en sus notas de cambio.
Si desea cambiar la forma en que se comporta Git, generalmente usa otros programas independientes, según la filosofía de "cada programa hace una cosa” de la cadena de herramientas de Linux. Por el contrario, Mercurial ofrece un mecanismo de extensión para que el código de terceros pueda integrarse directamente en Mercurial y ampliar su funcionalidad. Mercurial viene con una gran cantidad de extensiones, lo que permite todo, desde hacer comparaciones de cambios con utilidades externas hasta borrar todo en un directorio determinado que Mercurial no haya cambiado activamente. Quizás la característica más útil, desde el punto de vista externo, es la capacidad de sincronizar un repositorio de Mercurial con un repositorio de Git, lo cual es excelente si su base de código está en transición del uno al otro.
Subversion
El proyecto Subversion, de Apache Foundation, también conocido como SVN, surgió originalmente en el 2000. Su versión inicial 1.0, en el 2004, es ligeramente anterior a Git. Apache, FreeBSD y SourceForge son algunos de los usuarios más conocidos de Subversion. El proyecto GCC lo usó hasta el 2019, pero desde entonces migró a Git.
La principal diferencia de SVN con Git es que está centralizado, lo que significa que el repositorio se almacena en una ubicación fija única. Los colaboradores normalmente no hacen copias locales del código base, sino que trabajan en ramas del código en la copia centralizada. Un administrador puede establecer controles de acceso altamente granulares en un repositorio de Subversion, por lo que las contribuciones no tienen que ordenarse manualmente.
La naturaleza centralizada de SVN es tanto una bendición como una carga. Es una carga en el sentido de que, si algo le sucede al repositorio central, será mejor que tenga un buen plan de backup. Hacer que cada desarrollador guarde una copia del código hace que los proyectos sean mucho más resistentes a los discos duros muertos (o administradores de sistemas vengativos). También dificulta probar todo el código base a la vez. Y también significa que las ramas del código se manejan con menos elegancia -básicamente, son directorios físicos con copias discretas del código, en lugar del modelo de sistema de archivos virtual de Git.
Pero el diseño centralizado es una ventaja, ya que hace que el modelo conceptual de SVN sea mucho más simple y, a su vez, hace que sea más fácil trabajar con SVN en general. Hay menos pasos necesarios para conocer cuando se trabaja con una base de código, incluso si esos pasos individuales tienen más requerimientos. Además, SVN maneja mejor los archivos binarios grandes, ya que utiliza un algoritmo de diferenciación muy adecuado para dichos archivos.
Otra diferencia principal surge de la centralidad de SVN. La historia de un repositorio es inmutable. Git permite que el historial de un repositorio se modifique retroactivamente, pero SVN no. Es una fuente única de verdad para un proyecto, y eso es crucial si importa tener un control estricto sobre la fuente.
GitHub soportó los repositorios de Subversion durante algún tiempo, pero eliminará gradualmente el soporte a partir de enero del 2024. (GitLab y Bitbucket no son compatibles con los repositorios de Subversion; para usarlos, debe convertir un repositorio a Git manualmente).
Conclusión
Fossil proporciona una experiencia todo en uno similar a una plataforma de alojamiento de código lista para usarse, completa con emisión de boletos y discusión, mientras que Git se enfoca exclusivamente en el seguimiento de cambios a través de una colección de herramientas de filosofía Unix. El mecanismo de extensión de Mercurial lo hace modificable de forma nativa; los comportamientos de Git se modificarían con herramientas externas. Y la centralización de Subversion proporciona un modelo conceptual más simple y un control más estricto sobre la fuente, en comparación con los conceptos complejos y el manejo descentralizado de archivos de Git.
Basado en el artículo de Serdar Yegulalp (InfoWorld) y editado por CIO Perú