¿Por qué es Git mejor que Subversion?


393

He estado usando Subversion durante algunos años y después de usar SourceSafe , me encanta Subversion. Combinado con TortoiseSVN , realmente no puedo imaginar cómo podría ser mejor.

Sin embargo, hay un número creciente de desarrolladores que afirman que Subversion tiene problemas y que deberíamos pasar a la nueva generación de sistemas de control de versiones distribuidos, como Git .

¿Cómo mejora Git en Subversion?

Respuestas:


548

Git no es mejor que Subversion. Pero tampoco es peor. Es diferente.

La diferencia clave es que está descentralizada. Imagine que es un desarrollador en el camino, desarrolla en su computadora portátil y desea tener el control de fuente para poder retroceder 3 horas.

Con Subversion, tiene un problema: el repositorio SVN puede estar en una ubicación que no puede alcanzar (en su empresa, y no tiene Internet en este momento), no puede comprometerse. Si desea hacer una copia de su código, literalmente debe copiarlo / pegarlo.

Con Git, no tienes este problema. Su copia local es un repositorio, y puede comprometerse con ella y obtener todos los beneficios del control de código fuente. Cuando recupera la conectividad con el repositorio principal, puede comprometerse contra él.

Esto se ve bien al principio, pero solo tenga en cuenta la complejidad adicional de este enfoque.

Git parece ser la cosa "nueva, brillante, genial". De ninguna manera es malo (después de todo, hay una razón por la que Linus lo escribió para el desarrollo del Kernel de Linux), pero siento que muchas personas se suben al tren de "Control de fuente distribuida" solo porque es nuevo y está escrito por Linus Torvalds, sin realmente sabiendo por qué / si es mejor.

Subversion tiene problemas, pero también Git, Mercurial, CVS, TFS o lo que sea.

Editar: Entonces, esta respuesta ahora tiene un año y todavía genera muchos votos a favor, por lo que pensé agregar algunas explicaciones más. En el último año desde que escribí esto, Git ha ganado mucho impulso y apoyo, particularmente desde que sitios como GitHub realmente despegaron. Estoy usando Git y Subversion hoy en día y me gustaría compartir algunas ideas personales.

En primer lugar, Git puede ser realmente confuso al principio cuando se trabaja descentralizado. ¿Qué es un control remoto? y ¿Cómo configurar correctamente el repositorio inicial? Hay dos preguntas que surgen al principio, especialmente en comparación con el simple "svnadmin create" de SVN, el "git init" de Git puede tomar los parámetros --bare y --compartido, lo que parece ser la forma "adecuada" de configurar un sistema centralizado. repositorio. Hay razones para esto, pero agrega complejidad. La documentación del comando "checkout" es muy confusa para las personas que cambian: la forma "correcta" parece ser "git clone", mientras que "git checkout" parece cambiar de rama.

Git REALMENTE brilla cuando estás descentralizado. Tengo un servidor en casa y una computadora portátil en el camino, y SVN simplemente no funciona bien aquí. Con SVN, no puedo tener control de fuente local si no estoy conectado al repositorio (Sí, sé sobre SVK o sobre formas de copiar el repositorio). Con Git, ese es el modo predeterminado de todos modos. Sin embargo, es un comando adicional (git commit se compromete localmente, mientras que git push origin master empuja la rama maestra al control remoto llamado "origin").

Como se dijo anteriormente: Git agrega complejidad. Dos modos de crear repositorios, pago versus clonación, confirmación vs. inserción ... Debe saber qué comandos funcionan localmente y cuáles funcionan con "el servidor" (supongo que a la mayoría de la gente todavía le gusta un "repositorio maestro" central )

Además, las herramientas siguen siendo insuficientes, al menos en Windows. Sí, hay un complemento de Visual Studio, pero todavía uso git bash con msysgit.

SVN tiene la ventaja de que es MUCHO más fácil de aprender: existe su repositorio, todos los cambios hacia él, si sabe cómo crear, confirmar y pagar y está listo para comenzar y puede recoger cosas como ramificación, actualización, etc. más adelante en.

Git tiene la ventaja de que es MUCHO más adecuado si algunos desarrolladores no siempre están conectados al repositorio maestro. Además, es mucho más rápido que SVN. Y por lo que escuché, el soporte de ramificación y fusión es mucho mejor (lo cual es de esperar, ya que estas son las razones principales por las que fue escrito).

Esto también explica por qué gana tanto revuelo en Internet, ya que Git es perfectamente adecuado para proyectos de código abierto: simplemente bifurca, confirma tus cambios en tu propia bifurcación y luego pide al encargado del proyecto original que extraiga tus cambios. Con Git, esto simplemente funciona. Realmente, pruébalo en Github, es mágico.

Lo que también veo son puentes Git-SVN: el repositorio central es un repositorio de Subversion, pero los desarrolladores trabajan localmente con Git y el puente empuja sus cambios a SVN.

Pero incluso con esta larga adición, aún mantengo mi mensaje central: Git no es mejor ni peor, es simplemente diferente. Si tiene la necesidad de "Control de fuente fuera de línea" y la voluntad de pasar un tiempo extra aprendiéndolo, es fantástico. Pero si tiene un control de origen estrictamente centralizado y / o tiene dificultades para introducir el control de origen en primer lugar porque sus compañeros de trabajo no están interesados, entonces la simplicidad y las excelentes herramientas (al menos en Windows) de SVN brillan.


70
Un Ferrari no es mejor que un Hyundai. Pero tampoco es peor. Es diferente. (¿Qué? No me mires de esta manera ... ¿He dicho algo mal?)
FDCastel

219
No, no lo hiciste. Un Ferrari no es práctico, caro, tiene sed y no lo mejorará de A a B si vive en una ciudad como Nueva York o París; preferiría un Hyundai para muchos lugares, también porque un rasguño es mucho menos grave. Pero para cada uno lo suyo: un Ferrari tiene (muy pocas) ventajas también ...
Michael Stum

