¿Por qué todos usan Git de manera centralizada?

289

He usado Git en mis dos compañías anteriores para el control de versiones. Por lo que escuché, parece que alrededor del 90% de las empresas usan Git sobre otros sistemas de control de versiones.

Uno de los principales puntos de venta de Git es que está descentralizado, es decir, todos los repositorios son iguales; no hay un depósito central / fuente de verdad. Esta fue una característica que Linus Torvalds defendió.

Pero parece que todas las compañías usaron Git de manera centralizada, al igual que uno usaría SVN o CVS. Siempre hay un repositorio central en un servidor (generalmente en GitHub) del que las personas sacan y empujan. Nunca he visto ni oído hablar (en mi experiencia, sin duda limitada) de personas que usan Git de la manera verdaderamente descentralizada en la que estaba destinado, es decir, empujar y atraer a los repositorios de otros colegas como les parezca.

Mis preguntas son:

  1. ¿Por qué la gente no usa un flujo de trabajo distribuido para Git en la práctica?
  2. ¿Es la capacidad de trabajar de manera distribuida incluso importante para el control de versiones moderno, o suena bien?

Editar

Me di cuenta de que no entendí el tono correcto en mi pregunta original. Parecía que estaba preguntando por qué alguien trabajaría de manera centralizada cuando un sistema de control de versiones distribuido (DVCS) era tan obviamente superior. En realidad, lo que quería decir era que no veo ningún beneficio para DVCS en absoluto . Sin embargo, a menudo escucho a personas predicando su superioridad, mientras que el mundo real parece estar de acuerdo con mi punto de vista.

cabeza de jardín
fuente
31
Siento exactamente lo mismo, y no entiendo esto.
Snoop
57
Personalmente, simplemente no conozco ningún caso de uso para múltiples controles remotos, aparte de los tenedores para crear relaciones públicas en el control remoto principal. Lo distribuido sigue siendo útil porque significa que obtengo un historial completo en mi máquina sin tener que hablar con la red, y puedo hacer un trabajo sin conexión si realmente lo deseo, y es mucho más fácil migrar de un host de repositorio en línea a otro. ¿Qué es exactamente lo que tiene en mente cuando se refiere a un "flujo de trabajo distribuido"?
Ixrec
43
Estoy bastante seguro de que Torvalds pretendía desde el principio tener un repositorio de Kernel de Linux "fuente de verdad".
Steven Burnap
67
En definitiva, el software en sí está centralizado. Los clientes no compran sucursales ni controles remotos, compran un producto final, construido y construido. Siempre debe haber algún camino central hacia adelante.
Brandon
37
Para mí, la "descentralización" de git es una de las características menos importantes que lo recomiendan. La capacidad de realizar confirmaciones y retrocesos frecuentes a nivel local, sin afectar a nadie más, o técnicas poderosas como el rebase es donde git realmente brilla en mi flujo de trabajo. Es posible (de hecho probable) que todo esto sea posible al estar descentralizado, pero la "D" en DVCS no es tan importante por mí misma.
Jay

Respuestas:

257

Ahh, pero en realidad se está utilizando git de manera descentralizada!

Comparemos el predecesor de git en mindhare, svn. Subversion solo tenía un "repositorio", una fuente de verdad. Cuando hizo una confirmación, fue a un único repositorio central, al que también se comprometían todos los demás desarrolladores.

Este tipo de trabajo funcionó, pero condujo a numerosos problemas, el mayor de ellos fue el temido conflicto de fusión . Estos resultaron ser desde molestos hasta pesadillas para resolver. Y con una fuente de verdad, tenían la desagradable costumbre de detener el trabajo de todos hasta que se resolvieran. Los conflictos de fusión ciertamente existen con git, pero no son eventos que detienen el trabajo y son mucho más fáciles y rápidos de resolver; generalmente afectan solo a los desarrolladores involucrados con los cambios conflictivos, en lugar de a todos.

Luego está todo el punto único de falla y los problemas que esto conlleva. Si su repositorio svn central muere de alguna manera, está todo jodido hasta que pueda restaurarse de la copia de seguridad, y si no hubo copias de seguridad, está doblemente jodido. Pero si el repositorio git "central" muere, puede restaurar desde una copia de seguridad, o incluso desde una de las otras copias del repositorio que se encuentran en el servidor CI, las estaciones de trabajo de los desarrolladores, etc. Puede hacerlo precisamente porque están distribuidos, y cada desarrollador tiene una copia de primera clase del repositorio.

