2009-03-24 30 views
6

Imagina que tienes un amigo por teléfono (no VoIP) que pregunta: "¿Qué tiene de especial Git? Estoy bien usando Subversion". ¿Cuál sería su "argumento de ascensor" para describir la ventaja de usar un DVCS como Git?Paso del elevador para Git a/o DVCS

+0

lo general lanzar los ascensores para 90 nudos de velocidad del aire, entonces el control de mi trayectoria de planeo con el acelerador. Sobre el umbral, extiende las aletas si estás seguro de que no tienes hielo, luego acelera hacia atrás y redondea alrededor de un pie del suelo ... Lo siento, sitio web equivocado. –

+0

Mi teléfono rara vez funciona en el ascensor. – Damo

Respuesta

2

Para mí, una de las principales cosas que se pueden hacer en un DVCS como Git que no funciona bien en el SVN es la siguiente:

1) Crear varias ramas de desarrollo fuera del tronco de diversas características que son en desarrollo.

2) Fusiona el código de una rama de entidad en otra rama de entidad antes de que cualquiera de las ramas de entidad esté terminada y lista para combinarse en la línea troncal.

3) Más tarde, combine las ramas de características en el tronco.

Es bueno dividir las nuevas funciones en ramas separadas para que el tronco permanezca limpio hasta que las funciones estén terminadas. Pero, inevitablemente, te encuentras con una situación en la que un equipo que trabaja en una rama de características ha escrito algún código que necesita un equipo en otra rama de características. Si combina este código en las ramas de características con SVN, tendrá problemas para fusionarse en el tronco más adelante. Git evita este problema.

Aquí hay otro beneficio ... Su empresa decide subcontratar el desarrollo de una característica a una empresa india de contratación.O bien, su grupo de Servicios profesionales necesita agregar una función para un cliente, y esa característica puede ser productizada en el futuro. Realmente no desea dar acceso de escritura a su SVN al contratista indio o su grupo PS. Por lo tanto, deben crear el código fuera del control de origen, y debe fusionarlo usted mismo, detectar y resolver cualquier conflicto usted mismo sin la ayuda de SVN, y perder todo el historial de registro de los contratistas en el proceso.

Pero con git, solo le da al contratista o a su grupo PS una copia del repositorio, y pueden comprometerse con él como un desarrollador. Más tarde, puede usar las funciones de git para fusionar los cambios nuevamente en su repositorio de git. Git encontrará los conflictos y preservará la historia.

Finalmente, una de las mejores cosas de git es que realmente no tienes que convencer a tu amigo de que es mejor que SVN. Debido a que git se integra muy bien con SVN, su compañía/amigo puede usar SVN alegremente mientras que felizmente usa un git conectado al SVN.

0

Dos palabras: Fusión, bifurcación.

La fusión y la bifurcación son más fáciles en Git que en cualquier otro lugar. Git necesitaba resolver un problema: fusionar código escrito por miles de desarrolladores que rara vez están en la misma revisión. Ahora intente esto en SVN:

  1. confirmar su copia de trabajo (sin romper la acumulación de cualquier otra persona)
  2. Consigue la última versión (sin corromper su copia de trabajo)
  3. fusionar el código con una versión de destino arbitrario mientras puede retroceder a su copia de trabajo o a la versión de destino sin el riesgo de perder ninguno de los tres (copia de trabajo, versión de destino, fusión entre los dos).

Se puede hacer con SVN, pero en Git, este es el modo de funcionamiento predeterminado y por lo tanto, el más simple.

+0

Creo que la afirmación "en Git, este es el valor predeterminado" no está claro. ¿Qué es "esto" en esa declaración? –

+0

¿Estás seguro de que "M & B es más fácil en SVN que en Git"? –

+0

Tonto de mí. Fijo. –

1

Pídale que trabaje/compruebe/confirme/compruebe registros/revertir sin acceso a su repositorio de red (por ejemplo, en un avión).

+0

Esto se cita cada vez que las personas hablan sobre la revisión distribuida pero, sinceramente, ¿cuántos * desarrolladores * trabajan en aviones? – JasonSmith

+0

Trabajo en trenes casi todos los días. – Dustin

+0

Conozco a un tipo que trabaja en un pueblo de África y contribuye al kernel de Linux y a muchos otros proyectos de código abierto. Su único acceso a Internet es un cibercafé en un pueblo a 3 horas de distancia, y ese café solo abre una hora a la semana. El acceso ubicuo a Internet es un mito. –

2

Ya había a question similar to this. Además, Eric Sink tuvo un number de articles sobre DVCS. Tanto las respuestas a la otra pregunta como a los artículos pueden ayudar a tomar una decisión informada. Simplemente decir que uno es mejor que el otro probablemente no ayude (Tristemente, parece ser todo lo que Linus hace al respecto, lo que realmente no ayuda a convencer a la gente, al menos no a mí :)).

1

Es un problema de blub.

Cualquier cosa que pueda hacer en su sistema centralizado, puedo hacerlo en mi sistema distribuido, pero mis tareas DVCS cotidianas que me convierten en un desarrollador increíblemente eficiente no se pueden realizar en su sistema centralizado - y no puedes entender eso porque percibes el mundo con las limitaciones que tu sistema te ha impuesto.

0

Para un desarrollador, la diferencia más importante entre DVCS y SVN es velocidad.

Cuando un comando que toma 30 segundos o 4 minutos en SVN toma 1 o 2 segundos en Git o Mercurial o Bazaar, es una gran diferencia para un desarrollador. El control de versiones se convierte en una tarea menor en lugar de una interrupción en su flujo de trabajo. No necesita agregar cafeína & para invocar su ritual pavloviano para ponerse a trabajar; mantienes tu enfoque al no perderlo.

Otros beneficios son importantes, pero son secundarios en comparación:

  • más simple, la ramificación más flexible y fusión, con menos, de combinación simple conflicto
  • Brom libertad está limitada por el acceso a la red y el tiempo de actividad del servidor
  • estructura
  • cesión temporal que coincide con el flujo de trabajo
Cuestiones relacionadas