Por que o Git é tão complicado

Quando você aprende a programar, as pessoas geralmente recomendam aprender Git. Em teoria, parece fácil: um programa para rastrear alterações em seu código que o ajuda a restaurar versões anteriores do código quando você precisar delas. Além disso, é uma ferramenta utilizada em quase todos os setores da indústria. Na prática… Git pode ser confuso para dizer o mínimo.

Por que tem que ser dessa maneira?

Interface de linha de comando — CLI

A maioria dos usuários comuns de computadores não está acostumada ao luxo de interfaces baseadas em texto. Eu chamo isso de luxo porque, como escrevi anteriormente , há algumas grandes vantagens nisso - embora possa levar algum tempo para se acostumar com a experiência do usuário. Portanto, se suas associações corresponderem às da lista:

• cat - um animal fofo,
• cd — como as pessoas costumavam ouvir música e
• grep —algumas onomatopeias,

então é provável que sua primeira experiência com o Git tenha a dificuldade adicional de aprender o básico da linha de comando. Algo que o Windows 95 e seus semelhantes tiraram de você.

Objetivos de design do Git

O Git nunca foi feito para ser simples. Foi feito com diferentes objetivos em mente: mais importantes e mais desafiadores também.

Armazenando com segurança os dados salvos

O objetivo do Git é sempre devolver os dados exatamente como foram salvos OU informar que o repositório está corrompido. E ele faz um trabalho incrível com isso - você pode ter certeza de que o estado obtido ao verificar um commit é exatamente como o autor pretendia que fosse. Claro, isso pressupõe que eles sabiam o que estavam fazendo.

Como o Git consegue uma segurança de dados tão boa? Ele faz isso da maneira inteligente como armazena tudo - os commits, pastas e arquivos. Cada objeto é identificado por um hash criptográfico de seu conteúdo – um número gerado com base no conteúdo do objeto, que mudará se algo dentro dos arquivos for alterado. Como as referências entre os objetos também são hash, quase não há como adulterar um repositório sem que o Git perceba que algo está errado. E mesmo nesses casos, o código significativo seria substituído por um texto longo sem sentido.

Trabalhe em redes não seguras e com participantes não confiáveis

Como tudo é identificado por hashes criptográficos, o Git não precisa confiar muito na rede para manter os dados intactos. O Git é protegido contra ataques man-in-the-middle: não há como alguém injetar código significativo entre dois nós do Git. Claro, se alguém pode ler commits que não deveriam, isso também é um problema, mas com consequências menos perigosas do que os invasores injetando código na base de código.

Para uma camada extra de segurança, o Git oferece assinatura de commits - um meio adicional de garantir que o commit foi criado pela pessoa definida como seu autor.

Mantendo a compatibilidade com versões anteriores

A interface do Git é mais complicada do que deveria ser porque respeita os velhos hábitos de seus usuários. Aprendi Git em 2011, e até semana passada não tinha notado que havia um novo comando git switch que é recomendado para mudar de branch. A maneira que estou acostumado a fazer ( git checkout + vários sinalizadores) ainda está funcionando bem. O Git prioriza usuários mais antigos e seus hábitos em detrimento da simplicidade para usuários mais novos, o que nos leva ao próximo ponto.

Experiência do usuário para superusuários

O Git é uma ferramenta feita pensando nos superusuários. Ele foi escrito por Linus Torvalds para gerenciar a base de código do Linux - não é uma tarefa para iniciantes. Os principais usuários do Git desenvolvem sistemas operacionais, têm décadas de experiência em programação e vivem dentro da linha de comando. Todos os usos além disso são acidentais e não são a principal preocupação das pessoas que desenvolvem o Git.

Compensações de simplicidade

Quando você projeta sistemas, nada é de graça - simplicidade para os usuários incluídos.

Escondendo a complexidade