Por otro lado, dado que su repositorio de git es un repositorio de primera clase por derecho propio, cuando se compromete, sus confirmaciones van a su repositorio local. Si desea compartirlos con otros, o con la fuente central de la verdad, debe hacerlo explícitamente presionando un control remoto. Otros desarrolladores pueden eliminar esos cambios cuando sea conveniente para ellos, en lugar de tener que verificar svn constantemente para ver si alguien ha hecho algo que los arruine.

El hecho de que, en lugar de empujar directamente a otros desarrolladores, empuje los cambios indirectamente a través de otro repositorio remoto, no importa mucho. La parte importante desde nuestra perspectiva es que su copia local del repositorio es un repositorio por derecho propio. En svn, la fuente central de la verdad se impone mediante el diseño del sistema. En git, el sistema ni siquiera tiene este concepto; si hay una fuente de verdad, se decide externamente.

Michael Hampton
fuente
15
Las fusiones SVN también solo afectan a los desarrolladores involucrados con cambios conflictivos. Una confirmación llega al repositorio, ninguna fusión conflictiva puede entrar en el repositorio hasta que se resuelvan los conflictos (también puede comprometerse en paralelo a una rama / ruta separada, pero eso no entra en conflicto ahora, ¿verdad?)
Ben Voigt
30
Creo que la principal diferencia, cuando existe un servidor central, es que GIT permite el control de versiones locales mientras la red está inactiva, y SVN no (algunos otros sistemas de control de versiones son aún peores, y detienen todo el trabajo cuando la red es inaccesible , porque no te permiten cambiar un archivo hasta que lo revises).
Ben Voigt
17
@BenVoigt Oh, es un trabajo que se detiene bien. Recuerde que debe svn upestar al día con el repositorio antes de poder registrarse. Cuando otros continúan registrando mientras está tratando de resolver conflictos de fusión, y darle otro conjunto de conflictos de fusión ... o bien ponga fin a eso o pierdes lo que queda de tu cordura.
Michael Hampton
21
No, la gente definitivamente puede seguir comprometiéndose en la rama de la que está fusionando los cambios, sin interrumpir su flujo de trabajo.
Ben Voigt
29
Ben tiene razón. Un repositorio SVN administrado adecuadamente y utilizado por un equipo que ha sido educado adecuadamente en cómo desarrollar software, nunca debería tener conflictos de fusión en el tronco. Solo los obtendrá cuando alguien haya hecho algo mal y deba ser despedido (: P). inb4 es más fácil cuando no tienes que educar a las personas sobre cómo usar sus herramientas. Sí, bueno, ¡hay mucho más que enseñar sobre Git que sobre SVN!
Carreras de ligereza en órbita
118

Cuando su servidor de compilación ( está utilizando CI, ¿verdad?) Crea una compilación, ¿de dónde saca? Claro, una compilación de integración que podría argumentar no necesita "un verdadero repositorio", pero sí una compilación de distribución (es decir, lo que le da al cliente).

En otras palabras: fragmentación. Si designa un repositorio como "el" repositorio y designa a los tutores que examinan las solicitudes de extracción, tiene una manera fácil de satisfacer la solicitud de "darme una compilación de software" o "Soy nuevo en el equipo, ¿dónde está el código?"

La fuerza de DVCS no es tanto el aspecto de igual a igual, sino el hecho de que es jerárquico . Modifico mi espacio de trabajo, luego me comprometo con local. Una vez que tengo una función completa, fusiono mis commits y los envío a mi control remoto. Entonces cualquiera puede ver mi código tentativo, proporcionar comentarios, etc., antes de crear una solicitud de extracción y un administrador del proyecto lo fusiona en el repositorio One True.

Con el CVCS tradicional, usted se compromete o no. Eso está bien para algunos flujos de trabajo (uso ambos tipos de VCS para diferentes proyectos), pero se cae de bruces para un proyecto público u OSS. La clave es que DVCS tiene varios pasos, que son más trabajo, pero proporcionan una mejor manera de integrar código de extraños a través de un proceso integrado que permite una mejor visibilidad de lo que se está registrando. Usarlo de manera centralizada significa que aún puede tener ese estándar de oro del estado actual del proyecto al tiempo que proporciona un mejor mecanismo para compartir código.