50
La distribución no es la única diferencia entre Subversion y Git. Tampoco agrega ninguna complejidad a menos que use múltiples repositorios. Hay muchas ventajas de usar Git en lugar de Subversion, pero solo algunas desventajas (en su mayoría insignificantes). Git se usa porque es bueno, no brillante.
sebnow

66
Mis experiencias con git no son exactamente una "revelación que cambia la vida". Considero que es una gran herramienta cuando funciona, cuando no funciona, se siente sin pulir. No me impresionó demasiado depurar cosas como la pregunta 1052882, y aunque eso es claramente un problema RTFM: considero que git (y cualquier otra vcs distribuida) es más complicado que los centralizados, y consideraría usarlo en entornos centralizados . Pero, de nuevo, soy principalmente un desarrollador de Windows, y las herramientas aún son inmaduras en Windows en comparación con SVN.
Michael Stum

55
Solo analiza el aspecto de distribución en la comparación. Te diré por qué. Porque solo quieres compartir el código. Git y SVN son más que eso, ¿alguna vez has etiquetado, ramificado, fusionado, resuelto conflictos, copiar parches entre ramas? Creo que su análisis es solo defectuoso. En esos aspectos, git es una herramienta MUCHO poderosa. Sin mencionar las cosas que git puede y SVN no puede, como aplastar, disecar, enmendar, rebasar, recoger cerezas y muchas cosas más.
mschonaker

145

Con Git, puedes hacer prácticamente cualquier cosa sin conexión, porque todos tienen su propio repositorio.

Hacer ramas y fusionarse entre ramas es realmente fácil.

Incluso si no tiene derechos de compromiso para un proyecto, puede tener su propio repositorio en línea y publicar "solicitudes push" para sus parches. Todos los que quieran sus parches pueden incluirlos en su proyecto, incluidos los encargados de mantenimiento oficiales.

Es trivial bifurcar un proyecto, modificarlo y seguir fusionándose en las correcciones de errores de la rama HEAD.

Git funciona para los desarrolladores del kernel de Linux. Eso significa que es realmente rápido (tiene que serlo) y escala a miles de contribuyentes. Git también usa menos espacio (hasta 30 veces menos espacio para el repositorio de Mozilla).

Git es muy flexible, muy TIMTOWTDI (Hay más de una forma de hacerlo). Puede usar el flujo de trabajo que desee y Git lo admitirá.

Finalmente, está GitHub , un gran sitio para alojar sus repositorios Git.

Inconvenientes de Git:

  • es mucho más difícil de aprender, porque Git tiene más conceptos y más comandos.
  • las revisiones no tienen números de versión como en subversion
  • muchos comandos de Git son crípticos y los mensajes de error son poco amigables para el usuario
  • carece de una buena GUI (como el gran TortoiseSVN )

31
Aunque aprender todo Git sería mucho más difícil, los conceptos básicos son casi idénticos. El alcance del aprendizaje no es realmente tan empinado hasta que entras en las cosas más avanzadas, que SVN simplemente no es capaz de todos modos.
sebnow

10
+1 para mí Creo que muchos desarrolladores olvidan que a git le falta algo como TortoiseSVN, y que no solo los desarrolladores usan el control de versiones. Me estremezco ante la idea de tener que explicar (y apoyar) el control de versión distribuido a nuestros no desarrolladores que usan SVN | TortoiseSVN!
si618

77
Otra desventaja: debe tener una copia completa del repositorio, no puede trabajar en parciales (lo que importa si tiene grandes, como muchas empresas)
gbjbaanb

3
Me encanta git, pero me llevó unos seis meses de uso diario para usarlo realmente de manera efectiva. Dicho esto, uso una combinación de git shell (símbolo del sistema) de msysgit, git gui y gitk de msysgit y TortoiseGit. Creo que TortoiseGit es genial, pero no entiendo por qué más personas no lo usan. Sé que los mantenedores de msysgit detestan a TortoiseGit por varias razones, algunas de ellas ideológicas, y eso puede tener algo que ver con eso. ¡TortoiseGit es un secreto bien guardado!
Jim Raden el

2
Estoy de acuerdo. Yo uso SVN y GIT (desde hace unos 6 meses). Sinceramente, amo mucho más a Git que a SVN. Solo toma tiempo aprenderlo. El mayor salto para mí (en el momento en que vi la luz: P) fue cuando finalmente me di cuenta de que tenía que dejar de intentar usar GIT de la forma en que funcionaba SVN. Entonces todo cayó en su lugar;)
Blizz

110

Otras respuestas han hecho un buen trabajo al explicar las características principales de Git (que son geniales). Pero también hay tantas pequeñas formas en que Git se comporta mejor y ayuda a mantener mi vida más sana. Estas son algunas de las pequeñas cosas:

  1. Git tiene un comando 'limpio'. SVN necesita desesperadamente este comando, considerando la frecuencia con la que volcará archivos adicionales en su disco.
  2. Git tiene el comando 'bisecar'. Es agradable.
  3. SVN crea directorios .svn en cada carpeta (Git solo crea un directorio .git). Cada script que escriba, y cada grep que haga, deberá escribirse para ignorar estos directorios .svn. También necesita un comando completo ("svn export") solo para obtener una copia sensata de sus archivos.
  4. En SVN, cada archivo y carpeta puede provenir de una revisión o rama diferente. Al principio, suena bien tener esta libertad. Pero lo que esto realmente significa es que hay un millón de formas diferentes para que su pago local se arruine por completo. (por ejemplo, si "svn switch" falla a la mitad, o si ingresa un comando incorrecto). Y la peor parte es: si alguna vez se encuentra en una situación en la que algunos de sus archivos provienen de un lugar, y algunos de ellos de otro, el "estado de svn" le dirá que todo es normal. Tendrá que hacer "información de svn" en cada archivo / directorio para descubrir cuán extrañas son las cosas. Si el "estado de git" le dice que las cosas son normales, entonces puede confiar en que las cosas realmente son normales.
  5. Tienes que decirle a SVN cada vez que muevas o elimines algo. Git lo resolverá.
  6. Ignorar la semántica es más fácil en Git. Si ignora un patrón (como * .pyc), se ignorará para todos los subdirectorios. (Pero si realmente quiere ignorar algo para un solo directorio, puede hacerlo). Con SVN, parece que no hay una manera fácil de ignorar un patrón en todos los subdirectorios.
  7. Otro elemento que implica ignorar archivos. Git hace posible que se ignore la configuración "privada" (usando el archivo .git / info / exclude), que no afectará a nadie más.