Quando você está lidando com um problema inerentemente complexo, você facilita as soluções ao abstrair a complexidade. Acabou? Não, é apenas escondido do usuário. Por exemplo, no caso de conexão com a internet, eu e a maioria entendemos a qualidade da conexão apenas como número de barras em 📶:

• menos é ruim
• mais é bom

Isso é suficiente para usar a Internet, mas dificulta a compreensão e a solução de problemas de conexão.

O Git está focado em expor toda a complexidade que acompanha a alteração de arquivos em paralelo e a sincronização de maneira assíncrona. Na extremidade oposta, você tem acesso direto ao disco compartilhado. É fácil de usar, mas o que acontecerá quando duas pessoas tentarem editar o mesmo arquivo ao mesmo tempo? Um terá sorte e manterá suas mudanças, e o outro perderá tudo. Não é um bom fluxo de trabalho, especialmente se as alterações perdidas valerem horas de trabalho caro. Como o Git expõe ao usuário todos os problemas que podem surgir nessa situação, ele possibilita resolver conflitos em arquivos de forma inteligente — o que em alguns casos exige que o usuário o faça manualmente.

Fácil x seguro

Outra parte do Git que confunde os usuários são os IDs de commit que são muito longos, bem como números impossíveis de memorizar. Mesmo na forma abreviada e amigável, eles se parecem com 0828ae1 . E o ID completo é 0828ae10b20500fbc777cc40aa88feefd123ea5e . Em vez disso, poderíamos ter apenas números em ordem ou usar apenas nomes de ramificação? O problema é que os IDs de commit são hashes que garantem a integridade dos dados - eles garantem que o commit X na minha máquina é o mesmo que o commit X remoto ou na sua máquina. E as incompatibilidades entre eles podem aparecer por diferentes motivos:

• intencional - rebase, emenda, esmagamento ou qualquer outra operação que altere o histórico
• não intencional - um erro ou um ataque à base de código

Simplificar a interface e ocultar o formulário de ID de confirmação do usuário removeria a possibilidade de o usuário entender o que está acontecendo na base de código que está executando em sua máquina. E como o código é, por definição, executado na máquina, qualquer exploração de segurança seria extremamente perigosa.

É este o caminho certo?

Quando eu estava aprendendo Git, ainda era uma novidade - eu estava aprendendo em 2011, e o Git foi criado em 2005 (o primeiro commit é de Thu Apr 7 15:13:13 2005 -0700 ). Naquela época, eu usava SVN no trabalho, e o Mercurial era frequentemente considerado uma alternativa mais amigável ao Git. Você ouviu esses nomes recentemente? Git dominou o mercado de controle de versão quase completamente. Ele ganhou muita popularidade com o surgimento do GitHub, mas mesmo que seja difícil para iniciantes, é uma ferramenta muito eficiente e veio para ficar.

O que fazer como programador iniciante?

Meu conselho é aprender mais cedo ou mais tarde. É altamente improvável que o Git logo se torne mais simples. Ou nunca. Os sistemas de controle de versão em geral evitam muitas dores de cabeça enquanto você programa. Não consigo imaginar ser eficiente ao trabalhar com código se você luta para mover as versões de sua base de código. Aprender bem o Git ajudará você a se concentrar nos desafios do código, em vez de lutar com arquivos perdidos ou corrigir os chamados “problemas do Git” – que quase sempre são apenas pessoas bagunçando seus próprios repositórios.

Além disso, aprender Git tornou-se um rito de passagem para novos desenvolvedores. Como desenvolvedor, você precisa usá-lo, e o Git tornará sua vida miserável se você tentar usá-lo sem entendê-lo bem. A escolha inteligente é aprender em seus termos e não esperar até que o feedback do revisor ou os problemas de código o forcem a aprender enquanto lida com outras responsabilidades ao mesmo tempo.

Como aprender mais?

Se você estiver interessado em aprender mais sobre o Git, inscreva-se aqui para receber atualizações sobre meu conteúdo focado no Git.