fuente
2
En general, es una buena respuesta, pero estoy bastante seguro de que Git estaba en uso generalizado antes de la integración continua; nuestro equipo usa CI, por cierto, gracias por verificar: D.
cabeza de jardín
55
@gardenhead: se perdió el punto: el mismo argumento se mantiene si uno hace las compilaciones de integración manualmente. "CI" es solo una automatización para un proceso que es mucho más antiguo que Git.
Doc Brown,
25
"cualquiera puede ver mi código tentativo", y también pueden extraer su código tentativo, fusionarlo con su código tentativo y ejecutar las pruebas. Esto es una molestia en los VCS centralizados, ya que requiere ramas y cambios en One True Copy. Distribuido, simplemente configura controles remotos adicionales, luego comienza a fusionar, parchar y seleccionar cerezas. Tienes un seguimiento de lo que has hecho, pero nadie más tiene que ver qué travesuras estás haciendo a menos que elijas publicarlas. En general, recomiendo que nadie declare que DVCS no tiene sentido hasta que realmente hayan usado SVN para un proyecto grande ...
Steve Jessop
99
Porque no hay "una verdadera compilación" del núcleo de Linux. Como todos lo construyen ellos mismos, el repositorio de Linus no es más canónico que el de cualquier otra persona. Si está vendiendo un producto que no funciona tan bien.
Miles Budnek
2
@Superbest: gran parte (si no todo) del diseño de git se basó en Bitkeeper. Git fue creado después de que estalló la controversia de Linux-Bitkeeper.
whatsisname
40

No sé cómo se define a "todos", pero mi equipo tiene "un repositorio central en un servidor" y también de vez en cuando nos retiramos de los repositorios de otros colegas sin pasar por ese repositorio central. Cuando hacemos esto, todavía vamos a través de un servidor, porque elegimos no enviar parches por correo electrónico sobre el lugar, pero no a través del repositorio central. Esto generalmente ocurre cuando un grupo está colaborando en una característica en particular y quiere mantenerse actualizado entre sí, pero aún no tiene interés en publicar la característica para todos. Naturalmente, dado que no somos trabajadores secretos en el silo, esas situaciones no duran mucho, pero DVCS proporciona la flexibilidad para hacer lo que sea más conveniente. Podemos publicar una rama característica o no según el gusto.

Pero más del 90% del tiempo, claro, vamos a través del repositorio central. Cuando no me importa ningún cambio en particular o el trabajo de un colega en particular, es más conveniente, y se escala mejor, extraer "todos los cambios de mis colegas que se han examinado en el repositorio central", en lugar de extraer cambios por separado de cada uno de N colegas DVCS no está tratando de evitar que el "flujo desde el repositorio principal" sea el flujo de trabajo más común, está tratando de evitar que sea el único flujo de trabajo disponible.

"Distribuido" significa que todos los repos son técnicamente equivalentes en lo que respecta al gitsoftware, pero no se deduce que todos tengan la misma importancia en lo que respecta a los desarrolladores y nuestros flujos de trabajo. Cuando lanzamos a clientes o servidores de producción, el repositorio que usamos para hacer eso tiene una importancia diferente de un repositorio utilizado solo por un desarrollador en su computadora portátil.

Si "verdaderamente descentralizado" significa "no hay cesiones temporales especiales", entonces no creo que eso es lo que significa Linus al campeón, dado que en realidad él no mantener repositorios especiales que son más importantes en el gran esquema de las cosas, que es algún clon aleatorio de Linux que hice ayer y planeo usar solo para desarrollar un pequeño parche y luego eliminarlo una vez que haya aceptado el parche. gitno privilegia su repositorio sobre el mío, pero Linus lo privilegia. Su "es el estado actual de Linux", el mío no lo es. Entonces, naturalmente, los cambios tiendenpasar por Linus. La fuerza de DVCS sobre VCS centralizado no es que no debe haber un centro de facto, es que los cambios no tienen que pasar por ningún centro porque (si los conflictos lo permiten) cualquiera puede fusionar cualquier cosa.