2
Anuncio. 7. Con git moderno también puede hacer que la configuración de ignorar "privada" por usuario mediante el uso de la variable de configuración core.excludesFile en ~ .gitignore (consulte man git-config).
Jakub Narębski

3
Re # 5: Si bien esto es normalmente cierto, a veces Git lo arruina. Al menos con Subversion, los problemas debidos a mover o eliminar son casi siempre un PEBKAC. Si bien es bueno tener un seguimiento automático de mover / eliminar, al menos agradecería la capacidad de indicar explícitamente lo que estoy haciendo a los archivos en el repositorio, incluso si no necesito usarlo.
Chris Charabaruk

8
@ Chris: Puedes hacerlo explícitamente: git mvy git rm.
R. Martinho Fernandes

2
También me gustaría ver la opción de un único directorio .svn por copia de trabajo, pero para el registro: Para # 3: La mayoría de las herramientas (por defecto) ignorarán los directorios .svn. Para el n. ° 6: puede establecer propiedades de forma recursiva.
si618

66
3: el directorio "un único .svn" estará aquí con SVN 1.7 cuando se implemente WC-NG. 1: Para obtener la limpieza de SVN, 'exporta' en la parte superior de su WC. 5: no es tan fácil, si cambia el nombre de un archivo, git lo reconoce y mantiene el historial, ¿o lo trata como un agregado y borrado en el directorio? 6/7: svn tiene ignoraciones globales por configuración de cliente de usuario.
gbjbaanb

56

" Por qué Git es mejor que X " describe los diversos pros y contras de Git frente a otros SCM.

Brevemente:

  • Git rastrea contenido en lugar de archivos
  • Las ramas son livianas y la fusión es fácil , y quiero decir realmente fácil .
  • Se distribuye, básicamente cada repositorio es una rama. En mi opinión, es mucho más fácil desarrollarse simultáneamente y en colaboración que con Subversion. También hace posible el desarrollo fuera de línea .
  • No impone ningún flujo de trabajo , como se ve en el sitio web vinculado anteriormente , hay muchos flujos de trabajo posibles con Git. Un flujo de trabajo de estilo Subversion se imita fácilmente.
  • Los repositorios de Git son mucho más pequeños en tamaño de archivo que los repositorios de Subversion. Solo hay un directorio ".git", a diferencia de docenas de repositorios ".svn" (nota Subversion 1.7 y superior ahora usa un solo directorio como Git).
  • El área de preparación es impresionante, le permite ver los cambios que realizará, realizar cambios parciales y hacer otras cosas.
  • El escondite es invaluable cuando haces un desarrollo "caótico", o simplemente quieres arreglar un error mientras todavía estás trabajando en otra cosa (en una rama diferente).
  • Puede reescribir el historial , que es excelente para preparar conjuntos de parches y corregir sus errores ( antes de publicar las confirmaciones)
  • ... y mucho más.

Hay algunas desventajas:

  • Todavía no hay muchas buenas GUI para ello. Es nuevo y Subversion ha existido durante mucho más tiempo, por lo que esto es natural ya que hay algunas interfaces en desarrollo. Algunos buenos incluyen TortoiseGit y GitHub para Mac .
  • Pagos parciales / clones de repositorios no son posibles en este momento (leí que está en desarrollo). Sin embargo, hay soporte para submódulos. Git 1.7+ admite pagos escasos .
  • Puede ser más difícil de aprender, aunque no encontré que este fuera el caso (hace aproximadamente un año). Git ha mejorado recientemente su interfaz y es bastante fácil de usar.

En el uso más simplista, Subversion y Git son más o menos lo mismo. No hay mucha diferencia entre:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

y

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Donde Git realmente brilla es ramificarse y trabajar con otras personas.


8
Dices que GIT rastrea contenido en lugar de archivos. Descubrí que SVN también hace eso: acabo de hacer cambios en un archivo y lo guardé. SVN mostró el archivo como rojo (modificado). Luego hice deshacer en el editor y lo guardé de nuevo. Luego, SVN actualizó el estado a verde (no se modificó) incluso si se modificó el archivo (fecha de cambio más reciente) pero SVN reconoció que el contenido no se modificó del original.
temor

¿svn rastrea los cambios entre archivos?
Seun Osewa

12
@awe, eso se llama seguimiento de archivos. intente cambiar el nombre del archivo o moverlo a otro lugar manualmente [mismo contenido, nuevo archivo (debido a la nueva ruta / nombre)]: ¿sabrá SVN que ese es el mismo archivo y retendrá las innumerables revisiones anteriores que le hizo? no supongo que no.
Filip Dupanović


54

Google Tech Talk: Linus Torvalds en git

http://www.youtube.com/watch?v=4XpnKHJAok8

La página de comparación de Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion


12
La charla de Linus es divertida de ver. Destroza brutalmente sistemas de control de versiones centralizados como Subversion y CVS. Sin embargo, la charla de Randal Schwartz en youtube.com/watch?v=8dhZ9BXQgc4 es más constructiva, más informativa y más convincente.
Bendin

2
Este también es bastante bueno. Es de uno de los git commiters y explica muchas características avanzadas como dividir grandes commits en pequeños. youtube.com/watch?v=j45cs5_nY2k
schoetbi

Disfruto el video de Linus Torvalds, pero él implica que git está distribuido, no centralizado, y esto es simplemente incorrecto. Se puede utilizar de forma distribuida, O de forma centralizada. Puede tener un repositorio central con el que todos se comprometan, al igual que en SVN. Es solo que no tienes que hacerlo de esa manera.
MatrixFrog

