5 sistemas de control de versiones gratuitos de un vistazo (2023)

Git, SVN, Mercurial, Bazaar y Fossil5 sistemas de control de versiones gratuitos de un vistazo

Un sistema de control de versiones, o VCS para abreviar, pone orden en el caos del código durante la programación. Pero la categoría de software desencadena debates emocionales similares a los de los sistemas operativos o los editores de texto. Presentamos los candidatos gratuitos y de código abierto más importantes.

El desarrollo de software produce inevitablemente una maraña de versiones: se desarrollan diferentes características, se crean estados intermedios para las pruebas, se prueban diferentes caminos y se reúne el trabajo paralelo de varios desarrolladores.

Control de versionesPor lo tanto, el software (VCS) es esencial para los desarrolladores de software, pero los proyectos de texto más grandes, como la documentación con muchos autores, también pueden beneficiarse de él. Los sistemas VCS garantizan que todos los involucrados reciban los archivos necesarios, que puedan ingresar cambios, que todo sea rastreable y revisable y, por supuesto, que todos trabajen con la misma versión más actualizada.

Esto también requiere lidiar con conflictos, es decir, si varios autores (quieren) editar la misma parte de un archivo de manera diferente. Y más allá, por supuesto, el versionado en sí y, por tanto, también el trabajo en las bifurcaciones de la línea de desarrollo principal.

Las mayores diferencias residen en estas tareas centrales: ¿sistema distribuido o central? ¿Cómo se abordan los conflictos? Y por último, pero no menos importante: ¿qué tan complicado es su uso? A continuación presentamos cinco de los sistemas más conocidos y sus ventajas.

git

La plataformagit, iniciado en 2005 por Linus Torvalds, básicamente tiene que empezar aquí. No hay cifras realmente claras sobre la cuota de mercado, pero al menos en elFuente abiertaEn esta área, según la mayoría de las estadísticas que se pueden encontrar, Git es claramente el número 1. A veces durante cinco años, a veces durante ocho años, a veces con una cuota de mercado del 70 o incluso del 87 por ciento.

No es raro que la gente piense que esto no se debe necesariamente a Git, sino más bien a él.GitHub. Su popularidad es inquebrantable y el software de código abierto ahora se puede encontrar principalmente allí, ya no en Sourceforge o Google Code.

Git es un sistema distribuido que se puede utilizar sin conexión con un historial de versiones completo, lo cual es una gran ventaja. un nuevoRepositorioSe puede crear directamente desde una carpeta existente con un solo comando y servir como servidor para terceros con "un poco" de configuración. Todos los cambios debajo de la carpeta inicial ahora se registran, no a nivel de archivo, sino para el repositorio en su conjunto.

Para el conflicto existe un complejo.Unirsistema, que por un lado resuelve automáticamente y muy bien conflictos bastante triviales, por otro lado requiere algo de trabajo manual y comprensión de los aspectos internos de Git para problemas más grandes. Git también es muy rápido y te permite trabajar con ramas fácilmente. Una ventaja también se deriva de la amplia distribución: Git se implementa muy a menudo en otros productos como, por ejemplo, editores; esto también se aplica al antiguo competidor principal SVN, pero en caso de duda es más probable encontrar Git.

Uno de los principales puntos de crítica a Git es sin duda la pronunciada curva de aprendizaje: el concepto detrás de Git es bastante opaco al principio, pero se requieren conocimientos en muchas áreas del trabajo diario. Git también viene con muchas herramientas que es necesario aprender primero. Una crítica absolutamente justificada: debido a la naturaleza distribuida, el trabajo fuera de línea, la sencilla bifurcación y el sistema de fusión, git conlleva un cierto esfuerzo administrativo.

Por otro lado, la documentación ahora es muy buena y, para el líder del mercado, por supuesto, hay muchas instrucciones y artículos de terceros. También puedes encontrar una versión de tres partes aquí en Dev-Insider.Tutorial sobre cómo trabajar con Git. La belleza de este sistema de control de versiones: una vez aprendido, es muy flexible en la vida cotidiana y básicamente también bastante sencillo.

Subversión Apache

