lançamento de um sistema de controle de origem distribuído . Git é um dos sistemas de controle de versão mais populares, confiáveis e de alto desempenho, fornecendo ferramentas flexíveis de desenvolvimento não linear baseadas em ramificação e fusão. Para garantir a integridade do histórico e a resistência a mudanças retroativas, é utilizado hash implícito de todo o histórico anterior em cada commit; também é possível certificar tags individuais e commits com assinaturas digitais dos desenvolvedores.
Em comparação com a versão anterior, a nova versão incluiu 583 alterações, preparadas com a participação de 84 desenvolvedores, dos quais 32 participaram do desenvolvimento pela primeira vez. :
- A possibilidade de clonagem parcial aproxima-se da estabilização e prontidão total, permitindo transferir apenas parte dos dados e trabalhar com uma cópia incompleta do repositório. Um clone típico copia todos os dados do repositório, incluindo todas as versões de cada arquivo no histórico de alterações. Para repositórios muito grandes, a cópia de dados resulta em um aumento significativo no tráfego e no espaço em disco, mesmo que o desenvolvedor esteja interessado apenas em um subconjunto dos arquivos. Para facilitar a recuperação de apenas parte da árvore de origem em funcionamento, a nova versão introduz um comando experimental "sparse-checkout" e uma nova opção "--sparse" para o comando "clone".
Anteriormente, o processo de clonagem seletiva era realizado através da tarefa para filtrar conteúdo desnecessário e a opção “—no-checkout” para desabilitar o preenchimento de arquivos ausentes. Depois disso, antes de realizar a operação de checkout, foi necessário habilitar a configuração core.sparseCheckout e definir uma lista de padrões de caminho excluídos no arquivo .git/info/sparse-checkout. Por exemplo, para clonar sem blobs e evitar que arquivos sejam extraídos de subdiretórios de profundidade 2 ou mais, você pode executar:
git clone --filter=blob:none --no-checkout /seu/repositório/aqui repositório
$ cd repositório
$ gato >.git/info/sparse-checkout <EOF
/*
!/*
EOF
$ git config core.sparseCheckout 1
$git checkout.O novo comando “git sparse-checkout” simplifica bastante o trabalho e reduz o processo de organização do trabalho com um repositório incompleto aos seguintes comandos:
git clone --filter=blob:none --sparse /seu/repositório/aqui repositório
git sparse-checkout set /caminho/para/check/outO comando sparse-checkout permite definir uma lista de caminhos para checkout (definir) sem configurar manualmente .git/info/sparse-checkout, bem como exibir a lista atual de caminhos (lista) e ativar ou desativar checkouts parciais (habilitar /desativar).
Para otimizar o trabalho com repositórios e listas de modelos muito grandes, o “", que limita os padrões permitidos (em vez de padrões .gitignore arbitrários, você pode especificar se todos os caminhos e todos os arquivos em um determinado subdiretório devem ser verificados). Por exemplo, se um repositório grande possui um diretório “A/B/C” e todo o trabalho está concentrado no subdiretório “C”, então ao ativar o modo sparseCheckoutCone, o comando “git sparse-checkout set A/B/ C” extrairá todo o conteúdo de “C”, mas de “A” e “B” extrairá apenas as partes necessárias para trabalhar com “C”.
- Da documentação ("git rebase -h"), todas as referências à opção "--preserve-merges" foram removidas, que foi descontinuada e deve ser usada para migrar um conjunto de commits.".
- Para melhorar a legibilidade das mensagens com patches enviadas para listas de discussão, foi adicionada a opção “git format-patch —cover-from-description subject”, quando especificado, o primeiro parágrafo do texto de descrição do branch é usado como assunto do carta de apresentação para um conjunto de patches.
- Implementado suporte para o uso combinado do comando “git apply -3way” e da configuração “merge.conflictStyle” (“git apply” agora leva em consideração o estilo de descrição do conflito de merge.conflictStyle quando é necessário resolver o conflito após tentar para aplicar um arquivo de patch ao repositório).
- O código de definição de função usado em operações como "git diff/grep --show-function/-function-context" foi estendido para suportar a definição de limites de função em programas de linguagem .
- Uma nova opção foi adicionada a "git add", "git commit", "git reset" e outros comandos - "-pathspec-from-file", que permite carregar uma lista de caminhos de um arquivo ou fluxo de entrada , em vez de listá-los na linha de comando.
- O problema com a detecção de renomeações no nível do diretório ao escrever commits foi resolvido. A definição não funcionou se o conteúdo de um subdiretório fosse movido para a raiz do repositório.
- Uma implementação inicial do comando redesenhado “git add -i” foi proposta, permitindo adicionar conteúdo alterado de forma interativa, reescrito de Perl para C. Uma reformulação semelhante do comando “git add -p” está em andamento.
- O comando “git log –graph” foi refatorado, gerando uma imagem ASCII de um gráfico com o histórico de alterações no repositório. O retrabalho permitiu melhorar e simplificar significativamente o resultado sem distorcer a estrutura da história, o que, por exemplo, resolveu o problema da imagem que se estendia além da largura da linha terminal.
- A opção "git log --format=.." permite alterar o formato de saída,
estendido com suporte para sinalizadores “l/L” para exibir apenas a parte do endereço de e-mail indicada antes do símbolo “@” (por exemplo, útil quando todos os desenvolvedores têm todos os e-mails no mesmo domínio). - Adicionado um subcomando “set-url” ao comando “git submodule”.
- Os kits de teste foram atualizados em preparação para a transição para
algoritmo de hash SHA-2 em vez de SHA-1.
Fonte: opennet.ru