@MatrixForog: Creo que en este caso, "descentralizado" no es lo contrario de "centralizado", sino realmente un superconjunto. Es como "móvil" e "inmóvil", solo porque algo es "móvil" no me parece que no pueda quedarse quieto.
Tikhon Jelvis

26

Bueno, está distribuido. Los puntos de referencia indican que es considerablemente más rápido (dada su naturaleza distribuida, las operaciones como diffs y logs son todas locales, por lo que, por supuesto, es increíblemente más rápido en este caso), y las carpetas de trabajo son más pequeñas (lo que aún me sorprende).

Cuando está trabajando en Subversion, o en cualquier otro sistema de control de revisión de cliente / servidor, esencialmente crea copias de trabajo en su máquina al revisar las revisiones. Esto representa una instantánea en el tiempo del aspecto del repositorio. Actualiza su copia de trabajo mediante actualizaciones, y actualiza el repositorio mediante confirmaciones.

Con un control de versión distribuido, no tiene una instantánea, sino toda la base de código. ¿Quieres hacer un diff con una versión de 3 meses? No hay problema, la versión de 3 meses todavía está en su computadora. Esto no solo significa que las cosas son mucho más rápidas, sino que si está desconectado de su servidor central, aún puede realizar muchas de las operaciones a las que está acostumbrado. En otras palabras, no solo tiene una instantánea de una revisión dada, sino toda la base de código.

Se podría pensar que Git ocuparía un montón de espacio en su disco duro, pero desde un par de puntos de referencia que he visto, en realidad toma menos. No me preguntes cómo. Quiero decir, fue construido por Linus, creo que sabe una o dos cosas sobre los sistemas de archivos.


1
La razón por la cual Git puede ocupar menos espacio en el disco para el repositorio completo que Subversion para el simple pago es que Subversion almacena "copia prístina" para hacer que 'svn diff' (comparación con la última versión) funcione ... y ese repositorio git está comprimido (y deltaificado) )
Jakub Narębski

3
No me sorprende que las "carpetas de trabajo" de git (es decir, repos) sean más pequeñas que svn copias de trabajo porque incluso svn repos son más pequeñas que svn copias de trabajo.
R. Martinho Fernandes

22

Los puntos principales que me gustan de DVCS son aquellos:

  1. Puedes cometer cosas rotas. No importa porque otras personas no los verán hasta que publique. El tiempo de publicación es diferente del tiempo de compromiso.
  2. Debido a esto, puede comprometerse más a menudo.
  3. Puede fusionar funcionalidades completas. Esta funcionalidad tendrá su propia rama. Todos los commits de esta rama estarán relacionados con esta funcionalidad. Puede hacerlo con un CVCS, sin embargo, con DVCS es el valor predeterminado.
  4. Puede buscar su historial (buscar cuándo cambió una función)
  5. Puede deshacer una extracción si alguien arruina el repositorio principal, no necesita corregir los errores. Solo borra la fusión.
  6. Cuando necesite un control de fuente en cualquier directorio, haga: git init. y puedes confirmar, deshacer cambios, etc.
  7. Es rápido (incluso en Windows)

La razón principal de un proyecto relativamente grande es la comunicación mejorada creada por el punto 3. Otros son bonificaciones bonitas.


Creo que el punto # 1 tiene la intención de decir "otras personas no los verán hasta que publique " (o "push").
jackr

+1 "Puedes cometer cosas rotas". es la razón principal por la que estoy considerando cambiar a git desde svn. Siempre odio cuando estoy a medio camino de desarrollar un bloque de código pesado, y no tengo la red de seguridad de VCS (simplemente porque mis modificaciones aún no funcionan, por lo que no tengo permitido comprometerme).
András Szepesházi

15

Lo curioso es: alojo proyectos en Subversion Repos, pero accedo a ellos a través del comando Git Clone.

Lea Desarrollar con Git en un proyecto de código de Google

Aunque Google Code habla Subversion de forma nativa, puede usar Git fácilmente durante el desarrollo. La búsqueda de "git svn" sugiere que esta práctica está muy extendida, y nosotros también lo alentamos a que experimente con ella.

Usar Git en un repositorio Svn me da beneficios:

  1. Puedo trabajar distribuido en varias máquinas, comprometiéndome y tirando de ellas
  2. Tengo un repositorio svn central backup/public para que otros puedan ver
  3. Y son libres de usar Git para su propio

3
esto está un poco desactualizado, el código de google es mercurial, por lo que ya no es necesario este truco
Sam Saffron

@Sam a menos que te guste git y / o no te guste mercurial.
MatrixFrog

11

Todas las respuestas aquí son las esperadas, centradas en el programador, sin embargo, ¿qué sucede si su empresa utiliza el control de revisión fuera del código fuente? Hay muchos documentos que no son código fuente que se benefician del control de versiones, y deberían vivir cerca del código y no en otro CMS. La mayoría de los programadores no trabajan de forma aislada: trabajamos para empresas como parte de un equipo.

Con eso en mente, compare la facilidad de uso, tanto en herramientas como capacitación del cliente, entre Subversion y git. No puedo ver un escenario en el que cualquier sistema de control de revisión distribuido sea más fácil de usar o explicar a un no programador. Me encantaría que me demuestren que estoy equivocado, porque entonces podría evaluar git y tener la esperanza de que sea aceptado por personas que necesitan control de versiones que no son programadores.

Incluso entonces, si la gerencia me pregunta por qué deberíamos pasar de un sistema de control de revisión centralizado a uno distribuido, sería difícil dar una respuesta honesta, porque no la necesitamos.

Descargo de responsabilidad: Me interesé en Subversion desde el principio (alrededor de v0.29), así que obviamente soy parcial, pero las empresas para las que he trabajado desde entonces se están beneficiando de mi entusiasmo porque he alentado y apoyado su uso. Sospecho que así es como sucede con la mayoría de las compañías de software. Con tantos programadores subiéndose al tren de git, me pregunto cuántas empresas se perderán los beneficios de usar el control de versiones fuera del código fuente. Incluso si tiene sistemas separados para diferentes equipos, se está perdiendo algunos de los beneficios, como la integración (unificada) de seguimiento de problemas, al tiempo que aumenta los requisitos de mantenimiento, hardware y capacitación.


En mi humilde opinión, esta es la única razón válida para favorecer SVN. En resumen, es más fácil explicarle a un no programador, es decir, a alguien que esperaba usarlo de forma lineal y evitar escenarios de VC complejos (= reales): conflictos, fusiones de 3 vías, ramas ... Quiero decir, lo haría nunca quiero dejar que el VCS fusione un archivo de presentación de PowerPoint de todos modos ..
inger

2
"La mayoría de los programadores no trabajan de forma aislada" parece sugerir que los contadores / personal de marketing tendrían que usar el mismo repositorio donde se guarda el código fuente. No veo los beneficios de esto; algunas de mis ex compañías querían estandarizar cosas como esas, pero inevitablemente fallaron. Creo que el enfoque simplista puede ser excelente para el gerente, pero una simplificación excesiva para los equipos de programadores, por lo que unificarlos conduce a un mal compromiso.
inger

Para los documentos que van con el software, tiene razón: deben versionarse juntos. Descubrí que esos son mucho menos de lo que la gente piensa inicialmente (terminamos arrojando un gran documento de árbol del repositorio fuente). Además, hay muchas cosas que puede hacer para simplificar los flujos de trabajo de los escritores de tecnología, etc., en caso de que sea un problema (no debería).
inger

2
@inger No creo que pueda decir "esta es la única razón válida", el soporte de herramientas AFAIK para Subversion es muy superior a Git, por ejemplo, TortoiseSVN e integración con Visual Studio y Java IDE como Eclipse. Puede que eso no sea un problema para usted, pero ciertamente lo es para nosotros. No lo mencioné en mi respuesta porque es un tema aparte.
si618

1
@Keyo, sí, es cierto que los no programadores tardarán en obtener Subversion, pero creo que tardarán más con git o Hg. Los Wiki son geniales si se mantienen, pero en mi experiencia es más probable que los desarrolladores mantengan documentos relacionados con el código fuente si están cerca de ese código fuente. Estoy de acuerdo con inger en que no hay tantos documentos que se ajusten a esta categoría, pero ciertamente existen. Es interesante que digas que git / Hg es la mejor herramienta para el trabajo, esa es una declaración general que probablemente no sea cierta para todas las circunstancias, ¿tienen git y Hg una integración tan buena como SVN?
si618

9

Subversion sigue siendo un sistema de control de versiones mucho más utilizado, lo que significa que tiene un mejor soporte de herramientas. Encontrarás complementos SVN maduros para casi cualquier IDE , y hay buenas extensiones de explorador disponibles (como TurtoiseSVN). Aparte de eso, tendré que estar de acuerdo con Michael : Git no es mejor ni peor que Subversion, es diferente.


Pero ahora, después de usar git ampliamente durante un par de años, necesito estar en desacuerdo conmigo mismo: Git es mucho mejor que Subversion. Al menos una vez que superas la sintaxis hostil de Git.
neu242

8

Una de las cosas de SubVersion que me molesta es que coloca su propia carpeta en cada directorio de un proyecto, mientras que git solo coloca una en el directorio raíz. No es que la gran cosa, pero pequeñas cosas como que se suman.

Por supuesto, SubVersion tiene Tortoise, que es [generalmente] muy agradable.


55
los directorios .svn desaparecerán pronto, probablemente con v1.7
gbjbaanb

8

Blog de David Richards WANdisco sobre Subversion / GIT

La aparición de GIT ha traído consigo una raza de fundamentalistas de DVCS, los 'Gitterons', que piensan que cualquier cosa que no sea GIT es una mierda. Los Gitterons parecen pensar que la ingeniería de software ocurre en su propia isla y a menudo olvidan que la mayoría de las organizaciones no emplean exclusivamente ingenieros de software senior. Eso está bien, pero no es lo que piensa el resto del mercado, y estoy feliz de demostrarlo: GIT, en el último vistazo tenía menos del tres por ciento del mercado, mientras que Subversion tiene en la región de cinco millones de usuarios y aproximadamente la mitad de El mercado general.

El problema que vimos fue que los Gitterons estaban disparando (baratos) a Subversion. Tweets como "Subversion es tan [lento / horrible / restrictivo / no huele bien / me mira de manera divertida] y ahora tengo GIT y [todo funciona en mi vida / mi esposa quedó embarazada / tuve una novia después 30 años de intentos / gané seis veces corriendo en la mesa de blackjack]. Te dan la imagen.


1
Tenga en cuenta que David Richards podría ser imparcial: el producto que fabrica se basa en Subversion (o en ideas de Subversion), por lo que sería pro-Subversion y anti-Git.
Jakub Narębski

2
Irónicamente, Git fue creado específicamente porque la ingeniería de software no ocurre en las islas. Esta cita es tonta.
Ben Collins el

Aunque uso git, también estaría muy feliz de trabajar con cualquier DVCS decente como Mercurial, por ejemplo. Se necesita tiempo para que el concepto DVCS gane popularidad y ahora veo que una gran cantidad de proyectos de código abierto se han cambiado a git.
Keyo

Al pintar a los svn detractores como fundamentalistas, David está esquivando el tema fundamental: la arquitectura de subversión es un callejón sin salida. No es que git sea el fin de todo de VCS, tiene sus verrugas para estar seguro, pero git, mercurial, darcs y muchos otros VCS tienen modelos de repositorio fundamentalmente más elegantes. Subversion nunca hará que la fusión funcione porque el directorio == modelo de rama hace que el progreso real sea imposible. Las empresas como David pueden seguir pintando más y más lápiz labial en un cerdo, pero inevitablemente se quedará cada vez más atrás en el estado del arte.
gtd

7

Git también hace que la ramificación y la fusión sean realmente fáciles. Subversion 1.5 acaba de agregar el seguimiento de fusión, pero Git sigue siendo mejor. Con Git la ramificación es muy rápida y barata. Hace que la creación de una rama para cada nueva característica sea más factible. Los repositorios Oh y Git son muy eficientes con el espacio de almacenamiento en comparación con Subversion.


6

Se trata de la facilidad de uso / pasos necesarios para hacer algo.

Si estoy desarrollando un solo proyecto en mi PC / computadora portátil, git es mejor, porque es mucho más fácil de configurar y usar. No necesita un servidor, y no necesita seguir escribiendo las URL del repositorio cuando hace fusiones.

Si solo fueran 2 personas, diría que git también es más fácil, porque solo pueden empujar y tirar unos de otros.

Sin embargo, una vez que vaya más allá de eso, optaría por la subversión, porque en ese punto debe configurar un servidor o ubicación 'dedicado'.

Puede hacer esto tan bien con git como con SVN, pero los beneficios de git se ven compensados ​​por la necesidad de realizar pasos adicionales para sincronizar con un servidor central. En SVN solo te comprometes. En git tienes que git commit, luego git push. El paso adicional se vuelve molesto simplemente porque terminas haciéndolo demasiado.

SVN también tiene el beneficio de mejores herramientas GUI, sin embargo, el ecosistema git parece estar poniéndose al día rápidamente, por lo que no me preocuparía a largo plazo.


11
La separación de comprometerse y publicar en Git es una ventaja de la OMI en lugar de una desventaja.
Jakub Narębski

Ok, entonces, ¿cómo calificaría la "facilidad de uso / pasos necesarios para hacer algo" para SVN cuando: - crea una rama de tema para experimentación - fusiona esta rama en otra rama - divide las cosas editadas en un archivo en sus propios commits más pequeños - revisando rápidamente una rama principal para hacer una pequeña corrección, en mi humilde opinión, no veo cómo configurar un servidor SVN es más fácil que configurar su servidor git. Y por qué querría renunciar a todas las ventajas que obtiene de las ramas livianas para no tener que "empujar por separado".
Sam

El argumento de "rama temática para la experimentación" a menudo se presenta a favor de git, pero honestamente, nunca he visto a nadie realmente hacer eso en subversión u otro sistema que no sea DVCS. Tal vez sea un gran problema y todos nos lo estamos perdiendo, pero por lo que he visto, al 99% de los desarrolladores (incluido yo mismo) no nos importan las ramas temáticas porque nunca las usan. - No te puedes perder lo que nunca has tenido :-). Creo que si las personas de DVCS van a presentar "ramas temáticas" como una característica, primero tienen que convencer a todos de que tales cosas son realmente útiles.
Orion Edwards

La "división de cosas editadas en commits más pequeños", nuevamente, es algo que suena bien en teoría. Sin embargo, en los últimos 3 años, he no una vez pensé "Oh, me gustaría poder hacer eso", y yo incluso lucha para llegar a una situación hipotética en la que podría querer la característica ... Una gran parte del GIT / Los defensores de DVCS simplemente dicen "tenemos X y X es increíble" y todos los demás están sentados allí preguntándose por qué necesitarían X
Orion Edwards

6

Easy Git tiene una página agradable que compara el uso real de Git y SVN que le dará una idea de las cosas que Git puede hacer (o hacer más fácilmente) en comparación con SVN. (Técnicamente, esto se basa en Easy Git, que es un envoltorio liviano encima de Git).


5

Git y DVCS en general son excelentes para los desarrolladores que realizan una gran cantidad de codificación independientemente uno del otro porque cada uno tiene su propia rama. Sin embargo, si necesita un cambio de otra persona, ella tiene que comprometerse con su repositorio local y luego debe empujar ese conjunto de cambios hacia usted o usted debe quitárselo.

Mi propio razonamiento también me hace pensar que DVCS hace las cosas más difíciles para el control de calidad y la administración de versiones si haces cosas como versiones centralizadas. Alguien tiene que ser responsable de hacer ese push / pull desde el repositorio de todos los demás, resolver los conflictos que se habrían resuelto en el momento de la confirmación inicial antes, luego hacer la compilación y luego hacer que todos los demás desarrolladores vuelvan a sincronizar sus repositorios.

Todo esto puede abordarse con procesos humanos, por supuesto; DVCS acaba de romper algo que fue corregido por el control de versiones centralizado para proporcionar algunas nuevas comodidades.


1
En realidad, si parece que el kernel de Linux o el proyecto git en sí mismo está administrado, vería que Git es muy bueno para el flujo de trabajo de 'único mantenedor' (o mantenedor + lugartenientes), con un repositorio central por consenso. Y hace que sea fácil cambiar temporalmente a otra persona como mantenedor.
Jakub Narębski

5

Me gusta Git porque realmente ayuda a los desarrolladores de comunicación a desarrolladores en un equipo de mediano a grande. Como sistema de control de versiones distribuido, a través de su sistema push / pull, ayuda a los desarrolladores a crear un ecosistema de código fuente que ayuda a administrar un gran grupo de desarrolladores que trabajan en un solo proyecto.

Por ejemplo, digamos que confía en 5 desarrolladores y solo extrae códigos de su repositorio. Cada uno de esos desarrolladores tiene su propia red de confianza de donde extraen los códigos. Por lo tanto, el desarrollo se basa en ese tejido de confianza de los desarrolladores donde la responsabilidad del código se comparte entre la comunidad de desarrollo.

Por supuesto, hay otros beneficios que se mencionan en otras respuestas aquí.


4

Algunas respuestas han aludido a estas, pero quiero hacer 2 puntos explícitos:

1) La capacidad de realizar confirmaciones selectivas (por ejemplo, git add --patch ). Si su directorio de trabajo contiene múltiples cambios que no son parte del mismo cambio lógico, Git hace que sea muy fácil realizar una confirmación que incluya solo una parte de los cambios. Con Subversion, es difícil.

2) La capacidad de comprometerse sin hacer público el cambio. En Subversion, cualquier commit es inmediatamente público y, por lo tanto, irrevocable. Esto limita enormemente la capacidad del desarrollador de "comprometerse temprano, comprometerse con frecuencia".

Git es más que solo un VCS; También es una herramienta para desarrollar parches. Subversion es simplemente un VCS.