Subversion, normalmente llamada simplemente SVN, se gestiona desde el año 2000.Código fuentey es el predecesor de Git como claro líder del mercado. SVN, por su parte, había reemplazado previamente al Sistema de Versiones Concurrentes (CVS), que se desarrolló en 1990. Aunque Subversion parece estar en declive, todavía hay muchos partidarios fervientes; después de todo, el concepto es notablemente diferente de Git.

Esto comienza con el hecho de que Subversion necesita un servidor central. Para proyectos más pequeños, muchos usuarios consideran que esto es mejor que mantener todos los datos en cada computadora individual. Sin embargo, el trabajo fuera de línea sólo es posible de forma limitada. En última instancia, es una cuestión de la situación, del equipo y, sobre todo, de la organización si la mejor opción es peer-to-peer o cliente-servidor. Cualquiera que trabaje con muchos archivos binarios de gran tamaño, por ejemplo en proyectos multimedia, distribuye enormes cantidades de datos, por ejemplo, a través de Git.

SVN también puede puntuar con el segundo gran punto de diferencia. En lugar de simplemente confiar en la estrategia de combinación para fusionar conflictos de forma automática o manual, aquí también existe la estrategia de bloqueo: los archivos/carpetas se pueden bloquear para otros tan pronto como sean editados por un usuario. De esta forma se pueden evitar los conflictos desde el principio. Por supuesto, a expensas de los empleados que simplemente no pueden acceder al expediente; Básicamente, Git permite que todos los participantes hagan todo.

A menudo, una ventaja de Subversion: los cambios se registran a nivel de carpeta y archivo. Entonces, cuando cambia el nombre de un archivo, mantiene su historial de versiones completo, mientras que Git crearía un nuevo objeto con un nuevo historial. Esto corresponde al menos en mayor medida a las expectativas de los usuarios que no están familiarizados con VCS. En general, SVN a veces funciona "más cerca de los archivos". En SVN, las ramas son carpetas, en Git son simplemente referencias a cambios en el historial de versiones, del cual simplemente se bifurca.

Con todo, SVN es (inicialmente) más fácil de usar y, en ocasiones, los no desarrolladores lo utilizan para la gestión de documentos. Nota personal: Por otro lado, este documento también se gestiona en un repositorio de Git; por lo tanto, Git también es adecuado para tareas cotidianas y más fiable que algunas soluciones de sincronización.

Mercurial

Mercurial es similar a Git en algunos aspectos: también es de 2005, también debería reemplazar a otro sistema (BitKeeper) y se usa para el kernel de Linux, también es un sistema distribuido y las estrategias de resolución de conflictos también son similares. Por cierto, el sistema a menudo se llama simplemente Hg, el símbolo químico del mercurio (mercurio).

El trabajo básico es muy similar entre Git y Mercurial, pero existen algunas diferencias notables. Por ejemplo, Mercurial ha dominado el arte del simple comando "deshacer", es decir, la inversión de operaciones; con Git esto sólo se puede hacer con muchos conocimientos previos y mecanografía.

Mercurial también viene con su propio servidor web, lo que facilita que los repositorios estén disponibles para terceros. Otras diferencias técnicas con Git son, por ejemplo, lalenguaje de programación(aquíPitón), etiquetas globales para múltiples repositorios, soporte nativo de Windows, estrategia de combinación y bloqueo o mejor ayuda interna. Por otro lado, Mercurial también cuenta con características conocidas de Subversion, sobre todo mantener el historial de versiones al mover y copiar procesos.

Mercurial suele salir muy bien librado en las discusiones, en parte porque a muchas personas les resulta mucho más fácil empezar y Git es quizás un poco más complicado de usar en un momento u otro. En este sentido, desde un punto de vista técnico, Mercurial es sin duda un consejo para principiantes, pero esto se contradice con la presencia de Git en el mercado: probablemente se pueda encontrar un usuario de Git en cada autobús.

Bazar GNU

Encontrar un usuario de Bazaar debería ser mucho más difícil; Este es también un sistema distribuido programado con Python desde el año 2005, respaldado por Canonical, un fuerte patrocinador. Además, forma parte deÑU-El proyecto.

