¿Por qué todos usan Git de manera centralizada?

Ahh, pero de hecho, ¡ estás usando git de manera descentralizada!

Comparemos el predecesor de git en mindshare, svn. Subversión tenía un solo "repo", una fuente de verdad. Cuando hiciste un commit, fue en un único repositorio central, al que también se comprometieron todos los otros desarrolladores.

Este tipo de trabajo funcionó, pero dio lugar a numerosos problemas, el mayor de ellos fue el temido conflicto de combinación . Estos resultaron ser en cualquier lugar, desde molestos hasta pesadillas para resolver. Y con una fuente de verdad, tenían el desagradable hábito 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; por lo general, solo afectan a los desarrolladores involucrados con los cambios conflictivos, en lugar de a todos.

Luego está el único punto de falla y los problemas concomitantes que trae. Si su repositorio de svn central muere de alguna manera, todos están atornillados hasta que se pueda restaurar desde la copia de seguridad, y si no hubiera copias de seguridad, están doblemente atornillados. Pero si el repositorio de 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 de CI, las estaciones de trabajo de los desarrolladores, etc. Puede hacer esto precisamente porque están distribuidos. y cada desarrollador tiene una copia de primera clase del repositorio.

Por otra parte, dado que su git repo es un repo de primera clase por sí mismo, 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 con un impulso a un control remoto. Otros desarrolladores pueden eliminar esos cambios cuando sea conveniente para ellos, en lugar de tener que comprobar svn constantemente para ver si alguien ha hecho algo que los arruine.

El hecho de que, en lugar de empujar directamente a otros desarrolladores, les envíe 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 es impuesta por 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 (usted está usando CI, ¿verdad?) crea una compilación, ¿de dónde extrae? 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 tutores que revisan las solicitudes de extracción, tiene una manera fácil de satisfacer la solicitud de "darme una versió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 a local. Una vez que tengo una característica completa, fusiono mis confirmaciones y las empujo a mi control remoto. Entonces cualquier persona puede ver mi código tentativo, proporcionar comentarios, etc. antes de crear una solicitud de extracción y el administrador del proyecto lo combina en el repositorio de One True.

Con el CVCS tradicional, o te comprometes o no. Eso está bien para algunos flujos de trabajo (yo uso ambos tipos de VCS para diferentes proyectos), pero se cae de bruces para un proyecto público o OSS. La clave es que DVCS tiene varios pasos, que son más trabajo, pero proporcionan una mejor manera de integrar el código de extraños a través de un proceso incorporado que permite una mejor visibilidad de lo que se está registrando. Si lo usa de manera centralizada, aún puede tener ese estándar de oro del estado actual del proyecto al mismo tiempo que proporciona un mejor mecanismo de intercambio de 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 extraemos de los repositorios de otros colegas sin pasar por Ese repo central. Cuando hacemos esto, seguimos pasando 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 función en particular y quiere mantenerse actualizado el uno con el otro, pero aún no tiene interés en publicar la función para todos. Naturalmente, dado que no somos trabajadores de silos secretos, esas situaciones no duran mucho, pero DVCS proporciona la flexibilidad para hacer lo que sea más conveniente. Podemos publicar una rama de función o no según el gusto.

Pero el 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, para extraer "todos los cambios de mis colegas que han sido examinados en el repositorio central", en lugar de extraer por separado los cambios de cada uno de N colegas DVCS no está tratando de evitar que el "pull from main repo" sea el flujo de trabajo más común, sino que trata de evitar que sea el único flujo de trabajo disponible.

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

Si "verdaderamente descentralizado" significa "no hay repositorios especiales", entonces no creo que Linus quiera defender, dado que, de hecho, sí mantiene repositorios especiales que son más importantes en el gran esquema de las cosas, que un 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. git no privilegia su repo sobre el mío, pero Linus sí lo privilegia. Su "es el estado actual de Linux", el mío no lo es. Así que, naturalmente, los cambios tienden a pasar 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 son forzados , porque están descentralizados, para 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 ninguna razón fundamental por la que no pueda configurar un VCS centralizado con una memoria caché local que mantenga todo el historial de operaciones de solo lectura desactualizadas (creo que Perforce tiene una opción para este modo, pero nunca he usado Perforce). O, en principio, puede configurar git con su directorio .git/ en un sistema de archivos montado a distancia para emular la "característica" de SVN que no funciona cuando no tiene una conexión de red. En efecto, el DVCS obliga a que la plomería sea más robusta de lo que puede lograr en un VCS centralizado. Este es un efecto colateral (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 responsabilidad humana .

Lo interesante de la naturaleza del 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. Así que te preguntaré, ¿por qué tú 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, ya que, aunque puedan parecer sutiles, son generalizadas. Estas son todas las cosas que mi equipo realmente hace en el trabajo que no pudimos hacer cuando tuvimos un VCS centralizado:

• Tenga una lista muy pequeña de desarrolladores principales con acceso comprometido al repositorio "central" para cada microservicio. Todos los demás pueden trabajar fuera de las horquillas y enviarlas mediante solicitudes de extracción.
• Puede cometer mucho con más frecuencia, generalmente varias veces por hora, en lugar de una o dos veces por día.
• Puede crear ramas por cualquier motivo para coordinar temporalmente con compañeros de trabajo, empujar hacia él y jalarlo 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 sucursal 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 tu pregunta proviene de una mentalidad (comprensible) siempre conectada . es decir El servidor ci central 'truth' 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 mi equipo trabajó hace varios años. Todo el código (estamos hablando de una base de código de > US $ 1b) tuvo que hacerlo (por ley / acuerdo internacional, los hombres de traje oscuro vienen si no lo hacen) Estar en máquinas físicamente aisladas de cualquier conexión a Internet . Esto significó la situación habitual de cada uno de nosotros teníamos 2 PC, una para escribir / ejecutar / probar el código, la otra para cosas de Google, consultar el correo electrónico y demás. Y había una red local dentro del equipo de estas máquinas, obviamente de ninguna manera está 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 todo en bloques de hormigón (edificio reforzado, yada-yada). Esa máquina también no tenía conexión a Internet.

Periódicamente, sería tarea de alguien transportar (físicamente) una unidad 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, imagínese.

Además, en muy sistemas grandes donde tienes lotes de equipos. En general, cada uno tendrá su propio repo "central", que luego regresa al repo central "central" real (nivel divino). Sé que al menos otro contratista que hizo el mismo git repo dash del disco duro también 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 conectado las herramientas de control de fuente del modelo ( es decir SVN, por ejemplo) no se pudieron usar - o no podría usarse tan fácilmente.

En última instancia, estás construyendo un producto. Este producto representa su código en un solo punto en el tiempo. Dado eso, su código debe unirse en alguna parte . El punto natural es un servidor ci o servidor central desde el cual se construye el producto, y tiene sentido que este punto central sea un repositorio git.

El aspecto distribuido de un DVCS aparece en desarrollo de código abierto todo el tiempo, en forma de forking. Por ejemplo, algunos de los proyectos en los que contribuyo fueron abandonados por el autor original y ahora tienen un montón de bifurcaciones donde los mantenedores a veces extraen 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 al repositorio de la verdad en la tierra.

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

  

¿Por qué todos usan git de manera centralizada?

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

En segundo lugar, hay más características que puedes encontrar en Git pero no en CVS o SVN. Tal vez solo esté 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 sucursales y el historial completo están disponibles) y todas las sucursales pueden verificarse sin conectarse a un servidor.

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

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

Por lo tanto, puedo comprometer mis cambios, tal vez hacer squash de los trabajos en curso juntos, luego recuperar y rebautizar mi trabajo en la rama principal de desarrollo.

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

