¿Por qué es Git mejor que Subversion?

Con Git, puedes hacer prácticamente cualquier cosa sin conexión, porque todo el mundo tiene su propio repositorio.

Hacer ramas y fusionarlas entre ramas es muy fácil.

Incluso si no tiene derechos de confirmación para un proyecto, todavía puede tener su propio repositorio en línea y publicar "solicitudes push" para sus parches. Todos los que les gusten tus parches pueden incorporarlos a su proyecto, incluidos los mantenedores oficiales.

Es trivial bifurcar un proyecto, modificarlo, y aún sigue fusionando 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 ser), 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). Puedes usar cualquier flujo de trabajo que quieras, y Git lo soportará.

Finalmente, hay GitHub , un gran sitio para alojar tus 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 muy hostiles para el usuario
• carece de un buen GUI (como el gran TortoiseSVN)

Otras respuestas han hecho un buen trabajo explicando las características principales de Git (que son geniales). Pero también hay muchas 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 'clean'. SVN necesita desesperadamente este comando, considerando la frecuencia con la que volcará archivos adicionales en su disco.
2. Git tiene el comando 'bisect'. Es bonito.
3. SVN crea .directorios svn en cada uno carpeta (Git solo crea uno.git directory). Cada script que escribas, y cada grep que hagas, necesitará ser escrito para ignorarlos .directorios svn. También necesita un comando completo ("svn export") solo para obtener una copia sana 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 maneras diferentes para que su pago local sea completamente jodido hasta. (por ejemplo, si "svn switch" falla a mitad de camino, o si introduce un comando incorrecto). Y la peor parte es: si alguna vez te encuentras en una situación en la que algunos de tus archivos vienen de un lugar, y algunos de ellos de otro, el "svn status" te dirá que todo es normal. Tendrás que hacer "svn info" en cada archivo/directorio para descubrir lo raras que son las cosas. Si" git status " te dice que las cosas son normales, entonces puedes confiar en que las cosas realmente son normales.
5. Tienes que avísale a SVN cada vez que muevas o elimines algo. Git lo averiguará.
6. Ignorar la semántica es más fácil en Git. Si ignora un patrón (como *.pyc), será ignorado para todos los subdirectorios. (Pero si realmente quieres ignorar algo para un solo directorio, puedes 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 tener configuraciones de ignorar "privadas" (usando archivo .git / info / exclude), que no afectará a nadie más.

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

Brevemente:

• Git rastrea el contenido en lugar de los archivos
• Las ramas son ligerasy fusionarse es fácil, y quiero decir realmente fácil.
• Está distribuido, básicamente cada repositorio es una rama. Es mucho más fácil de desarrollar concurrentemente y en colaboración que con Subversion, en mi opinión. También hace fuera de línea desarrollo posible.
• No impone ningún flujo de trabajo, como se ve en el sitio web vinculado anterior, 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 uno ".git "directorio, en lugar de docenas de".repositorios svn" (nota: Subversion 1.7 y superior ahora usa un único directorio como Git.)
• El área staging es impresionante, te permite ver los cambios que confirmarás, confirmar cambios parciales y hacer varias otras cosas.
• Almacenar es invaluable cuando haces un desarrollo "caótico", o simplemente quieres corregir un error mientras todavía estás trabajando en otra cosa (en una rama diferente).
• Puede reescribir la historia , que es ideal para preparar conjuntos de parches y corregir sus errores (antes de publicar el commits)
• and y un lote más.

Hay algunas desventajas:

• Todavía no hay muchas GUI buenas 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 incluyenTortoiseGit yGitHub para Mac .
• Los checkouts/clones parciales de repositorios no son posibles en este momento (he leído que está en desarrollo). Sin embargo, hay soporte de submódulos. Git 1.7 + soporta checkouts dispersos .
• Podría ser más difícil de aprender, a pesar de que no me pareció 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 simple, Subversion y Git son casi lo mismo. No hay mucha diferencia entre:

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

Y

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Donde Git realmente brilla es ramificando y trabajando con otras personas.

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

Bueno, está distribuido. Los puntos de referencia indican que es considerablemente más rápido (dada su naturaleza distribuida, las operaciones como las diferencias y los registros 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 todavía me sorprende).

Cuando está trabajando en subversion, o en cualquier otro sistema de control de revisiones cliente/servidor, esencialmente crea copias de trabajo en su máquina mediante revisando revisiones. Esto representa una instantánea en el tiempo de cómo es el repositorio. Actualizas tu copia de trabajo a través de actualizaciones, y actualizas el repositorio a través de confirmaciones.

Con un control de versiones distribuido, no tiene una instantánea, sino todo el código base. ¿Quieres hacer una diferencia 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, todavía puede hacer muchas de las operaciones a las que está acostumbrado. En otros words, no solo tienes una instantánea de una revisión dada, sino toda la base de código.

Pensarías que Git ocuparía un montón de espacio en tu disco duro, pero de un par de puntos de referencia que he visto, en realidad toma menos. No me preguntes cómo. Quiero decir, fue construido por Linus, él sabe una cosa o dos sobre sistemas de archivos supongo.

Los puntos principales que me gustan de DVCS son los siguientes:

1. Puedes cometer cosas rotas. No importa porque otras personas no los verán hasta que publiques. El tiempo de publicación es diferente del tiempo de confirmación.
2. Debido a esto puedes comprometerte más a menudo.
3. Puede combinar funcionalidad completa. Esta funcionalidad tendrá su propia rama. Todas las confirmaciones de esta rama estarán relacionadas con esta funcionalidad. Usted puede hacerlo con un CVCS sin embargo con DVCS su el predeterminado.
4. Puede buscar en su historial (buscar cuando una función cambió )
5. Puede deshacer un pull si alguien arruina el repositorio principal, no necesita corregir los errores. Sólo limpia la fusión.
6. Cuando necesite un control de código fuente en cualquier directorio, haga : git init . y puedes comprometer, deshacer cambios, etc...
7. Es rápido (incluso en Windows )

La razón principal de un proyecto relativamente grande es la mejora de la comunicación creada por el punto 3. Otros son agradables bonos.

Lo gracioso es: Alojo proyectos en repositorios de Subversion, pero accedo a ellos a través del comando Git Clone.

Por favor lee Desarrolla con Git en un Proyecto de Código de Google

Aunque Google Code habla de forma nativa Subversion, puede usar fácilmente Git durante el desarrollo. Buscando " git svn " sugiere que esta práctica es y nosotros también os animamos para experimentar con él.

Usar Git en un repositorio Svn me da beneficios:

1. puedo trabajar distribuido en varios máquinas para la fabricación y extracción de y a ellos
2. Tengo un central backup/public repositorio svn para que otros lo comprueben
3. Y son libres de usar Git para su propio

Todas las respuestas aquí son como se esperaba, centrado en el programador, sin embargo, ¿qué sucede si su empresa utiliza el control de revisión fuera del código fuente? Hay un montón de documentos que no son código fuente que se benefician del control de versiones, y deben 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 esto en mente, compare la facilidad de uso, tanto en herramientas de cliente como en entrenamiento, entre Subversion y git. Me no se puede ver un escenario donde cualquier sistema de control de revisiones distribuido va a ser más fácil de usar o explicar a un no programador. Me encantaría ser probado equivocado, porque entonces sería capaz de evaluar git y realmente tener la esperanza de que sea aceptado por personas que necesitan control de versiones que no son programadores.

Incluso entonces, si la dirección me preguntara por qué deberíamos pasar de un sistema de control de revisiones centralizado a un sistema de control de revisiones distribuido, sería difícil dar una respuesta honesta, porque no lo necesito.

Descargo de responsabilidad: Me interesé en Subversion desde el principio (alrededor de la v0.29), así que obviamente estoy sesgado, pero las compañías para las que he trabajado desde ese momento se están beneficiando de mi entusiasmo porque he alentado y apoyado su uso. Sospecho que esto es lo que sucede con la mayoría de las empresas de software. Con tantos programadores que se suben al carro de git, me pregunto cuántas compañías se perderán los beneficios de usar el control de versiones fuera del código fuente. Incluso si tenga 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.

Subversion sigue siendo un sistema de control de versiones mucho más utilizado, lo que significa que tiene 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 o peor que Subversion, es diferente.

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

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

David Richards WANdisco Blog 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 basura. 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 ingenieros de software sénior exclusivamente. Eso está bien, pero no es como piensa el resto del mercado, y estoy feliz de demostrarlo: GIT, al final look tenía menos del tres por ciento del mercado, mientras que Subversion tiene en la región de cinco millones de usuarios y alrededor de la mitad del mercado general.

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

Git también facilita la ramificación y la fusión. Subversion 1.5 acaba de añadir el seguimiento de fusión, pero Git es aún mejor. Con Git ramificación es muy rápido y barato. 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.

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

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

Si fueran solo 2 personas, diría que git también es más fácil, porque puedes simplemente empujar y tirar entre sí.

Una vez que se llega más allá de eso, sin embargo, yo iría por subversion, porque en ese punto necesita configurar un servidor o ubicación' dedicado'.

Puedes hacer esto tan bien con git como con SVN, pero los beneficios de git se ven superados por la necesidad de hacer 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 tanto.

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

Easy Git tiene una buena página que compara el uso real de Git y SVN que le dará una idea de lo 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 ligero sobre Git.)

