¿Cómo se diseñó Git?

Mi lugar de trabajo recientemente cambió a Git y lo he estado amando (¡y odiando!). Realmente me encanta, y es extremadamente poderoso. La única parte que odio es que a veces es demasiado potente (y tal vez un poco breve / confuso).

Mi pregunta es ... ¿Cómo se diseñó Git? Solo usándolo por un corto período de tiempo, tiene la sensación de que puede manejar muchos flujos de trabajo oscuros que otros sistemas de control de versiones no podrían. Pero también se siente elegante debajo. ¡Y rápido!

Esto es sin duda en parte para el talento de Linus. Pero me pregunto, ¿el diseño general de git se basó en algo? He leído sobre BitKeeper pero las cuentas son escasas en detalles técnicos. La compresión, los gráficos, deshacerse de los números de revisión, enfatizar la ramificación, el escondite, los controles remotos ... ¿De dónde vino todo?

¡Linus realmente eliminó a este del parque y prácticamente en el primer intento! Es bastante bueno usarlo una vez que haya pasado la curva de aprendizaje.

Git no fue diseñado tanto como evolucionó .

Echa un vistazo por ti mismo. Clone el repositorio oficial de git , ábralo gitk(o su visor gráfico de registro de git favorito) y mire sus primeras revisiones.

Verá que originalmente solo tenía la funcionalidad principal (la base de datos de objetos y el índice). Todo lo demás se hizo a mano . Sin embargo, este pequeño núcleo fue diseñado para automatizarse fácilmente a través de scripts de shell. Los primeros usuarios de git escribieron sus propios scripts de shell para automatizar tareas comunes; Poco a poco, estos scripts se incorporaron a la distribución de git (ver un ejemplo anterior 839a7a0 ). Cada vez que había una nueva necesidad, los scripts se adaptaban para permitirlo. Mucho más tarde, varios de estos scripts se reescribieron en C.

Esta combinación de un núcleo ortogonal limpio (que aún puede usar directamente si lo necesita), con una capa superior que creció orgánicamente sobre ella, es lo que le da a git su poder. Por supuesto, también es lo que le da la gran cantidad de comandos y opciones con nombres extraños.

La compresión, los gráficos, deshacerse de los números de revisión, enfatizar la ramificación, el escondite, los controles remotos ... ¿De dónde vino todo?

Mucho de eso no estaba allí al principio.

Si bien cada objeto se comprimió individualmente y se evitaron los duplicados al nombrarlos, los archivos de "paquete" que son responsables de la alta compresión que estamos acostumbrados a ver en git no existían. La filosofía al principio era "el espacio en disco es barato".

Si por "los gráficos" te refieres a espectadores gráficos como gitk, aparecieron más tarde (AFAIK, el primero fue gitk). AFAIK, BitKeeper también tenía un visor gráfico de historia.

Deshacerse de los números de versión, de hecho, el concepto central de git de usar un sistema de archivos con contenido para almacenar los objetos, en su mayoría provino de monótono . En ese momento, la monotonía era lenta; Si este no fuera el caso, es posible que Linus lo hubiera usado en lugar de crear git.

Enfatizar la ramificación es algo inevitable en un sistema de control de versiones distribuido, ya que cada clon actúa como una rama separada.

Stashing ( git stash) es, IIRC, bastante reciente. Los reflogs, que utiliza, no estaban allí al principio.

Incluso los controles remotos no estaban allí inicialmente. Originalmente, copiaste los objetos a mano usando rsync.

Una por una, cada una de estas características fue agregada por alguien. No todos, tal vez ni la mayoría, fueron escritos por Linus. Cada vez que alguien siente una necesidad que git no satisface, uno puede crear una nueva característica sobre la capa principal de "plomería" de git y proponerla para su inclusión. Si es bueno, probablemente será aceptado, mejorando aún más la utilidad de git (y la complejidad de su línea de comando).

Creo que el punto principal es simplemente que git fue diseñado por la persona más calificada del planeta para hacerlo. Y no estoy hablando de talento, estoy hablando de experiencia: dudo que haya alguien más que haya estado a cargo de una base de código con una combinación comparable de tamaño y número de contribuyentes como el kernel de Linux y que aún se ocupa de la mayor parte de la integración trabajar solo.

Entonces Linus conocía los requisitos y los casos de uso para un sistema de control de versiones distribuido mejor que nadie. Y, por supuesto, ayudó que la mayor parte de la codificación que estaba tratando estaba en C, y gran parte de ella era crítica para el rendimiento.

Básicamente es el mejor ejemplo de rascarse la propia picazón.

Fue diseñado exactamente como se describe en The Git Parable .

Imagine que tiene una computadora que no tiene nada más que un editor de texto y algunos comandos del sistema de archivos. Ahora imagine que ha decidido escribir un gran programa de software en este sistema. Debido a que es un desarrollador de software responsable, decide que necesita inventar algún tipo de método para realizar un seguimiento de las versiones de su software para que pueda recuperar el código que previamente cambió o eliminó. Lo que sigue es una historia sobre cómo podría diseñar uno de esos sistemas de control de versiones (VCS) y el razonamiento detrás de esas opciones de diseño.