Como o Git foi projetado?

Meu local de trabalho recentemente mudou para o Git e eu o amo (e odeio!). Eu realmente amo isso, e é extremamente poderoso. A única parte que eu odeio é que às vezes é muito poderoso (e talvez um pouco conciso / confuso).

Minha pergunta é ... Como o Git foi projetado? Ao usá-lo por um curto período de tempo, você tem a sensação de que ele pode lidar com muitos fluxos de trabalho obscuros que outros sistemas de controle de versão não podiam. Mas também parece elegante por baixo. E rápido!

Isso não tem dúvida em parte do talento de Linus. Mas eu estou pensando, o design geral do git foi baseado em alguma coisa? Eu li sobre o BitKeeper, mas as contas são escassas em detalhes técnicos. A compressão, os gráficos, a eliminação de números de revisão, enfatizando ramificações, esconderijas, controles remotos ... De onde tudo isso veio?

Linus realmente tirou essa do parque e praticamente na primeira tentativa! É muito bom usá-lo quando você passa pela curva de aprendizado.

O Git não foi projetado tanto quanto evoluiu .

Dê uma olhada sozinho. Clone o repositório oficial do git , abra-o gitk(ou seu visualizador gráfico favorito do git) e veja as primeiras revisões.

Você verá que originalmente tinha apenas a funcionalidade principal (o banco de dados de objetos e o índice). Todo o resto foi feito à mão . No entanto, esse pequeno núcleo foi projetado para ser facilmente automatizado via script de shell. Os primeiros usuários do git escreveram seus próprios scripts de shell para automatizar tarefas comuns; pouco a pouco, esses scripts foram incorporados à distribuição git (veja o exemplo 839a7a0 ). Sempre que havia uma nova necessidade, os scripts eram adaptados para permitir isso. Muito mais tarde, vários desses scripts seriam reescritos em C.

Essa combinação de um núcleo limpo e ortogonal (que você ainda pode usar diretamente, se necessário), com uma camada superior que cresceu organicamente sobre ele, é o que dá ao git seu poder. Obviamente, é também o que fornece a grande quantidade de comandos e opções de nomes estranhos.

A compressão, os gráficos, a eliminação de números de revisão, enfatizando ramificações, esconderijas, controles remotos ... De onde tudo isso veio?

Muito disso não estava lá no começo.

Enquanto cada objeto foi compactado individualmente e as duplicatas foram evitadas por seus nomes, os arquivos "pack", responsáveis ​​pela alta compactação que estamos acostumados a ver no git, não existiam. A filosofia no começo era "espaço em disco é barato".

Se por "gráficos" você quer dizer visualizadores gráficos gitk, eles apareceram mais tarde (AFAIK, o primeiro foi gitk). AFAIK, BitKeeper também teve um visualizador de histórico gráfico.

Livrar-se dos números de versão, na verdade, o conceito principal do git de usar um sistema de arquivos endereçado a conteúdo para armazenar os objetos, veio principalmente de monotonia . Naquela época, monótono era lento; se não fosse esse o caso, é possível que o Linus o tivesse usado em vez de criar o git.

Enfatizar a ramificação é um tanto inevitável em um sistema de controle de versão distribuído, pois cada clone atua como uma ramificação separada.

O esconderijo ( git stash) é, IIRC, bastante recente. Os reflogs, que ele usa, não estavam lá no começo.

Mesmo controles remotos não estavam lá inicialmente. Originalmente, você copiava os objetos manualmente usando rsync.

Um por um, cada um desses recursos foi adicionado por alguém. Nem todos eles - talvez nem mesmo a maioria deles - foram escritos por Linus. Toda vez que alguém sente uma necessidade que o git não atende, pode-se criar um novo recurso na camada "encanamento" principal do git e propor a inclusão. Se for bom, provavelmente será aceito, aprimorando ainda mais a utilidade do git (e sua complexidade da linha de comando).

Eu acho que o ponto principal é simplesmente que o git foi projetado pela pessoa mais qualificada do planeta para fazer isso. E não estou falando de talento, estou falando de experiência: duvido que haja alguém que tenha sido responsável por uma base de código com uma combinação comparável de tamanho e número de colaboradores como o kernel do Linux e ainda esteja lidando com a maior parte da integração trabalhar a si mesmo.

Portanto, Linus conhecia os requisitos e os casos de uso de um sistema de controle de versão distribuído melhor do que qualquer outro. E, é claro, ajudou o fato de que a maior parte da codificação que ele estava lidando era em C, e grande parte do desempenho era crítica.

Basicamente, é o melhor exemplo de coçar a própria coceira.

Ele foi projetado exatamente como descrito em The Git Parable .

Imagine que você tem um computador que não possui nada além de um editor de texto e alguns comandos do sistema de arquivos. Agora imagine que você decidiu escrever um grande programa de software neste sistema. Como você é um desenvolvedor de software responsável, decide que precisa inventar algum tipo de método para acompanhar as versões do seu software, a fim de recuperar o código que alterou ou excluiu anteriormente. A seguir, é apresentada uma história sobre como você pode criar um desses sistemas de controle de versão (VCS) e o raciocínio por trás dessas opções de design.