Retrospectiva dos 20 anos do Git – ainda estranho, ainda incrível

• O Git é um sistema de controle de versão que começou há 20 anos, quando Linus Torvalds fez o primeiro commit
• Originalmente era apenas um projeto pessoal simples, mas depois cresceu e se tornou o sistema de controle de versão mais usado no mundo
• O autor é cofundador do GitHub e esteve profundamente envolvido na evolução do Git ao construir livros e a comunidade relacionados ao Git
• No início, era uma ferramenta simples de gerenciamento de conteúdo de diretórios, mas hoje se tornou uma ferramenta central que mudou a forma de desenvolver software

A filosofia e a necessidade do Git

• O Git nasceu da insatisfação da comunidade do kernel Linux com as limitações das ferramentas de controle de versão existentes
• A forma de colaboração existente na época era distribuída e baseada em regiões, usando mailing lists, tarballs e arquivos patch
• Como as ferramentas de SCM da época eram lentas, centralizadas e ineficientes, a abordagem baseada em tarball/patch era melhor
• Havia uma alternativa chamada Bitkeeper, mas problemas de licença levaram ao início do desenvolvimento do Git
• Desde o começo, o Git não foi projetado como um "sistema de controle de versão", e sim como uma estrutura de dados para lidar melhor com patches e tarballs

O primeiro commit do Git

• O primeiro commit era uma ferramenta muito básica de rastreamento de conteúdo de diretórios
• Na época, as ferramentas não eram comandos como git commit, mas utilitários de banco de dados de baixo nível como write-tree e commit-tree
• Desde o início, o Git já tinha recursos como:
  • salvar o diretório de trabalho no cache (update-cache) e transformá-lo em um objeto de árvore (write-tree) para gravá-lo no banco de dados
  • armazenar mudanças na forma de commit (commit-tree) para criar histórico
  • ler e comparar objetos do banco de dados com cat-file, read-tree e show-diff
• Linus via o Git apenas como uma "ferramenta de encanamento (plumbing)" de backend e queria que a UI fosse criada externamente

Caso de uso do Git para distribuição de conteúdo

• Em 2005, o autor usou o Git na startup Reactrix para distribuir conteúdo de publicidade digital
• Centenas de telas digitais precisavam ter combinações diferentes de anúncios, e o endereçamento por conteúdo do Git resolveu isso de forma eficiente
• Foi um caso criativo de uso do Git não para gerenciar código, mas como ferramenta de distribuição de conteúdo
• Nick Hengeveld, um dos principais contribuidores do projeto Git inicial, adicionou recursos como SSL e transferência HTTP paralela
• Essa experiência levou à criação de documentação, site e livros sobre Git, e acabou se conectando ao surgimento do GitHub

A evolução dos comandos do Git e das ferramentas para usuários

• Nos primeiros tempos, todos os comandos do Git eram ferramentas de baixo nível baseadas em scripts, bem diferentes do que são hoje
• Comandos como git log, git rebase e git commit também começaram como simples scripts shell e foram evoluindo gradualmente até chegar ao formato atual

A versão inicial de git log

• git log era um script simples no formato git-rev-list --pretty HEAD | less
• rev-list é uma ferramenta para exibir IDs de commit que ainda existe hoje

O surgimento do git rebase

• O conceito de rebase nasceu em 2005 em uma troca de e-mails entre Linus e Junio Hamano
• A forma de trabalhar de Junio consistia em descartar o HEAD existente e continuar o trabalho com base em um novo HEAD, e isso foi descrito como "rebase"
• Isso evoluiu para o comando git rebase como o conhecemos hoje

A origem do Octocat

• O Octocat, símbolo do GitHub, teve sua ideia inspirada na estratégia de "octopus merge" do Git
• A estratégia de mesclar vários branches ao mesmo tempo era chamada de "octopus", e nos primeiros dias do GitHub essa palavra inspirou a criação do personagem Octocat

O presente e o futuro do Git

• O autor ainda usa o Git para seu propósito original, como um "stupid content tracker"
• O projeto GitButler está usando o Git como forma de rastrear e registrar o histórico de projetos
• O Git continua sendo um sistema poderoso de rastreamento de conteúdo e distribuído, com potencial para seguir sendo usado de diversas maneiras no futuro

• Feliz aniversário, Git. Ainda estranho, ainda incrível

[aobamisaki]

Feliz 20º aniversário, Git.

[bobross0]

Parabéns

[girr311]

Feliz aniversário. Ouça bem o que o tio diz e viva por muito, muito tempo com saúde.

[kaistj]

Feliz aniversário ^^

[crawler]

Que post estranhamente empolgante, hein.

[GN⁺]

Comentários do Hacker News

• A narrativa sobre as origens do Git tende a retratar Linus quase como um profeta

  • O post do blog destaca o lado humano de Linus e menciona os erros e tentativas do começo
  • O Mercurial também teve um papel importante, mas muitas vezes é ignorado
  • O Mercurial já tinha UI desde o início e era mais amigável por ter uma interface semelhante à do Subversion
  • A estrutura de dados do Git não é adequada para arquivos muito grandes
  • Não acho que o Git fosse inevitável e espero que surjam novas alternativas

• Por volta de 2002, tive a ideia de marcar cada parte de um projeto com um código hash exclusivo

  • Propus isso a uma empresa de software, mas não houve interesse

• Comecei a usar Git como alternativa ao ClearCase

  • Comecei a usar Git por volta de 2007 e escrevi scripts para contornar a falta de praticidade do ClearCase
  • Em 2008, comecei a contribuir com patches para o Git e aprendi muito sobre contribuição em código aberto
  • Apesar da CLI complexa do Git, não tive dificuldade para usá-lo
  • No emprego seguinte, trabalhei com base em um fork do Chromium e fiquei bom em resolver conflitos de merge usando Git
  • Fiquei decepcionado por o GitHub ter se tornado a principal ferramenta de code review do Git, mas ainda acho que Git foi uma escolha melhor que Mercurial

• É surpreendente que o Git tenha apenas 20 anos

  • Não surpreende que o GitHub tenha menos de 20 anos, mas é chocante que o Git não existisse antes de 2005
  • Nunca usei outras opções de controle de código-fonte e me pergunto se algum dia usarei

• Foi interessante conhecer o contexto histórico

  • O ClearCase também usava o termo "rebase", e é possível confirmar seu uso desde 1999
  • O rebase do ClearCase demorava muito, então o rebase instantâneo do Git foi impressionante

• Eu queria criar uma ferramenta eficiente de banco de dados de histórico de tarballs, não tinha a intenção de criar um sistema de controle de versão

• Descobri que é possível assinar commits com chaves ssh

  • Usei assinatura com ssh para resolver um problema no OpenBSD
  • Não parece que já se passaram 20 anos desde que migramos itens de trabalho do CVS para o Git

• Obrigado pelo artigo útil; recomendo um repositório que inclui uma introdução à estrutura interna do Git

• Achei interessante a ideia de querer escrever um post de blog sobre colaboração por mailing list

• Entre vários sistemas de controle de código-fonte, o Git é o pior em usabilidade, mas ainda é o meu favorito