44
Re 1) Si está utilizando TortoiseSVN, AnkhSVN, etc., entonces es muy fácil (trivial) seleccionar qué archivos con cambios para confirmar. Re 2) Si no desea que otros desarrolladores obtengan su código, cree una rama y luego fusione cuando esté listo, no es difícil.
si618

¿irrevocable? Bueno, podría invertir la fusión de la confirmación defectuosa y el repositorio es como era antes. Pero tienes razón, está documentado. ¿Pero esto es bueno o malo? Supongo que depende ...
schoetbi

@schoetbi No, el jefe del repositorio es como era antes. El repositorio en sí ahora contiene dos confirmaciones, mientras que sería bueno si ninguno de ellos estuviera allí. Es un desorden adicional que te ralentiza cuando estás mirando a través de los registros. Por supuesto, esto también puede suceder con git, especialmente si algunos desarrolladores tienen la costumbre de presionar inmediatamente después de comprometerse. Pero es mucho más fácil de evitar en git.
MatrixFrog

4

Creo que Subversion es bien .. hasta que pueda empezar la fusión .. o hacer algo complicado .. o hacer cualquier subversión piensa que es complicado (como hacer consultas para averiguar qué ramas metido con un archivo en particular, cuando un cambio en realidad viene de, la detección de copia y pastas , etc.) ...

No estoy de acuerdo con la respuesta ganadora, diciendo que el principal beneficio de GIT es el trabajo fuera de línea: es ciertamente útil, pero es más como un extra para mi caso de uso. SVK también puede funcionar sin conexión, aún no hay dudas para mí en cuál invertir mi tiempo de aprendizaje

Es solo que es increíblemente potente y rápido y, después de acostumbrarse a los conceptos, es muy útil (sí, en ese sentido: fácil de usar).

Para obtener más detalles sobre una historia de fusión, vea esto: ¿Cómo usar git-svn (o similar) * solo * para ayudar con una fusión de svn?


3

Gracias al hecho de que no necesita comunicarse constantemente con un servidor central, casi todos los comandos se ejecutan en menos de un segundo (obviamente, git push / pull / fetch son más lentos simplemente porque tienen que inicializar las conexiones SSH). La ramificación es mucho más fácil (un comando simple para ramificar, un comando simple para fusionar)


3

Me encanta poder administrar las sucursales locales de mi código fuente en Git sin enturbiar el agua del repositorio central. En muchos casos, verificaré el código del servidor Subversion y ejecutaré un repositorio Git local solo para poder hacer esto. También es genial que inicializar un repositorio Git no contamine el sistema de archivos con un montón de molestas carpetas .svn en todas partes.

Y en lo que respecta al soporte de herramientas de Windows, TortoiseGit maneja los conceptos básicos muy bien, pero todavía prefiero la línea de comando a menos que quiera ver el registro. Realmente me gusta la forma en que Tortoise {Git | SVN} ayuda al leer los registros de confirmación.


3

Esta es la pregunta incorrecta que debe hacerse. Es muy fácil concentrarse en las verrugas de git y formular un argumento sobre por qué la subversión es aparentemente mejor, al menos para algunos casos de uso. El hecho de que git se diseñó originalmente como un conjunto de construcción de control de versiones de bajo nivel y tiene una interfaz barroca orientada al desarrollador de Linux hace que sea más fácil para las guerras santas ganar tracción y percibir legitimidad. Los defensores de Git golpean el tambor con millones de ventajas de flujo de trabajo, que los muchachos proclaman innecesarios. Muy pronto todo el debate se enmarca como centralizado vs distribuido, lo que sirve a los intereses de la comunidad de herramientas empresariales. Estas empresas, que suelen publicar los artículos más convincentes sobre la superioridad de Subversion en la empresa,

Pero aquí está el problema: Subversion es un callejón sin salida arquitectónico .

Mientras que puede tomar git y construir un reemplazo de subversión centralizado con bastante facilidad, a pesar de estar presente por más del doble de tiempo, svn nunca ha sido capaz de lograr que el seguimiento de fusión básico funcione en un lugar tan cercano como lo hace en git. Una razón básica para esto es la decisión de diseño de hacer que las ramas sean lo mismo que los directorios. No sé por qué fueron de esta manera originalmente, ciertamente hace que los pagos parciales sean muy simples. Desafortunadamente, también hace que sea imposible rastrear el historial correctamente. Ahora, obviamente, se supone que debe usar convenciones de diseño de repositorio de subversión para separar las ramas de los directorios normales, y svn usa algunas heurísticas para hacer que las cosas funcionen para los casos de uso diario. Pero todo esto solo está empañando una decisión de diseño de bajo nivel muy pobre y limitante. Ser capaz de hacer una diferencia en el repositorio (en lugar de una diferencia en el directorio) es una funcionalidad básica y crítica para un sistema de control de versiones, y simplifica enormemente las funciones internas, lo que hace posible construir funciones más inteligentes y útiles. Puede ver la cantidad de esfuerzo que se ha dedicado a extender la subversión y, sin embargo, cuán lejos está de la cosecha actual de VCS modernos en términos de operaciones fundamentales como la resolución de fusión.

Ahora, este es mi consejo sincero y agnóstico para cualquiera que todavía crea que Subversion es lo suficientemente bueno para el futuro previsible:

Subversion nunca alcanzará a las razas más nuevas de VCS que han aprendido de los errores de RCS y CVS; es una imposibilidad técnica a menos que reorganicen el modelo de repositorio desde cero, pero entonces realmente no sería svn, ¿verdad? Independientemente de cuánto creas que no tienes las capacidades de un VCS moderno, tu ignorancia no te protegerá de las trampas de la Subversión, muchas de las cuales son situaciones imposibles o fáciles de resolver en otros sistemas.