Los sistemas DVCS también están obligados , porque están descentralizados, a proporcionar ciertas características convenientes basadas en el hecho de que necesariamente debe tener un historial completo (es decir, un repositorio) localmente para hacer cualquier cosa. Pero si lo piensa, no hay una razón fundamental por la que no pueda configurar un VCS centralizado con una memoria caché local que mantenga todo el historial de las operaciones de solo lectura que están desactualizadas (creo que Perforce tiene una opción para este modo, pero nunca he usado Perforce). O, en principio, podría configurar gitcon su.git/directorio en un sistema de archivos montado remotamente para emular la "característica" de SVN de que no funciona cuando no tiene una conexión de red. En efecto, DVCS obliga a la tubería a ser más robusta de lo que puede escapar en un VCS centralizado. Este es un efecto secundario (muy bienvenido) y ayudó a motivar el diseño de DVCS, pero esta distribución de responsabilidad a nivel técnico no es lo mismo que descentralizar completamente toda la responsabilidad humana .

Steve Jessop
fuente
77
Son técnicamente equivalentes, no socialmente equivalentes.
curiousdannii
3
Enviar parches por correo electrónico es bastante sencillo, en caso de que alguien lo esté considerando, solo use git format-patch y luego git send-email . Hice eso cuando no quería jugar con los controles de acceso de Github y fue muy sencillo, después de todo, todos tienen un correo electrónico.
Rudolf Olah
1
"necesariamente debe tener una historia completa [...] localmente para hacer cualquier cosa", no es cierto; Los DSCM modernos admiten repositorios parciales ("pagos poco profundos" en términos bzr, "clones superficiales" en términos git).
Charles Duffy el
27

Lo interesante de la naturaleza de DVCS es que si otras personas lo usan de manera distribuida, es probable que no lo sepa a menos que interactúen directamente con usted. Lo único que puedes decir definitivamente es que y tus compañeros de equipo directos no usan git de esta manera. Esto no requiere una política de toda la empresa. Entonces te preguntaré, ¿por qué no usas git de manera descentralizada?

Para abordar su edición, quizás necesite algo de experiencia trabajando con un control de versión centralizado real para apreciar las diferencias, porque aunque puedan parecer sutiles, son dominantes. Estas son todas las cosas que mi equipo realmente hace en el trabajo que no pudimos hacer cuando teníamos VCS centralizado:

  • Tenga una lista muy pequeña de desarrolladores principales con acceso de confirmación al repositorio "central" para cada microservicio. Todos los demás pueden trabajar sin tenedores y enviar a través de solicitudes de extracción.
  • Puede comprometerse con mucha más frecuencia, generalmente varias veces por hora frente a una o dos veces por día.
  • Puede crear ramas por cualquier motivo para coordinarse temporalmente con sus compañeros de trabajo, empujar y tirar de él varias veces al día, luego aplastarlo cuando esté listo para compartir con un grupo más grande. ¿Tienes idea de lo difícil que es obtener permiso para crear una rama temporal para algo como esto en un CVCS tradicional?

A riesgo de sonar viejo por decirlo, realmente no sabes lo fácil que lo tienes.

Karl Bielefeldt
fuente
1
La pregunta de cuán difícil es crear una sucursal en un CVCS tradicional depende completamente de la política: trabajo con un repositorio SVN ascendente (¡naturalmente a través de un clon git-svn!), Y tengo todo el derecho de crear cualquier sucursal querer, a pesar de que es un proyecto bastante grande. No se me permite tocar varias ramas de integración designadas, y mucho menos el tronco, sin hablar primero con mis superiores. Otras compañías pueden tener otras políticas que pueden ser más restrictivas, pero ciertamente no tienen que serlo.
cmaster
77
Tienes razón, no sé lo fácil que lo tengo. Ojalá hubiera estado presente en los días de dominio de SVN para apreciar lo lejos que hemos llegado. Como desarrollador de software muy joven, encuentro que este mismo patrón se repite con bastante frecuencia: los desarrolladores más experimentados me dicen que la antigua forma de hacer algo era mala, y esta nueva forma / tecnología es mucho más fácil. Pero solo tengo que aceptar su palabra; Nunca puedo apreciar realmente las ventajas. Siempre he encontrado esta disonancia difícil de superar.
cabeza de jardín
1
@gardenhead siempre puedes crear tu propio repositorio SVN e intentar romperlo;) (y notar cuánto más difícil es crear un repositorio git y clonarlo ...) - Otra característica importante que he notado (al menos en entornos corporativos especialmente) es que compartir archivos es un poco incómodo o se hace de tal manera que se acumulan repositorios (porque el escáner de virus se bloquea en una unidad de red, por ejemplo).
Wayne Werner
44
@gardenhead: bueno, considérate afortunado de no estar atrapado en un proyecto heredado, con desarrolladores de software antiguos que te dicen que la forma antigua de hacer las cosas está bien ... a veces no puedes evitar sentir que simplemente están ¡Me alegro de que no necesiten aprender nuevas tecnologías!
Leftaroundabout
1
@gardenhead aparentemente los proyectos se están lanzando a un ritmo bastante loco. La capacidad de continuar aprendiendo es necesaria si quieres poder encontrar un trabajo increíble.
Wayne Werner
19

