Aquí hay una copia de una respuesta que hice de una pregunta duplicada desde entonces eliminada sobre Git vs. SVN (septiembre de 2009).
¿Mejor? Aparte del enlace habitual WhyGitIsBetterThanX , son diferentes:
uno es un VCS central basado en una copia barata para ramas y etiquetas, el otro (Git) es un VCS distribuido basado en un gráfico de revisiones. Ver también Conceptos básicos de VCS .
Esa primera parte generó algunos comentarios mal informados que pretenden que el propósito fundamental de los dos programas (SVN y Git) es el mismo, pero que se han implementado de manera bastante diferente.
Para aclarar la diferencia fundamental entre SVN y Git , permítanme reformular:
SVN es la tercera implementación de un control de revisión : RCS, luego CVS y finalmente SVN administran directorios de datos versionados. SVN ofrece características de VCS (etiquetado y fusión), pero su etiqueta es solo una copia de directorio (como una rama, excepto que no "se supone" que toque nada en un directorio de etiquetas), y su fusión sigue siendo complicada, actualmente basada en meta -datos agregados para recordar lo que ya se ha fusionado.
Git es una gestión de contenido de archivos (una herramienta hecha para fusionar archivos), desarrollada en un verdadero sistema de control de versiones , basado en un DAG ( gráfico acíclico dirigido ) de commits, donde las ramas son parte del historial de datos (y no un dato en sí mismo). ), y donde las etiquetas son verdaderos metadatos.
Decir que no son "fundamentalmente" diferentes porque puedes lograr lo mismo, resolver el mismo problema, es ... simplemente falso en muchos niveles.
- Si tiene muchas fusiones complejas, hacerlo con SVN será más largo y más propenso a errores. Si tiene que crear muchas ramas, deberá administrarlas y fusionarlas, nuevamente mucho más fácilmente con Git que con SVN, especialmente si hay una gran cantidad de archivos involucrados (la velocidad se vuelve importante)
- Si tiene fusiones parciales para un trabajo en progreso, aprovechará el área de preparación de Git (índice) para comprometer solo lo que necesita, esconder el resto y avanzar en otra rama.
- si necesita desarrollo fuera de línea ... bueno, con Git siempre está "en línea", con su propio repositorio local, sea cual sea el flujo de trabajo que desee seguir con otros repositorios.
Aún así, los comentarios sobre esa vieja respuesta (eliminada) insistieron:
VonC: Usted está confundiendo la diferencia fundamental en la implementación (las diferencias son muy fundamentales, ambos estamos claramente de acuerdo en esto) con la diferencia en el propósito.
Ambas son herramientas utilizadas para el mismo propósito: esta es la razón por la cual muchos equipos que anteriormente usaron SVN han podido deshacerse con éxito en favor de Git.
Si no resolvieran el mismo problema, esta sustituibilidad no existiría.
, a lo que respondí:
"sustituibilidad" ... término interesante ( utilizado en la programación de computadoras ).
Por supuesto, Git no es un subtipo de SVN.
Puede lograr las mismas características técnicas (etiqueta, ramificación, fusión) con ambos, pero Git no se interpone en su camino y le permite concentrarse en el contenido de los archivos , sin pensar en la herramienta en sí.
Ciertamente no puede (siempre) simplemente reemplazar SVN por Git "sin alterar ninguna de las propiedades deseables de ese programa (corrección, tarea realizada, ...)" (que es una referencia a la definición de sustituibilidad mencionada anteriormente ):
- Una es una herramienta de revisión extendida, la otra un verdadero sistema de control de versiones.
- Uno es adecuado para proyectos monolíticos pequeños a medianos con flujo de trabajo de fusión simple y (no demasiado) versiones paralelas. SVN es suficiente para ese propósito, y es posible que no necesite todas las funciones de Git.
- El otro permite proyectos de medianos a grandes basados en múltiples componentes ( un repositorio por componente ), con gran cantidad de archivos para fusionar entre múltiples ramas en un flujo de trabajo de fusión complejo, versiones paralelas en ramas, fusiones de retroadaptación, etc. Podrías hacerlo con SVN, pero estás mucho mejor con Git.
SVN simplemente no puede administrar ningún proyecto de ningún tamaño con ningún flujo de trabajo de fusión. Git puede.
Nuevamente, su naturaleza es fundamentalmente diferente (lo que lleva a una implementación diferente, pero ese no es el punto).
Uno ve el control de revisión como directorios y archivos, el otro solo ve el contenido del archivo (¡tanto que los directorios vacíos ni siquiera se registrarán en Git!).
El objetivo final general puede ser el mismo, pero no puede usarlos de la misma manera, ni puede resolver la misma clase de problema (en alcance o complejidad).