{"id":118622,"date":"2024-07-30T09:43:00","date_gmt":"2024-07-30T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46"},"modified":"2024-07-30T09:43:00","modified_gmt":"2024-07-30T07:43:00","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","title":{"rendered":"Lan\u00e7amento do sistema de controle de vers\u00f5es Git 2.46","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ap\u00f3s tr\u00eas meses de desenvolvimento, foi publicada a vers\u00e3o 2.46 do sistema distribu\u00eddo de controle de vers\u00f5es Git. O Git \u00e9 um dos sistemas de controle de vers\u00f5es mais populares, confi\u00e1veis e de alto desempenho, fornecendo meios flex\u00edveis para desenvolvimento n\u00e3o linear, baseados em ramifica\u00e7\u00f5es e mesclagens. Para garantir a integridade do hist\u00f3rico e resist\u00eancia a altera\u00e7\u00f5es 'retroativas', \u00e9 utilizado um hash impl\u00edcito de todo o hist\u00f3rico anterior em cada commit, sendo tamb\u00e9m poss\u00edvel validar digitalmente as assinaturas dos desenvolvedores em tags e commits individuais. O c\u00f3digo do Git \u00e9 distribu\u00eddo sob a licen\u00e7a GPLv2+. <\/p>\n
Comparado \u00e0 vers\u00e3o anterior, a nova vers\u00e3o inclui 746 mudan\u00e7as, desenvolvidas por 96 desenvolvedores, dos quais 31 participam do desenvolvimento pela primeira vez. As principais novidades s\u00e3o: <\/p>\n
\n
Foi adicionada a suporte experimental a um novo tipo de bitmap \u2014 o 'pseudo-merge reachability bitmap', que, ao contr\u00e1rio da estrutura 'reachability bitmap', armazena dados sobre conjuntos de objetos relacionados a commits n\u00e3o vinculados a cada commit individual, mas sim a v\u00e1rios commits de uma vez. Essa organiza\u00e7\u00e3o permite o uso de um \u00fanico bitmap na determina\u00e7\u00e3o de objetos para commits em diferentes ramifica\u00e7\u00f5es, o que em reposit\u00f3rios grandes permite evitar a cria\u00e7\u00e3o de um grande n\u00famero de bitmaps separados e acelera significativamente a abordagem de objetos para determinar quais objetos devem ser enviados ao cliente durante opera\u00e7\u00f5es como 'git fetch', 'git rev-list' e 'git clone'. Para ativar o novo tipo de bitmaps e definir a l\u00f3gica de sua sele\u00e7\u00e3o e uso, foi proposta uma s\u00e9rie de configura\u00e7\u00f5es 'bitmapPseudoMerge': git config bitmapPseudoMerge.all.pattern 'refs\/(heads|tags)\/' git config bitmapPseudoMerge.all.threshold now git config bitmapPseudoMerge.all.stableThreshold never git repack -adb\n
Foi implementada uma nova interface de linha de comando para o comando 'git config', que, em vez de op\u00e7\u00f5es dispersas para visualizar, renomear e remover configura\u00e7\u00f5es e se\u00e7\u00f5es, como '--get', '--get-all', '--unset' e '--remove-section', oferece um conjunto de subcomandos separados. Por exemplo, para listar todas as configura\u00e7\u00f5es do reposit\u00f3rio, agora pode-se usar o comando 'git config list', e para visualizar o conte\u00fado de um par\u00e2metro espec\u00edfico \u2014 o comando 'git config get '. Para filtragem adicional dos resultados, pode-se usar a op\u00e7\u00e3o '--regexp' para definir um filtro baseado em uma express\u00e3o regular.\n
No protocolo «credential helper», utilizado para transmitir credenciais ao acessar reposit\u00f3rios com acesso restrito, foi adicionada a suporte a novos campos «authtype» e «credential», permitindo a cria\u00e7\u00e3o de manipuladores para sistemas de autentica\u00e7\u00e3o HTTP que n\u00e3o se limitam \u00e0 verifica\u00e7\u00e3o de login e senha, por exemplo, ao utilizar Bearer Token no OAuth 2.0. Antes, para trabalhar com sistemas de autentica\u00e7\u00e3o desse tipo, era necess\u00e1rio especificar dados confidenciais em texto claro no par\u00e2metro http.extraHeader. Al\u00e9m disso, o protocolo agora suporta a possibilidade de salvar o estado de cada manipulador de credenciais para suportar m\u00e9todos de autentica\u00e7\u00e3o multif\u00e1sicos usados em protocolos como NTLM e Kerberos.\n
O desenvolvimento do backend experimental «reftable» para armazenamento eficiente de refer\u00eancias a branches e tags no reposit\u00f3rio foi continuado. Este backend utiliza um armazenamento em bloco, aplicado pelo projeto JGit e otimizado para armazenar um n\u00famero muito grande de refer\u00eancias (formatos de armazenamento de refer\u00eancias tradicionais levam a um overhead significativo em reposit\u00f3rios com um grande n\u00famero de refer\u00eancias, devido \u00e0 coloca\u00e7\u00e3o de muitos arquivos em um \u00fanico diret\u00f3rio se as refer\u00eancias forem armazenadas no diret\u00f3rio $GIT_DIR\/refs ou \u00e0 necessidade de reescrever um grande arquivo sempre que h\u00e1 uma atualiza\u00e7\u00e3o se as refer\u00eancias forem armazenadas no arquivo $GIT_DIR\/packed_refs). Na nova vers\u00e3o, foi adicionada o comando «git refs migrate \u2014ref-format=reftable» para converter reposit\u00f3rios existentes para o backend «reftable» (anteriormente, o backend s\u00f3 era ativado ao inicializar o reposit\u00f3rio).\n
Foi adicionada \u00e0 equipe git a op\u00e7\u00e3o «—no-advice», que desabilita todas as mensagens de recomenda\u00e7\u00e3o e dicas, o que pode ser \u00fatil para evitar a polui\u00e7\u00e3o do log com informa\u00e7\u00f5es desnecess\u00e1rias durante chamadas automatizadas do git.\n
O processo de migra\u00e7\u00e3o de algumas verifica\u00e7\u00f5es do conjunto de testes para o uso de testes unit\u00e1rios come\u00e7ou, o que simplificar\u00e1 o teste de componentes de baixo n\u00edvel e melhorar\u00e1 a efici\u00eancia do processo de teste na plataforma Windows, onde h\u00e1 grandes sobrecargas ao iniciar um grande n\u00famero de processos durante a execu\u00e7\u00e3o de testes implementados como scripts shell.\n
O c\u00f3digo para an\u00e1lise das configura\u00e7\u00f5es de cores agora suporta a representa\u00e7\u00e3o «#RGB» al\u00e9m da «#RRGGBB». <\/ul>\n