Creo que su pregunta proviene de una mentalidad (comprensible) siempre conectada . es decir, el servidor central de 'verdad' ci está siempre (o casi siempre) disponible. Si bien esto es cierto en la mayoría de los entornos, he trabajado en al menos uno que estaba lejos de esto.

Un proyecto de simulación militar en el que trabajó mi equipo hace varios años. Todo el código (estamos hablando de una base de código> US $ 1b) tenía que (por ley / acuerdo internacional, los hombres con trajes oscuros vienen si no) estar en máquinas físicamente aisladas de cualquier conexión a Internet . Esto significaba la situación habitual de que cada uno tenía 2 PC, una para escribir / ejecutar / probar el código, la otra para las cosas de Google, revisar el correo electrónico y demás. Y había una red local dentro del equipo de estas máquinas, obviamente, de ninguna manera conectada a Internet.

La "fuente central de la verdad" era una máquina en una base del ejército, en una habitación subterránea sin ventanas (edificio reforzado, yada-yada). Esa máquina tampoco tenía conexión a Internet.

Periódicamente, sería el trabajo de alguien transportar (físicamente) un disco con el repositorio git (que contiene todos nuestros cambios de código) a la base del ejército, que estaba a varios cientos de kilómetros de distancia, así que, como pueden imaginar.


Además, en sistemas muy grandes donde tienes muchos equipos. En general, cada uno tendrá su propio repositorio "central", que luego volverá al repositorio central "central" real (nivel de dios). Sé de al menos otro contratista que también hizo el mismo guión de repositorio de disco duro con su código.

Además, si considera algo en la escala del kernel de Linux ... Los desarrolladores no solo envían una solicitud de extracción al propio Linus. Es esencialmente una jerarquía de repositorios, cada uno de los cuales era / es "central" para alguien / algún equipo.

La naturaleza desconectada de git significa que se puede usar en entornos donde las herramientas de control de fuente del modelo conectado ( es decir , SVN, por ejemplo ) no se pueden usar, o no se pueden usar tan fácilmente.

Tersosauros
fuente
3
Soy miembro del Mile High (Software) Club: he cometido un código a 35,000 pies. Claro, los aviones tienen Wifi ahora , pero ese no siempre fue el caso. Y es bueno saber que al menos si fallamos, existe la posibilidad de que mi equipo conserve mi código intacto.
Wayne Werner
@WayneWerner es cierto. Había estado pensando en proporcionar algunas situaciones más genéricas en las que no fuera posible estar (casi) siempre conectado. Por ejemplo, en un avión, barco en el mar, estación espacial, lugares remotos en África, etc.
Tersosauros
18

En definitiva, estás creando un producto. Este producto representa su código en un solo punto en el tiempo. Dado eso, su código debe fusionarse en algún lugar . El punto natural es un servidor ci o servidor central a partir del cual se construye el producto, y tiene sentido que este punto central sea un repositorio git.

Bryan Oakley
fuente
14

