Control de versiones: ¿Cómo funciona un repository en las instalaciones de alojamiento de código fuente?

Estoy un poco curioso acerca de cómo las instalaciones de alojamiento de código fuente como Bitbucket, GitHub y Launchpad realmente administran el process de bifurcación desde el repository principal, y cómo logran save el espacio en disco de su server cuando esos depósitos se bifurcan en el lado del server.

por ejemplo, si bifurco desde un repository en GitHub: ¿el código copydo en mi repository toma un espacio de disco adicional (es decir, ¿causa duplicidad de almacenamiento) desde el maestro en el server GitHub?

Gracias por adelantado.

Según esta respuesta , parece que Github, al less, no copy el repository cuando se bifurca. En cambio, crea nuevas twigs con los nombres de usuario antepuestos (por ejemplo, en lugar de master , mi twig maestra bifurcada sería referenceda como lightcc.master ).

Esto tiene mucho sentido en el context de cómo Git almacena files y hace reference a ellos y por qué es capaz de almacenar repositorys de manera tan eficiente. Si un tenedor es una copy perfecta de un repository, entonces todo lo que se necesita hacer es crear nuevas sucursales (references de seguimiento) y realizar un seguimiento de quién tiene permissions para verlos y empujar / tirar hacia / desde ellos. Si cambio un repository, pero nunca hago un cambio, mis references de seguimiento pueden estar detrás del repository de subida, pero siempre serán las mismas que las confirmaciones anteriores (a less que el repository original haga algunas cosas muy malas [tm] y reescribe su historial a través de rebase, aplastamiento, etc. a confirmaciones existentes).

En otras palabras, en el momento de una bifurcación original, no es necesario copyr ninguno de los repo originales, por lo que el único costo son los bytes necesarios para crear las nuevas references de seguimiento, que son ~ 40 bytes por cada bifurcación existente. Y puede que incluso no sea capaz de hacer nuevas references hasta que realmente se aparte del repository original (o hasta que configure una reference de seguimiento y la coloque en su bifurcación para una bifurcación determinada, entonces ¿probablemente el maestro es automático?).

Teniendo en count los comentarios, parece que esto es lo que hace Github, y por lo tanto el acto de Gitlab de replicar realmente el repository (por la respuesta de 0xcaff) es más parecido a una horquilla de Unix donde se crea un process duplicado. Github, de una manera muy ágil, quiere esperar hasta el último momento posible para crear objects nuevos debido a un tenedor realmente divergente del repository original.

Esta es la razón por la cual Github tiene algunas reglas para separar por completo un tenedor de un repository original, y por qué el soporte debe estar involucrado. Si lo hace, les costará espacio de almacenamiento y si permiten que todos lo hagan de manera fácil y gratuita, podría costarles mucho espacio de almacenamiento, etc., a lo largo del time.

Esta es una buena pregunta y me hizo preguntarme lo mismo.

Gitlab

Afortunadamente, hay una herramienta de administración de repository git de código abierto llamada gitlab que podemos ver.

En gitlab-shell , la function fork_project maneja bifurcación. Después de verificar si los parameters aprobados son válidos, se ejecuta la siguiente línea:

 cmd = %W(git clone --bare -- #{full_path} #{full_destination_path}) system(*cmd) && self.class.create_hooks(full_destination_path) 

Entonces, GitLab simplemente clona el repository, duplicando el código fuente.

preguntas relacionadas

  • ¿Los git bifes realmente son clones?
  • ¿Cuál es la diferencia entre Forking y Cloning en GitHub?