Git y DVCS en general son excelentes para desarrolladores que hacen mucho código independientemente unos de otros porque cada uno tiene su propia rama. Si necesitas un cambio de otra persona, sin embargo, ella tiene que comprometerse con su repositorio local y luego debe empujar ese conjunto de cambios a usted o usted debe tirarlo de ella.

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

Todo esto se puede abordar con procesos humanos, por supuesto; DVCS acaba de romper algo que fue arreglado por el control de versiones centralizado con el fin de proporcionar algunas nuevas comodidades.

Me gusta Git porque realmente ayuda a la comunicación de desarrollador a desarrollador en un equipo mediano a grande. Como un 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ías en 5 desarrolladores y solo extraes códigos de su repositorio. Cada uno de esos desarrolladores tiene su propia red de confianza desde donde extraen los códigos. Así el el desarrollo se basa en ese tejido de confianza de los desarrolladores donde la responsabilidad del código es compartida entre la comunidad de desarrollo.

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

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

1) La capacidad de hacer confirmaciones selectivas (por ejemplo, git add --patch). Si tu directorio de trabajo contiene varios cambios que no son parte del mismo cambio lógico, Git hace que sea muy fácil hacer 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 así irrevocable. Esto limita en gran medida la capacidad del desarrollador para "comprometerse temprano, comprometerse a menudo".

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