El aspecto distribuido de un DVCS aparece en el desarrollo de código abierto todo el tiempo, en forma de bifurcación. Por ejemplo, algunos de los proyectos a los que contribuyo fueron abandonados por el autor original y ahora tienen un montón de tenedores donde los mantenedores a veces obtienen características específicas entre sí. Incluso en general, los proyectos OSS toman contribuciones externas a través de una solicitud de extracción, en lugar de otorgar acceso aleatorio a personas al repositorio de la verdad fundamental.

Este no es un caso de uso muy común cuando se construye un producto concreto con un lanzamiento oficial específico, pero en el mundo F / OSS es la norma, no la excepción.

mullido
fuente
44
Esa es la respuesta correcta, también desde un punto de vista histórico. El kernel de Linux ha tenido múltiples repositorios de origen durante mucho tiempo (llamados "árboles" por los desarrolladores, como "árbol de Linus" o "árbol de Andrew"). Linux quería algo para soportar ese tipo de desarrollo distribuido cuando desarrolló git.
sleske
@Luaan Después de pensar en esto por un tiempo, me di cuenta de que tienes razón. He cambiado un poco la redacción: ¿capta esto un poco mejor la distinción?
esponjoso
@fluffy Suena bien para mí;)
Luaan
9

¿Por qué todos usan git de manera centralizada?

Nunca nos hemos conocido, ¿cómo es que dices a todos? ;)

En segundo lugar, hay más otras características que puede encontrar en Git pero no en CVS o SVN. Tal vez es solo usted asumiendo que esta debe ser la única característica para todos .

Seguro que muchas personas pueden usarlo centralizado como CVS o SVN. Pero no olvide la otra característica que viene inherentemente con un VCS distribuido: todas las copias están más o menos "completas" (todas las ramas y el historial completo está disponible) y todas las ramas se pueden retirar sin conectarse a un servidor.

En mi opinión, esta es otra característica que no debe olvidarse.

Si bien no puede hacer esto con CVS y SVN listos para usar, Git se puede usar centralizado como los anteriores sin ningún problema.

De modo que puedo realizar mis cambios, tal vez aplastar los compromisos de trabajo en progreso juntos, luego buscar y volver a basar mi trabajo en la rama principal de desarrollo.

Otras características que salen de la caja con Git:

  • confirma criptográficamente las confirmaciones
  • rebase (reordenar y aplastar confirmaciones; editar confirmaciones, no solo el mensaje)
  • cosecha de la cereza
  • dividiendo la historia
  • sucursales locales y cambios de escondite (llamados "estanterías" en Wikipedia)

Consulte también estas tres tablas en Wikipedia: comparación del software de control de versiones :

Entonces, de nuevo, tal vez la manera descentralizada no es esa única característica que hace que las personas la usen.

  1. ¿Por qué la gente no usa un flujo de trabajo distribuido para Git en la práctica?

Cualquiera que contribuya o aloje un proyecto más grande en Bitbucked, GitHub, etc. Los mantenedores mantienen el repositorio "principal", un colaborador clona, ​​confirma y luego envía una solicitud de extracción.

En las empresas, incluso con pequeños proyectos o equipos, un flujo de trabajo distribuido es una opción cuando externalizan módulos y no quieren que los externos modifiquen las ramas de desarrollo sagradas sin que se revisen sus cambios antes.

  1. ¿Es la capacidad de trabajo distribuido incluso importante para el control de versiones moderno, ...

Como siempre: depende de los requisitos.

Use un VCS descentralizado si se aplica algún punto:

  • desea confirmar o navegar el historial sin conexión (es decir, finalizar el submódulo en la cabaña de montaña durante las vacaciones)
  • proporcionar repositorios centrales pero desea mantener el repositorio "verdadero" aparte para revisar los cambios (es decir, para grandes proyectos o equipos distribuidos)
  • desea proporcionar (una copia de) todo el historial y las ramas ocasionalmente mientras evita el acceso directo al repositorio central (similar al segundo)
  • desea versionar algo sin tener que almacenarlo de forma remota o configurar un repositorio dedicado (especialmente con Git, un simple git init .bastará para estar listo para versionar algo)

Hay algunos más, pero cuatro deberían ser suficientes.

... o simplemente suena bien?

Por supuesto que suena bien, para principiantes.

tratar de atrapar finalmente
fuente
¿No ganó SVN svn initen algún momento?
immibis
5

