Guia de Git do Beej

 (beej.us)
1 pontos por GN⁺ 2025-02-06 | 1 comentários | Compartilhar no WhatsApp
  • Uma página de guia que oferece versões distribuídas em HTML e PDF em vários formatos para leitores que querem aprender ou consultar Git
  • O próprio guia parte do princípio de que pode conter erros, e sugestões de correção sobre conteúdo incorreto de Git são recebidas por e-mail
  • As versões em HTML podem ser escolhidas de acordo com o ambiente de leitura: dividida, página única, widescreen, ZIP etc.
  • Os PDFs podem ser baixados em combinações de US Letter e A4, frente única e frente e verso, com destaque de sintaxe ou em preto e branco
  • Tradutores e autores podem clonar todo o material no GitHub e seguir o README para trabalhar nele

Formatos de distribuição para leitura

Sugestões de correção e materiais-fonte para trabalho

  • O guia reconhece a possibilidade de conter erros e recebe sugestões de correção por e-mail
  • Tradutores e autores podem clonar o repositório no GitHub e seguir o README

Leituras relacionadas

1 comentários

 
GN⁺ 2025-02-06
Comentários do Hacker News

  • Se encontrarem algo errado, mandem. Eu mesmo organizo e corrijo — Beej

    • Não está errado, mas, se for abordar vim no contexto do Git, vale incluir também :cq. Ele sai com um status de encerramento diferente de 0, o que pode impedir o Git de concluir o commit ou a operação
    • Trabalho realmente excelente, e obrigado por criar um material tão abrangente. Não li tudo, mas a formulação da seção 5.1 me chamou a atenção
      Em https://beej.us/guide/bggit/html/split/branches-and-fast-for..., diz que “o branch padrão é main” e que “antigamente era master, e repositórios antigos ainda têm master”, mas isso não está correto. O Git ainda usa master como padrão, apenas permitindo que isso seja alterado para futuros git init via git config --global init.defaultBranch
      Fonte: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
      Além disso, a expressão “repositórios antigos” passa a mensagem errada. Foi o GitHub que decidiu essa mudança, outros lugares acompanharam, e o próprio Git passou a permitir a configuração acima; não é uma questão de repositórios novos/antigos, mas mais uma questão de preferência
    • Fui um dos inúmeros alunos que aprenderam na Lambda School, e aquela aula foi um dos momentos mais marcantes para mim
    • Li o guia de programação em C quando era adolescente e, hoje, como desenvolvedor de firmware, ainda sinto que devo muito a ele
    • Não está errado, mas git worktree também vale ser mencionado. Foi essencial no meu fluxo de trabalho, e muita gente nem sabe que existe
      É uma boa forma de manter branches sem se embolarem entre si, sem o incômodo de lidar com stash

  • Beej's Guide to Network Programming e Beej's Guide to Unix IPC, que li quando era adolescente, eram acessíveis e ao mesmo tempo profundos, e tiveram grande influência no tipo de programador que eu me tornei depois
    [0] https://beej.us/guide/bgnet/
    [1] https://beej.us/guide/bggit/

    • [1] é https://beej.us/guide/bgipc/
    • Comigo foi parecido. Eu era adolescente em meados dos anos 90 e fiquei fascinado com código de servidores IRCd e bots
      Comprei de segunda mão um Slackware Linux Unleashed que vinha com CD-ROM, e ele tinha exemplos de networking em C; aqueles códigos me deixaram confuso, o que me levou a encontrar o site de networking do Beej. A partir daí me aprofundei ainda mais, entrando numa toca de coelho enorme, e eu vivia indo a várias livrarias atrás de livros de programação
      Depois que comprei o excelente livro de referência do Richard Stevens, não olhei mais para trás, e até hoje sou grato ao Beej por ter ajudado a tornar essa paixão possível
    • Lembro que, na época em que estava aprendendo a usar select, traduzi o guia de redes do Beej para o italiano porque queria deixar algum port scanner — talvez “grabb”? — mais rápido. Bons tempos
    • Vim conferir se era a mesma pessoa e, ao ver aquele design antigo da web em que cada página tinha personalidade, fiquei quase convencido
      Era a época em que eu salvava páginas para ler offline para meu pai não ficar bravo com a conta de telefone, e quando o código funcionava parecia uma validação que superava fracassos e rejeições anteriores da vida. Havia uma alegria enorme em enviar mensagens de um computador para outro

  • Ao ver “comando antigo: git checkout”, eu nem sabia que existia git switch, nem que git checkout era considerado uma alternativa antiga. Me senti velho
    Faz quase 10 anos que comecei a aprender Git, então vá lá, mas é estranho pensar que alguém aprendendo Git hoje possa ficar confuso sobre por que eu uso git checkout. Parece que estou usando uma expressão antiquada
    Voltando ao texto, acho que este guia teria sido muito útil quando eu estava aprendendo. É fácil de acompanhar e aborda bem as perguntas comuns
    Também guardo com carinho a lembrança de ter me assustado com meu primeiro conflito de merge, desistido, e depois dado voltas para evitar conflitos

    • git switch é um comando relativamente novo e foi lançado pela primeira vez em 2019
      Há uma discussão de 2021 e outra de algumas semanas atrás; nesta última, também é mencionado que, na documentação, git switch ainda é considerado um recurso experimental
      https://news.ycombinator.com/item?id=28024972
      https://news.ycombinator.com/item?id=42649858
    • Eu não diria que git checkout ainda é visto como uma “alternativa antiga”. Da última vez que verifiquei, switch ainda era experimental, e eu nem cogitei sair do fluxo de trabalho e dos comandos que aprendi quando comecei a usar Git, há cerca de 15 anos
      Tudo que quero fazer ainda funciona exatamente igual, git checkout continua fazendo as mesmas coisas de antes, e não tenho problemas para colaborar com outras pessoas usando Git; então não vejo motivo para mudar meu fluxo de trabalho

  • O simples fato de ser necessário um guia com mais de 30 partes explicando como usar Git já faz parecer que o Git perdeu de vista o panorama geral

    • Não entendo por que programadores ficam tão furiosos com o fato de uma ferramenta complexa, que faz coisas complexas sobre estruturas de dados complexas, ter certo grau de complexidade
    • Se as pessoas usassem para aprender Git metade do esforço que usam para reclamar dele, talvez nem fosse preciso criar um guia com mais de 30 partes para explicar coisas que podem ser encontradas nas páginas de manual
      Commits são snapshots de uma árvore e têm uma lista de ancestrais. Normalmente é um, mas nem sempre. Tags são rótulos imutáveis para commits, e branches são rótulos mutáveis para commits. O índice é um pequeno proto-commit em andamento que você preenche com add antes de fazer o commit
      Isso é Git. Se quiser saber mais, não leia um guia; pesquise coisas como “como mudar para um commit específico do Git sem afetar a árvore”, “como commitar apenas alguns dos arquivos alterados”, “como copiar commits de outro lugar para a árvore atual”
      As abstrações básicas são minimalistas e fáceis. O que você quer fazer com essas abstrações é que é sofisticado e complexo. Aprenda as primeiras e pesquise o segundo; não precisa ler um guia
    • O uso do Git pode ser explicado em 5 linhas de comentário no HN: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
    • Ainda assim, dá para dar um tiro no próprio pé
    • Sim e não. Os comandos voltados ao usuário do Git provavelmente são bons o bastante para 95% dos usuários
      rebase -i vem com instruções sobre o que cada comando faz, e bastam alguns parágrafos para explicar como formatar a saída de git log conforme preferências e compromissos. Em geral, considero que os comandos voltados ao usuário também incluem coisas bem variadas como git gc, git fsck e git rev-parse
      Os comandos de baixo nível são definitivamente mais obscuros e, por si só, fazem muitas coisas que nem sempre são fáceis de realizar com comandos voltados ao usuário otimizados para casos de uso comuns
      Em resumo, o Git é grande, até gigantesco, mas para a maioria dos desenvolvedores uma parte considerável do que ele oferece fica longe do caminho principal

  • O assustador é o guia ser tão longo assim
    Sei que os guias do Beej em geral são abrangentes, mas eu não tinha uma noção real da enorme quantidade de sutilezas do Git até ver isso
    Com Jujutsu, acho que seria um guia muito mais fino, ou pelo menos um guia em que uma pessoa conseguiria descobrir e aprender as coisas com mais facilidade

    • Tento fazer meus guias de modo que a pessoa possa parar de ler quando sentir que já leu o suficiente. Não é preciso ler tudo
      Sinto que este guia cobre só uns 10% do Git, mas espero que cubra 90% do uso comum
    • Este guia pende para o lado abrangente; no extremo oposto, há uma folha de uma página com 90% dos comandos Git de que você vai precisar no futuro: https://wizardzines.com/git-cheat-sheet.pdf
    • Parece um sinal de que o Git não é a ferramenta certa para a maioria, mas acabou se cristalizando como padrão por acaso

  • No trabalho, uma ou duas vezes por ano, conduzo um curso de 2 horas de introdução ao modelo de dados do Git
    Entramos de fato no diretório .git, descompactamos arquivos e mostramos que tudo é apenas uma representação em texto puro das estruturas de dados básicas. É muito legal ver o momento em que isso encaixa na cabeça das pessoas
    Compartilhamos um documento básico de receitas de Git para que novos funcionários comecem a commitar código, mas a maioria só segue os passos sem entender o que está acontecendo
    Já quem faz a aula, mesmo sem conhecer todos os comandos, passa a ter uma compreensão prática bastante razoável do que realmente acontece no Git. Como os comandos são fáceis de pesquisar, se o modelo mental estiver correto, os comandos em si não são um grande problema. Ainda assim, quase toda discussão sobre Git no HN acaba virando conversa sobre linha de comando
    Curiosamente, essa aula soa parecida com o texto alternativo de https://xkcd.com/1597/. A diferença é que, para leitores técnicos, essa é de fato a maneira correta de ensinar Git, e uma vez entendido, dá uma compreensão fundamental que não se esquece
    Sinceramente, acho que o retorno sobre o tempo investido é tão alto que é estranho não fazer isso

    • Também já fiz isso uma vez e foi muito bom; a discussão que veio depois também foi excelente
      No último slide da apresentação, coloquei perguntas para os colegas responderem com base no modelo de dados do Git. Por exemplo: “é possível mover um commit para outro branch?” e “o que garante que não haja ciclos no grafo de commits?”
      Foi muito satisfatório ver as pessoas não apenas usando Git, mas pensando em Git
    • A frase “se o modelo mental estiver correto, os comandos não são um grande problema” no começo teria soado para mim como aquela lógica comum nos anos 90 de que “usar Linux é fácil se você entender todas as camadas e todas as partes do Linux”. Em teoria está certo, mas para a maioria parece algo inviável na prática
      Felizmente, no início vi um vídeo explicando parte do modelo interno do Git e percebi que, na prática, não é preciso ter tanto conhecimento interno nem tão profundo para fazer uma grande diferença. Só saber uns 5% de como o Git funciona já me fez entender muito melhor o que os comandos fazem e como usá-los
    • Fico curioso se você poderia compartilhar o material ou a gravação desse curso de 2 horas, caso não haja informações proprietárias nem restrições que impeçam a divulgação
      Se ele foi baseado em algum material público e conciso o bastante para caber em 2 horas, seria ótimo se você compartilhasse nesta thread ou em um post no HN. Acredito que, mesmo sobre o mesmo tema, quanto mais materiais de aprendizagem com pressupostos, analogias e focos diferentes, melhor
    • Fico curioso se há uma cópia da apresentação ou um vídeo, ou então algum material parecido que você recomende
    • Compartilhe o vídeo, por favor

  • Consigo lidar razoavelmente com o fluxo comum do Git, merges, rebases etc., mas estou pensando seriamente em migrar para jujutsu em vez de tentar ficar melhor no Git. jj é compatível com Git, e posso usá-lo sozinho enquanto meus colegas continuam usando Git

  • Sinto que há um truque que muitos guias e a maioria das GUIs de Git deixam passar. Como exceção, o magit lida bem com isso
    É definir o branch upstream não como origin/feature/foo de feature/foo, mas como o destino para o qual você quer fazer merge, ou seja, o branch de integração master ou origin/master
    Isso simplifica muita coisa. Ao executar git status, ele informa o quanto você divergiu do branch de integração, o que é útil; e, ao executar git rebase sem argumentos, ele já faz o rebase diretamente sobre o upstream
    Ter origin/feature/foo como upstream é menos útil. Em geral, os desenvolvedores também “possuem” seu próprio branch remoto, então saber o quanto ele divergiu dali não tem muito significado, e você também não costuma querer fazer rebase para ele
    Se definir push.default como "current", o git push também faz o esperado: envia feature/foo para origin/feature/foo
    Fico me perguntando por que essa configuração não é mais comum

  • A seção de colaboração não trata de branches de funcionalidade. Acho que é um fluxo de trabalho bastante comum
    Seria útil contrastá-lo com o modo “cada um usa seu próprio branch” do guia. Além disso, na seção 17, valeria abordar a forma de reutilizar branches em pull requests do GitHub e a forma de criar um branch novo para cada PR

  • Ainda não conferi o texto, mas parece bom. Outra recomendação é o curso de Git da boot.dev, ministrado pelo Primeagen
    Ele é interativo e vai fundo a ponto de manipular diretamente os arquivos dentro do diretório .git. Depois de fazer esse curso, passei a ter um modelo mental completamente novo de como o Git funciona