• firmar de forma criptográfica
• rebasar (reordenar y realizar confirmaciones de squash; editar confirmaciones, no solo el mensaje)
• cosecha de cerezas
• dividiendo la historia
• sucursales locales y cambios de ocultación (llamados "estanterías" en Wikipedia)

También vea estas tres tablas en Wikipedia - Comparación del software de control de versiones :

• Características

• Comandos básicos

• Comandos avanzados

De nuevo, tal vez la manera descentralizada no sea la característica que solo hace que la gente lo use.

  

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

Cualquier persona que contribuya a un proyecto más grande o lo esté hospedando en Bitbucked, GitHub, etc. hará exactamente eso. 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 subcontratan módulos y no quieren que los externos modifiquen las ramas sagradas de desarrollo sin haber revisado sus cambios antes.

  

2. ¿Es la capacidad de trabajo distribuida incluso importante para el control de versión moderno, ...
  

Como siempre: depende de los requisitos.

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

• desea confirmar o navegar el historial fuera de línea (es decir, terminar el submódulo en la cabaña de montaña durante las vacaciones)
• proporcione repositorios centrales pero desea mantener el repositorio "verdadero" para revisar los cambios (es decir, para proyectos grandes o equipos distribuidos)
• desea proporcionar (una copia de) todo el historial y las sucursales ocasionalmente, al mismo tiempo que impide el acceso directo al repositorio central (similar al segundo)
• desea versionar algo sin tener que almacenar eso de forma remota o configurar un repositorio dedicado (especialmente con Git, un simple git init . debería ser suficiente para estar listo para la versión de 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 también una bendición. Y como Git es extremadamente flexible, casi siempre es demasiado demasiado flexible para la situación típica. Específicamente, la mayoría de los proyectos Git no son Linux.

Como resultado, la opció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 beneficios claros utilizando 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, es casi seguro que utiliza por defecto el modelo de "antepasado único". Y los gráficos en los que los nodos tienen un antepasado único (a excepción de un nodo raíz) son exactamente árboles. Por lo tanto, su propio cliente git utiliza por defecto el modelo de árbol y, por lo tanto, los repositorios centralizados.

La lógica de negocios premia 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, excepto en los casos extraños y extraños donde el bit distribuido era esencial para mantener las cosas en movimiento.

El lado distribuido de las cosas es complicado. Normalmente quieres mantener las cosas fáciles y sin complicaciones. Sin embargo, al utilizar git, se asegura de tener acceso al lado distribuido para hacer frente a las situaciones complicadas que puedan surgir en el futuro.

Para que un compañero de trabajo extraiga un repositorio git en mi máquina significa que necesito tener un demonio git ejecutándose en el 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 provista por mi empresa. La solución más fácil es "NO"! Para que un compañero de trabajo saque un repositorio de git en mi máquina también significa que mi dirección de Internet debe ser corregida. Viajo, trabajo desde casa y ocasionalmente trabajo desde mi oficina.

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

En la tercera mano, mi repositorio local de git es un repositorio con todas las funciones. Puedo realizar un nuevo trabajo, crear una nueva rama para el trabajo experimental y revertir el trabajo cuando hago un lío de cosas, incluso cuando estoy trabajando en un avión que vuela a 30,000 pies en 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 en desarrollador para 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 principal de Alicia y la rama principal 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 de desarrollador.

Simple:

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

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

GIT ofrece características que son útiles para las empresas (por ejemplo, solicitudes de revisión para 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 el 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 características diferentes de GIT son importantes para él que para su compañía centrada en el github.

Tal vez se deba a que el procesamiento de la nómina está centralizado, por lo que debemos mantener contentos a una persona central si queremos 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 se deba a que la base de datos de errores está centralizada, y debe mantenerse sincronizada con el código .

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

Al ser un sistema distribuido, Git permite crear un nuevo centro a bajo costo desde cualquier repositorio actualizado (solo 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 desarrolladores, lo que facilita la recuperación del centro.

Ser capaz de fusionar, 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. Igualmente con el registro de código con vuelo etc.

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