La flexibilidad es una maldición y una bendición. Y como Git es extremadamente flexible, que es casi siempre lejos demasiado flexible para la situación típica. Específicamente, la mayoría de los proyectos de Git no son Linux.

Como resultado, la elección inteligente es eliminar parte de esa flexibilidad teórica al implementar Git. En teoría, los repositorios pueden formar cualquier gráfico, en la práctica la elección habitual es un árbol. Podemos ver los claros beneficios usando la teoría de grafos: en un árbol de repositorios, dos repositorios comparten exactamente un antepasado. En un gráfico aleatorio, ¡la idea de un antepasado ni siquiera existe!

Su cliente git, sin embargo, casi por defecto usa el modelo de "antepasado único". Y los gráficos en los que los nodos tienen un solo ancestro (excepto un nodo raíz) son exactamente árboles. Por lo tanto, su cliente git se predetermina al modelo de árbol y, por lo tanto, a los depósitos centralizados.

MSalters
fuente
1
Estoy de acuerdo en que la flexibilidad de Git debe atenuarse para la mayoría de los casos de uso. En mi último trabajo, no teníamos pautas sobre cómo usar git, y había constantes conflictos y roturas debido a esto. En mi nueva empresa, utilizamos el modelo Git Flow, y hace que el desarrollo sea mucho más ágil y libre de estrés.
cabeza de jardín
1
No es "flexibilidad teórica" ​​permitir no árboles. Restrinja a "solo árboles" y nunca podrá fusionarse en sus cambios, lo que hará que todo su VCS sea algo inútil.
Comodín el
2
@Wildcard: La fusión no es un problema en absoluto con los árboles, ¿por qué sería ese el caso? No puede fusionar entre nodos aleatorios, por supuesto, solo entre padre / hijo.
MSalters
1
No estaba lo suficientemente claro, evidentemente. Me refería a un árbol de commits, no a un árbol de sistema de archivos. Por definición, una confirmación de fusión tiene más de un elemento primario y, por lo tanto, su gráfico de historial ya no es un árbol, sino un DAG.
Comodín el
2
@Wildcard: MSalters dijo que los repositorios generalmente están conectados como árboles, no que los commits lo estén. Está diciendo que los repositorios generalmente tienen solo un control remoto "ascendente" al que envían (o emiten solicitudes de extracción). No tengo ninguna estadística sobre si eso es cierto o no, pero es un reclamo completamente separado de cualquier cosa que tenga que ver con cuántos padres tiene un compromiso de fusión.
Steve Jessop
4

La lógica empresarial recompensa a un servidor centralizado. Para casi todos los escenarios empresariales realistas, un servidor centralizado es una característica fundamental del flujo de trabajo.

El hecho de que tenga la capacidad de hacer DVCS no significa que su flujo de trabajo principal tenga que ser DVCS. Cuando uso git en el trabajo, lo usamos de manera centralizada, a excepción de esos extraños casos extraños donde el bit distribuido era esencial para mantener las cosas en movimiento.

El lado distribuido de las cosas es complicado. Por lo general, desea mantener las cosas suaves y fáciles. Sin embargo, al usar git, se asegura de tener acceso al lado distribuido para lidiar con las situaciones complicadas que pueden surgir en el futuro.

Cort Ammon
fuente
3

Para que un compañero de trabajo extraiga de un repositorio de git en mi máquina, necesito tener un demonio git ejecutándose a nivel raíz como una tarea en segundo plano. Soy muy receloso con los demonios que se ejecutan en mi propia computadora o en la computadora portátil que me proporciona la compañía. ¡La solución más fácil es "NO"! Para un compañero de trabajo sacar de un repositorio de git en mi máquina también significa que mi dirección de internet debe ser reparada. Viajo, trabajo desde casa y ocasionalmente trabajo desde mi oficina.

Por otro lado, VPNing al sitio corporativo y empujar una sucursal al repositorio central toma menos de un minuto. Ni siquiera necesito una VPN si estoy en la oficina. Mis compañeros de trabajo pueden sacar fácilmente de esa rama.

Por otro lado, mi repositorio local de git es un repositorio completo. Puedo comprometer un nuevo trabajo, crear una nueva sucursal para el trabajo experimental y revertir el trabajo cuando hago un desastre, incluso cuando estoy trabajando en un avión que vuela a 30,000 pies sobre el medio de la nada. Intenta hacerlo con un sistema de control de versiones centralizado.

