¿Por qué todos usan Git de manera centralizada?

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.

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.

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.

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 .

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 tú 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.

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.

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.

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.

¿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 :

• Caracteristicas

• Comandos básicos

• Comandos avanzados

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.

2. ¿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.

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.

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.

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.

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.

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.

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".