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   , 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: anteriormente    - um animal fofo, cat    — como as pessoas costumavam ouvir música e cd    —algumas onomatopeias, grep  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   - 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. armazena tudo  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   que é recomendado para mudar de branch. A maneira que estou acostumado a fazer (   + 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. git switch git checkout  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   . E o ID completo é   . 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: 0828ae1 0828ae10b20500fbc777cc40aa88feefd123ea5e  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,   na máquina, qualquer exploração de segurança seria extremamente perigosa. executado  É 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   ). Naquela época, eu usava   no trabalho, e o   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. Thu Apr 7 15:13:13 2005 -0700 SVN Mercurial  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   para receber atualizações sobre meu conteúdo focado no Git. aqui  Publicado também   . aqui

Different

Keep

Mind

Super

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Learning

2022 - the Greatest Storyteller

Newsletter

Senior JS developer

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Por que o Git é tão complicado

Por que o Git é tão complicado

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Uma breve introdução à teoria do cérebro de Boltzmann

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Uma breve introdução à teoria do cérebro de Boltzmann

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps