git - ¿Qué es un repositorio simple y por qué necesitaría uno?

github git-bare

Question

Quizás esto haya sido respondido, pero no encontré una buena respuesta.
Vengo de repositorios centralizados, como SVN, donde generalmente solo realiza pagos, actualizaciones, confirmaciones, reversiones, fusiones y no mucho más.

Git me está volviendo loco. Hay toneladas de comandos, pero lo más difícil de entender es por qué muchas cosas funcionan como lo hacen.

De acuerdo con "¿Qué es un repositorio git desnudo?" :

Los repositorios creados con git init --bare se denominan repos desnudos. Están estructurados de manera un poco diferente a los directorios de trabajo. En primer lugar, no contienen una copia funcional o extraída de sus archivos fuente.
...
Un repositorio desnudo creado con git init --bare es para ... compartir . … Los desarrolladores clonarán el repositorio descubierto compartido, realizarán cambios localmente en sus copias de trabajo del repositorio y luego volverán al repositorio compartido compartido para que sus cambios estén disponibles para otros usuarios.
- Jon Saints, http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/

Sin embargo, de la respuesta aceptada a "¿cuál es la diferencia entre el repositorio github y el repositorio git bare?" :

Los repositorios de Git en GitHub están desnudos, como cualquier repositorio remoto al que desea enviar [sic] .
- VonC, https://stackoverflow.com/a/20855207

Sin embargo, en GitHub hay archivos fuente. Puedo verlos. Si creo un repositorio simple, no hay archivos fuente, solo el contenido del directorio .git de un repositorio en funcionamiento.

¿Cómo es esto posible? ¿Qué no entiendo?

¿Puede dar un ejemplo de por qué necesitaría un repositorio simple y su motivación para trabajar de esa manera?

ACTUALIZAR

La respuesta de Edward Thomson es, en parte, lo que quería saber. Sin embargo, reformularé mi pregunta:

Primer enlace que publiqué estados ( "¿Qué es un repositorio de git desnudo?" ):

ellos [repositorios desnudos] no contienen ninguna copia funcional o extraída de sus archivos fuente.

La respuesta de VonC:

Los repositorios de Git en GitHub están desnudos

Ambas declaraciones implican

Github no tiene copia de trabajo.

Edward Thomson dice:

renderiza la página web en función de los datos a medida que navega por ella: extrae los datos directamente del repositorio y los envía a su navegador web, no los escribe primero en un disco en el servidor de archivos

De alguna manera, un repositorio desnudo debe contener todos los datos y el código fuente. Si no, no sería imposible renderizar nada, porque puedo ver todo el código fuente actualizado (comprometido), todas las ramas (con su fuente respectiva), el registro completo de un repositorio, etc.

¿Hay todos los datos de un repositorio siempre dentro del directorio .git (o en un repositorio simple), en algún tipo de formato que sea capaz de representar todos los archivos en cualquier momento? ¿Es esta la razón del repositorio desnudo, mientras que la copia de trabajo solo tiene los archivos en un momento dado?

Answer 1

¿Hay todos los datos de un repositorio siempre dentro del directorio .git (o en un repositorio simple), en algún tipo de formato que sea capaz de representar todos los archivos en cualquier momento?

Sí, esos archivos y su historial completo se almacenan en .git/packed-refs y .git/refs , y .git/objects .

Cuando clona un repositorio (desnudo o no), siempre tiene la carpeta .git (o una carpeta con una extensión .git para repositorio, por convenio de denominación) con sus archivos administrativos y de control de Git. ( ver glosario )

Git puede descomprimir en cualquier momento lo que necesita con git unpack-objects .

El truco es:

Desde un repositorio simple, puede consultar los registros (el registro de git log en un repositorio simple de git funciona bien: no es necesario un árbol de trabajo), o enumerar archivos en un repositorio vacío .
O muestre el contenido de un archivo de un repositorio desnudo .
Así es como GitHub puede renderizar una página con archivos sin tener que pagar el repositorio completo .

Sin embargo, no sé si GitHub hace exactamente eso, ya que la gran cantidad de repositorios obliga al equipo de ingeniería de GitHub a hacer todo tipo de optimización.
Vea, por ejemplo, cómo optimizaron la clonación / recuperación de un repositorio .
Con DGit , esos DGit desnudos se replican en varios servidores.

¿Es esta la razón del repositorio desnudo, mientras que la copia de trabajo solo tiene los archivos en un momento dado?

Para GitHub, mantener un árbol de trabajo costaría demasiado en espacio en disco y en actualización (cuando cada usuario solicita una rama diferente). Es mejor extraer del repositorio desnudo único lo que necesita para representar una página.

En general (fuera de la restricción de GitHub), se utiliza un repositorio simple para empujar, a fin de evitar que un árbol de trabajo no esté sincronizado con lo que se acaba de empujar . Consulte " pero ¿por qué necesito un repositorio simple? " Para obtener un ejemplo concreto.

Habiendo dicho eso:

• desde git 2.3 podría pasar a un repositorio no descubierto (que actualizaría el árbol de trabajo en consecuencia)
• desde git 2.4, puede "presionar para desplegar" (es decir, también funciona para la rama no nacida )

Pero eso no sería posible para GitHub, que no puede mantener uno (o servidor) árbol (s) de trabajo para cada repositorio que tiene que almacenar.