Creo que Subversion está bien.. hasta que empieces a fusionarte.. o haciendo algo complicado.. o hacer cualquier cosa que Subversion crea que es complicado (como hacer consultas para averiguar qué ramas se ensucian con un archivo en particular, de dónde proviene realmente un cambio , detectar copy&pastes, 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 puede trabajar sin conexión también, todavía no hay duda para mí en cuál invertir mi tiempo de aprendizaje).

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

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

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

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

Y en cuanto al soporte de herramientas de Windows, TortoiseGit maneja muy bien los conceptos básicos, pero aún así prefiero la línea de comandos a menos que quiera ver el registro. Me gusta mucho la forma en que Tortoise{Git / SVN} ayuda al leer los registros de confirmación.

Esta es la pregunta equivocada. Es muy fácil centrarse en las verrugas de git y formular un argumento sobre por qué subversion es aparentemente mejor, al menos para algunos casos de uso. El hecho de que git fue diseñado originalmente como un conjunto de construcción de control de versiones de bajo nivel y tiene una interfaz barroca orientada a desarrolladores de linux hace que sea más fácil para the holy wars ganar tracción y legitimidad percibida. Los defensores de Git golpean el tambor con millones de ventajas de flujo de trabajo, que los chicos de svn proclame innecesario. Muy pronto todo el debate se enmarca como centralizado vs distribuido, lo que sirve a los intereses de la comunidad de herramientas svn de la empresa. Estas empresas, que normalmente publican los artículos más convincentes sobre la superioridad de subversion en la empresa, dependen de la inseguridad percibida de git y de la preparación empresarial de svn para el éxito a largo plazo de sus productos.

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

Mientras que puede tomar git y construir un reemplazo centralizado de subversion con bastante facilidad, a pesar de estar alrededor por más del doble de tiempo que svn nunca ha sido capaz de obtener incluso el seguimiento básico de fusión trabajando tan bien 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 iguales a los directorios. No se por qué se fueron de esta manera originalmente, ciertamente hace que los pagos parciales sean muy simples. Desafortunadamente, también hace que sea imposible rastrear historia correctamente. Ahora, obviamente, se supone que debe usar las convenciones de diseño del repositorio subversion para separar las ramas de los directorios regulares, y svn usa algunas heurísticas para hacer que las cosas funcionen para los casos de uso diarios. Pero todo esto es solo un papeleo sobre una muy pobre y limitante decisión de diseño de bajo nivel. Ser capaz de hacer un diff en cuanto a repositorios (en lugar de un diff en cuanto a directorios) es una funcionalidad básica y crítica para un sistema de control de versiones, y simplifica enormemente los aspectos internos, haciéndolo es posible crear funciones más inteligentes y útiles. Se puede ver en la cantidad de esfuerzo que se ha puesto en extender subversion, y sin embargo, lo lejos que está de la cosecha actual de VCSE modernos en términos de operaciones fundamentales como la resolución de fusión.

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 nuevas razas de VCSE que han aprendido de los errores de RCS y CVS; es una imposibilidad técnica a menos que retool el modelo de repositorio desde cero, pero entonces no sería realmente svn ¿verdad? Independientemente de lo mucho que piense que no tiene las capacidades de un VCS moderno, su ignorancia no lo protegerá de las trampas de Subversion, muchas de las cuales son situaciones que son 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 es con svn, ciertamente nunca diría tal opinión sobre win-vs-linux o emacs-vs-vi, pero en este caso es tan clara, y el control de código fuente es una herramienta tan fundamental en el arsenal del desarrollador, que siento que debe ser declarado inequívocamente. Independientemente del requisito de usar svn por razones de organización, imploro a todos los usuarios de svn que no dejen que su mente lógica construya una falsa creencia de que las VCSE más modernas solo son útiles para grandes proyectos de código abierto. Independientemente de la naturaleza de tu trabajo de desarrollo, si eres un programador, serás un programador más efectivo si aprendes a usar VCSes mejor diseñados, ya sea Git, Mercurial, Darcs o muchos otros.

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 GUI excelentes y el soporte para la integración de SVN es grande.