Es extremadamente raro que la inferioridad técnica de una solución sea tan clara como lo es con svn, ciertamente nunca diría tal opinión sobre win-vs-linux o emacs-vs-vi, pero en este caso es así claro, y el control de código fuente es una herramienta tan fundamental en el arsenal del desarrollador, que creo que debe declararse inequívocamente. Independientemente del requisito de usar svn por razones organizativas, imploro a todos los usuarios de svn que no dejen que su mente lógica construya una falsa creencia de que los VCS más modernos solo son útiles para grandes proyectos de código abierto. Independientemente de la naturaleza de su trabajo de desarrollo, si usted es un programador, será un programador más efectivo si aprende a usar VCS mejor diseñados, ya sea Git, Mercurial, Darcs o muchos otros.


2

Subversion es muy fácil de usar. Nunca he encontrado en los últimos años un problema o que algo no funcione como se esperaba. También hay muchas herramientas excelentes de GUI y el soporte para la integración SVN es grande.

Con Git obtienes un VCS más flexible. Puede usarlo de la misma manera que SVN con un repositorio remoto donde confirma todos los cambios. Pero también puede usarlo principalmente fuera de línea y solo enviar los cambios de vez en cuando al repositorio remoto. Pero Git es más complejo y tiene una curva de aprendizaje más pronunciada. Me encontré por primera vez comprometiéndome con ramas incorrectas, creando ramas indirectamente u obteniendo mensajes de error con poca información sobre el error y dónde debo buscar con Google para obtener mejores informaciones. Algunas cosas fáciles como la sustitución de marcadores ($ Id $) no funcionan, pero GIT tiene un mecanismo de filtrado y conexión muy flexible para fusionar sus propios scripts y así obtener todo lo que necesita y más, pero necesita más tiempo y lectura de la documentación. ;)

Si trabaja principalmente fuera de línea con su repositorio local, no tiene respaldo si algo se pierde en su máquina local. Con SVN, usted está trabajando principalmente con un repositorio remoto que también es la misma vez que su copia de seguridad en otro servidor ... Git puede funcionar de la misma manera, pero este no era el objetivo principal de Linus para tener algo como SVN2. Fue diseñado para los desarrolladores del kernel de Linux y las necesidades de un sistema de control de versiones distribuido.

¿Git es mejor que SVN? Los desarrolladores que solo necesitan un poco de historial de versiones y un mecanismo de respaldo tienen una vida buena y fácil con SVN. Los desarrolladores que trabajan a menudo con sucursales, prueban más versiones al mismo tiempo o trabajan principalmente fuera de línea pueden beneficiarse de las características de Git. Hay algunas características muy útiles como el alijo que no se encuentra con SVN que pueden hacer la vida más fácil. Pero, por otro lado, no todas las personas necesitarán todas las funciones. Entonces no puedo ver a los muertos de SVN.

Git necesita una mejor documentación y el informe de errores debe ser más útil. También las GUI útiles existentes son raramente raras. Esta vez solo he encontrado 1 GUI para Linux con soporte para la mayoría de las características de Git (git-cola). La integración de Eclipse está funcionando pero no se ha lanzado oficialmente y no hay un sitio de actualización oficial (solo algunos sitios de actualización externos con compilaciones periódicas desde el tronco http://www.jgit.org/updates ) Entonces, la forma más preferida de usar Git en estos días Es la línea de comando.


2

Eric Sink de SourceGear escribió una serie de artículos sobre las diferencias entre los sistemas de control de versiones distribuidos y no distribuidos. Compara los pros y los contras de los sistemas de control de versiones más populares. Muy interesante lectura.
Los artículos se pueden encontrar en su blog, www.ericsink.com :


2

Para las personas que buscan una buena GUI de Git, Syntevo SmartGit podría ser una buena solución. Su propietario, pero gratuito para uso no comercial, se ejecuta en Windows / Mac / Linux e incluso es compatible con SVN usando algún tipo de puente git-svn, creo.


1

http://subversion.wandisco.com/component/content/article/1/40.html

Creo que es bastante seguro decir que entre los desarrolladores, el SVN vs. El argumento de Git ha estado furioso durante algún tiempo, y cada uno tiene su propia opinión sobre cuál es mejor. Esto se mencionó incluso en las preguntas durante nuestro seminario web sobre Subversion en 2010 y más allá.

Hyrum Wright, nuestro director de código abierto y presidente de Subversion Corporation, habla sobre las diferencias entre Subversion y Git, junto con otros sistemas de control de versiones distribuidas (DVCS).

También habla sobre los próximos cambios en Subversion, como Working Copy Next Generation (WC-NG), que cree que hará que varios usuarios de Git vuelvan a convertir a Subversion.

Eche un vistazo a su video y cuéntenos su opinión comentando en este blog o publicando en nuestros foros. ¡El registro es simple y solo tomará un momento!


Obviamente sesgado, ya que su herramienta se basa en Subversion. Solo digo.
Jakub Narębski


1

Últimamente he estado viviendo en Git Land, y me gusta para proyectos personales, pero aún no podría cambiarme de proyectos de trabajo desde Subversion dado el cambio en la forma de pensar requerida por el personal, sin ningún beneficio urgente. Además, el proyecto más grande que ejecutamos internamente es extremadamente dependiente de svn: externos que, por lo que he visto hasta ahora, no funcionan tan bien y sin problemas en Git.


1

Primero, el control de versiones concurrentes parece un problema fácil de resolver. No es para nada. De todas formas...

SVN es bastante no intuitivo. Git es aún peor. [especulación sarcástica] Esto podría deberse a que los desarrolladores, a quienes les gustan los problemas difíciles como el control de versiones concurrentes, no tienen mucho interés en hacer una buena interfaz de usuario. [/ especulación sarcástica]

Los partidarios de SVN piensan que no necesitan un sistema distribuido de control de versiones. Yo también pensé eso. Pero ahora que usamos Git exclusivamente, soy un creyente. Ahora el control de versiones funciona para mí Y para el equipo / proyecto en lugar de solo trabajar para el proyecto. Cuando necesito una rama, me ramifico. A veces es una rama que tiene una rama correspondiente en el servidor, y otras no. Sin mencionar todas las otras ventajas que tendré que estudiar (gracias en parte a la falta de UI absurda y arcana que es un sistema de control de versiones moderno).


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.