Bazaar también tiene algunas características interesantes. Por ejemplo, funciona de forma puramente distribuida o con un servidor central, o incluso con ambas cosas al mismo tiempo. Bazaar puede incluso crear ramas desde repositorios de Subversion, editarlas y enviarlas de regreso a Subversion. Al menos puedes leer en Git y Mercurial. También es posible importar y exportar historiales completos hacia/desde varios sistemas VCS.

Desafortunadamente, Bazaar sólo parece ser un producto de nicho: en 2014, los dos populares usuarios de Bazaar, GNU Emacs y Bugzilla, se cambiaron a Git porque el desarrollo ya no avanzaba: el desarrollador principal había dejado Canonical poco antes. El últimoLiberares de 2016, desde entonces solo han aparecido algunas publicaciones aquí y allá. Bazaar puede seguir siendo interesante para proyectos más pequeños que necesitan trabajar con otras herramientas VCS, pero ya no podemos recomendarlo.

Fósil

Por una vez, Fossil no es de 2005, sino de 2006: un buen momento para VCS. Fossil está diseñado explícitamente para el desarrollo de SQLite y también almacena datos en un SQLite interno.Base de datos. Esa es una gran diferencia con el enfoque de archivos de Git. Aunque Fossil también es un sistema distribuido, funciona con un repositorio central donde se reúne todo el trabajo de todos los desarrolladores.

Con Git, por otro lado, cada desarrollador trabaja con sus propias ramas privadas, que quizás nunca sean vistas por nadie más que el propio desarrollador. Fossil adopta un enfoque mucho más centralizado, ya que SQLite es esencialmente mantenido por solo tres personas, mientras que el kernel de Linux es alimentado por miles de desarrolladores a través de Git.

En cuanto a las funciones, Fossil definitivamente se destaca porque, además del VCS real, también incluye un sistema de tickets, wiki, documentación y foro. Y muy importante: un servidor web integrado hace que crear un sitio web para desarrolladores sea mucho más fácil que, por ejemplo, con Git. Con Git, es necesario configurar todo tipo de herramientas y configuraciones, lo que puede llevar horas y días, con Fossil esto puede ser hecho automáticamente en cuestión de minutos.

Pero Fossil también puede ganar puntos cuando se trata de versionar. Por un lado, Fossil es una única herramienta con muchas opciones y operaciones complejas, mientras que Git consta de muchas herramientas pequeñas, que en caso de duda deben ser combinadas "correctamente" por el propio usuario. Por otro lado, también se considera que Fossil es más amigable para principiantes que Git.

Conclusión

Al final, probablemente sea una cuestión de organización, ya sea que el enfoque completamente distribuido de Git o enfoques más centralizados como Fossil o Subversion sean más adecuados. Al observar las revisiones generales, uno podría llegar a la conclusión de que Git es de hecho el (aparentemente) líder indiscutible del mercado, más gracias a GitHub. Para muchos desarrolladores, Git parece ser principalmente una herramienta anidada para nerds, flexible pero engorrosa de usar y propensa a errores.

A otros no les gusta la naturaleza completamente distribuida, ya que, por supuesto, las sucursales privadas y el trabajo fuera de línea pueden crear rápidamente un caos en el código base, que luego primero debe resolverse nuevamente. Sin embargo, si está dispuesto a trabajar intensamente con Git, a largo plazo dispondrá de una herramienta extremadamente rápida que podrá utilizar para hacer prácticamente cualquier cosa, incluso con la ayuda de terceros (por ejemplo, derechos de acceso).

En cualquier caso, una cosa está clara: cuantos más "profesionales" trabajen en el proyecto, por ejemplo, no desarrolladores en un proyecto de documentación, más problemático será Git. Por otro lado, cualquiera que escriba programas completos en Python El papel en blanco tampoco debería tener problemas con Git. Mercurial parece una buena alternativa, quedando un poco entre Git y Subversion aquí y allá.

Pero también está claro que cuanto más grandes son los proyectos, mayores son las exigencias en cuanto a detalles, y en los detalles, por ejemplo en los formatos de archivos o en el proceso exacto en caso de conflictos, las herramientas difieren significativamente. No en vano, como se mencionó al principio, el debate es acalorado: muchas cosas en el entorno de VCS simplemente caen en el mundo de la opinión.

(ID:45957867)