Con Git se obtiene 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 sin conexión y solo enviar los cambios de vez en cuando al repositorio remoto. Pero Git es más complejo y tiene un curva de aprendizaje más pronunciada. Me encontré en la primera vez comprometiéndome con ramas incorrectas, creando ramas indirectamente o recibiendo mensajes de error con poca información sobre el error y donde debo buscar con Google para obtener mejores informaciones. Algunas cosas fáciles como la sustitución de marcadores (Id Id)) no funciona, pero GIT tiene un mecanismo de filtrado y gancho muy flexible para combinar los propios scripts y así obtener todas las cosas que necesita y más, pero necesita más tiempo y lectura de la documentación ;)

Si trabaja principalmente sin conexión con su repositorio local, no tiene copia de seguridad si se pierde algo en su máquina local. Con SVN está trabajando principalmente con un repositorio remoto que también es al mismo tiempo 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.

¿ Es mejor Git que SVN? Desarrollador que solo necesita un poco de historial de versiones y un mecanismo de copia de seguridad tienen una vida buena y fácil con SVN. Los desarrolladores que trabajan a menudo con ramas, probando más versiones al mismo tiempo o trabajando en su mayoría sin conexión pueden beneficiarse de las características de Git. Hay algunas características muy útiles como el almacenamiento no encontrado con SVN que puede hacer la vida más fácil. Pero por otro lado no todas las personas necesitarán todas las características. Así que no puedo ver a los muertos de SVN.

Git necesita una mejor documentación y el error la presentación de informes debe ser más útil. También las GUI útiles existentes son solo raras veces. 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 es oficial y no hay un sitio de actualización oficial (solo un sitio de actualización externo con compilaciones periódicas desde el tronco http://www.jgit.org/updates ) Así que la forma más preferida de usar Git en estos días es la línea de comandos.

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 pros y contras de los sistemas de control de versiones más populares. Una lectura muy interesante.
Los artículos se pueden encontrar en su blog, www.ericsink.com:

• Leer las diferencias

• Git es la C de las Herramientas de Control de Versiones

• Sobre la falta de respeto de Git por la inmutabilidad y las Mejores Prácticas para un DVCS

• DVCS y DAG, Parte 1

• DVCS y Además, Parte 2

• DVCS y Seguimiento de Errores

• Historia de fusión, DAGs y Darcs

• ¿Por Qué Git es tan Rápido?

• Mercurial, Subversion y Wesley Snipes

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

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

Creo que es bastante seguro decir que entre los desarrolladores, el argumento SVN Vs. Git ha estado furioso desde hace algún tiempo, con todos teniendo su propia opinión sobre cuál es mejor. Esto incluso se planteó en las preguntas durante nuestro Seminario Web sobre Subversion en 2010 y más allá.

Hyrum Wright, nuestro Director de Código Abierto y el Presidente de la Corporación Subversion habla sobre el diferencias entre Subversion y Git, junto con otros Sistemas de Control de Versiones Distribuidas (DVCS).

También habla de 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.

Ten un vistazo de su video y háganos saber lo que piensas, ya sea comentando en este blog, o mediante la publicación en nuestros foros. El registro es simple y solo tomará un momento!

Git en Windows está bastante bien soportado ahora.

Echa un vistazo a GitExtensions = http://code.google.com/p/gitextensions /

Y el manual para una mejor experiencia Git de Windows.

He estado viviendo en Git land últimamente, y me gusta para proyectos personales, pero no sería capaz de cambiar los proyectos de trabajo a él todavía desde Subversion dado el cambio en el pensamiento del personal requerido, sin beneficios urgentes. Además, el proyecto más grande que ejecutamos internamente es extremadamente dependiente de svn:externals que, por lo que he visto hasta ahora, no funciona tan bien y sin problemas en Git.

Primero, el control de versiones simultáneo parece un problema fácil de resolver. No lo es en absoluto. Por cierto...

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

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

Por qué creo que Subversion es mejor que Git (al menos para los proyectos en los que trabajo), principalmente debido a su usabilidad y flujo de trabajo más simple:

Http://www.databasesandlife.com/why-subversion-is-better-than-git /