David Hammen
fuente
"Soy muy receloso con los demonios que se ejecutan en mi propia computadora o en la computadora portátil que me proporciona la compañía". - Porque aparte de cualquier otra cosa, ejecutar un servicio en mi computadora portátil significa que el servicio no está disponible cuando cierro la tapa. DynDNS podría ayudar con múltiples ubicaciones (hasta cierto punto, aún puede estar atrapado detrás de un NAT), pero no ayuda con apagar su tarjeta de red ...
Steve Jessop
Hay muchas maneras de hacer visible un repositorio git sin ejecutar ningún demonio especial; se puede acceder a través de casi cualquier recurso compartido de archivos (smb, sshfs, etc.), e incluso puede estar disponible como un simple almacén HTTP.
esponjoso
2

Complejidad:

Con un repositorio central, un flujo de trabajo típico podría ser

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

La complejidad con respecto al número de desarrolladores en O (1).

Si, en cambio, cada desarrollador tiene su propia rama maestra se convierte, para el desarrollador 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

El enfoque de igual a igual es O (N).

Consistencia:

Ahora considere si hay un conflicto de fusión entre la rama maestra de Alice y la rama maestra de Bob. Cada uno de los desarrolladores N podría resolver el conflicto de manera diferente. Resultado: caos. Hay formas de lograr una consistencia eventual, pero hasta que eso suceda, se puede desperdiciar todo tipo de tiempo para desarrolladores.

Theodore Norvell
fuente
Si va a rechazar la votación, ¿podría dejar un comentario sobre por qué?
Theodore Norvell
No es que me molesten los votos negativos. Solo quiero saber si la respuesta es incorrecta de alguna manera.
Theodore Norvell
1

Sencillo:

Las empresas son organizaciones centralizadas, con flujo de trabajo centralizado.

Cada programador tiene un jefe y él tiene su jefe, etc. hasta CTO. CTO es la última fuente de verdad técnica. Cualquiera que sea la herramienta que utilice la empresa, debe reflejar esta cadena de mando. Una compañía es como un ejército: no se puede dejar que los privados superen a un general.

GIT ofrece características que son útiles para las empresas (por ejemplo, solicitudes de extracción de revisión de código) y que solo las hace cambiar a GIT. La parte descentralizada es simplemente una característica que no necesitan, por lo que la ignoran.

Para responder a su pregunta: la parte distribuida es de hecho superior en un entorno distribuido, por ejemplo, de código abierto. Los resultados varían dependiendo de quién está hablando. Linus Torvalds no es exactamente su rata de cubículo, por eso las diferentes características de GIT son importantes para él que para su empresa centrada en github.

Agent_L
fuente
-2

Tal vez sea porque el procesamiento de la nómina está centralizado, por lo que debemos mantener contenta a una persona central si deseamos que nos paguen.

Tal vez sea porque estamos creando un producto, por lo que necesitamos una copia maestra del software para los clientes.

Tal vez sea porque es mucho más fácil para un programador ir a un lugar para obtener los cambios de todos, en lugar de tener que conectarse a muchas máquinas diferentes.

Tal vez sea porque la base de datos de errores está centralizada y debe mantenerse sincronizada con el código .

Estar centralizado es genial, hasta que haya un problema ...

Git es un sistema distribuido que permite crear un nuevo centro a bajo costo desde cualquier repositorio actualizado (simplemente exponga el repositorio a la red). Git también permite que una copia de seguridad desactualizada se actualice desde los repositorios en las máquinas de desarrollo, lo que facilita la recuperación del centro.

Poder combinar, etc., en una copia local de un repositorio cuando la red está inactiva es excelente, pero no necesita un sistema distribuido; solo necesita un sistema que mantenga una copia local de todos los datos. Del mismo modo con el código de registro con vuelo, etc.

Al final del día, hay poco costo para ser distribuido y algunos beneficios. La mayor parte del costo de distribución se encuentra en el área que se necesita si desea un excelente seguimiento de sucursales, etc. Si diseñara un sistema para su uso en la mayoría de las empresas, no lo diseñaría para su distribución, como control centralizado del código fuente es claramente el principal "caso de uso".

Ian
fuente