Migrando para o MQL5 Algo Forge (Parte 2): Trabalhando com múltiplos repositórios

Introdução

No primeiro artigo iniciamos a transição do uso do MQL5 Storage — o repositório SVN integrado ao MetaEditor — para uma solução mais flexível e moderna baseada no sistema de controle de versões Git: MQL5 Algo Forge. A principal razão para essa mudança foi a necessidade de usar plenamente diferentes branches do repositório ao trabalhar em vários projetos ou em funcionalidades distintas dentro de um mesmo projeto.

A transição começou com a criação de um novo repositório no MQL5 Algo Forge e a configuração do ambiente local de desenvolvimento utilizando o Visual Studio Code, as extensões necessárias para trabalhar com MQL5 e Git, além da instalação das ferramentas apropriadas. Em seguida, adicionamos ao repositório o arquivo .gitignore para excluir do rastreamento arquivos padrão e temporários. Todos os projetos existentes foram carregados em uma branch separada chamada archive, que assumiu o papel de repositório de arquivamento de todo o código já existente. A branch principal main foi deixada vazia e preparada para a criação de novas branches específicas para cada projeto. Dessa forma, estabelecemos a base necessária para a futura organização do código de diferentes projetos em diferentes branches do repositório.

Entretanto, nos cinco meses que se passaram desde a publicação do artigo anterior, ocorreram mudanças significativas no desenvolvimento do suporte ao novo repositório dentro do MetaEditor. Isso nos obriga a repensar o plano traçado anteriormente para a utilização desse novo armazenamento. Por isso, neste artigo, nos afastaremos um pouco da abordagem adotada na primeira parte e analisaremos o exemplo de criação de um projeto público que utiliza outros projetos públicos como partes integrantes. O projeto em questão será dedicado ao desenvolvimento de um EA multimoeda. No decorrer desse trabalho, já publicamos alguns artigos apresentando abordagens para o desenvolvimento e a modificação de código. Agora, tentaremos aproveitar ao máximo os recursos do sistema de controle de versões Git para organizar e estruturar o processo de desenvolvimento.

Definindo o caminho

É difícil acreditar, mas no momento em que escrevemos o artigo anterior sobre este tema, o MetaEditor ainda não tinha o item "Git" no menu principal nem os comandos do menu de contexto dos arquivos para trabalhar com o repositório MQL5 Algo Forge. Por isso, foi necessário investir bastante esforço em estruturar o processo de trabalho com o novo repositório utilizando ferramentas externas, como o Visual Studio Code. Como ainda não sabíamos como o suporte ao repositório seria implementado no MetaEditor, tínhamos que trabalhar com os recursos disponíveis na época.

Com o tempo, as novas versões do MetaEditor passaram a oferecer suporte ao novo repositório, e recentemente a MetaQuotes publicou um novo artigo — "Como começar a trabalhar com MQL5 Algo Forge" — explicando os pontos principais e demonstrando as possibilidades de uso do MQL5 Algo Forge. No entanto, o que consideramos mais importante foi a implementação no MetaEditor do mecanismo de projetos compartilhados (Shared Projects).

Vamos explicar por que isso é tão relevante. Antes dessa implementação, sabíamos apenas que a pasta MQL5 passaria a ser um repositório armazenado nos servidores Git do MQL5 Algo Forge. Ao que tudo indicava, esse repositório teria sempre o nome fixo mql5. Isso significa que diferentes usuários teriam em seu espaço do MQL5 Algo Forge um repositório chamado mql5. Esse repositório seria clonado automaticamente para a pasta MQL5 após a instalação de um novo terminal, a autorização do usuário na Community e a ativação do repositório. Mas desde o início já era possível criar outros repositórios no MQL5 Algo Forge. Não complementares, mas sim independentes, totalmente separados do repositório mql5. Assim, surgia naturalmente a dúvida: como trabalhar com esses repositórios adicionais no MetaEditor? 

Será que seria implementada a opção de escolher o repositório a ser usado em cada instância do terminal instalada? Ou isso não aconteceria? Nesse caso, teríamos de nos contentar com apenas um repositório, aproveitando ao menos a possibilidade de criar diferentes branches para separar o desenvolvimento de vários projetos. Para ser sincero, estávamos preparados para esse pior cenário. Pior porque trabalhar com múltiplos projetos em branches diferentes de um único repositório não é muito prático. Felizmente, nossos receios não se confirmaram.

A MetaQuotes propôs uma solução elegante que resolveu dois problemas de uma só vez. De um lado, permanece o repositório principal com o nome mql5. Essa abordagem é especialmente conveniente para quem já utilizava o MQL5 Storage, pois agora é possível continuar usando o controle de versão da mesma forma simples e intuitiva, sem precisar se preocupar com qual sistema de versionamento (CVS) está sendo usado por trás.

De outro lado, todos os demais repositórios do usuário passaram a estar acessíveis como pastas dentro do Shared Project. Assim, ganhamos uma nova pasta raiz padrão, ao lado das já conhecidas (MQL5, MQL5/Experts, MQL5/Include etc.), destinada ao armazenamento do código proveniente dos outros repositórios do usuário.

Vamos simular a seguinte situação: suponhamos que temos dois repositórios separados no novo armazenamento MQL5 Algo Forge, que não são os repositórios principais padrão. Um deles (Adwizard) conterá apenas código de biblioteca, ou seja, apenas arquivos de inclusão *.mqh, sem arquivos *.mq5 que, ao serem compilados, se transformariam em um EA ou, por exemplo, em um indicador. O segundo repositório (Simple Candles) já contém arquivos *.mq5, nos quais os arquivos de inclusão usados vêm do primeiro repositório. Para simplificar, chamaremos o primeiro repositório de **biblioteca** e o segundo de **projeto**.

Queremos entender como proceder para garantir que o código do repositório de biblioteca possa ser utilizado no desenvolvimento dentro do repositório de projeto. Esse tipo de situação pode vir a se tornar bastante comum, especialmente se, por exemplo, códigos publicados pelos membros da comunidade no Codebase forem duplicados por eles no MQL5 Algo Forge na forma de repositórios públicos. Nesse caso, a conexão de um ou vários repositórios como bibliotecas externas de código a um projeto poderia ser implementada da mesma forma que vamos tentar demonstrar neste artigo.

Começando

Primeiro, vamos analisar o caso do desenvolvedor que mantém esses repositórios. Ou seja, poderemos modificar o código-fonte de ambos os repositórios diretamente, sem precisar esperar por revisão e aceitação das alterações via mecanismo de Pull Request. Criamos uma pasta limpa para o terminal e copiamos para ela dois arquivos de qualquer cópia já instalada anteriormente do terminal MetaTrader 5:

Para evitar a necessidade de procurar a pasta de trabalho do terminal nas profundezas do sistema de arquivos, recomendamos iniciar o terminal diretamente no modo portátil (Portable). No Windows, uma das formas de fazer isso é criar um atalho para o executável do terminal e, nas propriedades do atalho, adicionar à linha de execução a chave /portable. 

Iniciamos o terminal, abrimos uma conta demo (por precaução), atualizamos o terminal para a versão mais recente, fazemos login na Community e, em seguida, abrimos o MetaEditor pressionando F4. Conectamos o repositório MQL5 Algo Forge, caso ele ainda não tenha sido ativado automaticamente.

Podemos ver que, no navegador do MetaEditor, aparece a pasta Shared Projects, dentro da qual estão listados todos os repositórios que criamos anteriormente via interface web. No entanto, se abrirmos essa pasta no explorador de arquivos, ela estará vazia. Isso significa que, por enquanto, os arquivos reais desses outros repositórios ainda não foram baixados para o nosso computador.

Agora, clicamos com o botão direito do mouse nos nomes dos dois repositórios que nos interessam e, no menu de contexto, selecionamos a opção "Clonar repositório Git". No log, vemos mensagens confirmando o sucesso da clonagem dos repositórios Adwizard e Simple Candles. No explorador de arquivos, após essa operação, também já aparecem as pastas com os repositórios clonados:

Pronto, o código-fonte de ambos os projetos foi baixado para o nosso computador e está pronto para uso.

Encontramos o primeiro problema

Tentemos abrir o arquivo do EA SimpleCandles.mq5 e compilá-lo:

Como podemos ver, durante a compilação ocorrem erros. Vamos tentar entender as causas. Não há dúvida de que eles não são insolúveis, já que anteriormente esse código era compilado com sucesso. O que mudou agora? Apenas a forma como os arquivos da biblioteca e do projeto estão organizados. Portanto, os dois primeiros erros fundamentais acontecem porque o compilador não encontra os arquivos de biblioteca no local em que espera encontrá-los. Na parte 28 havíamos definido a seguinte estrutura de pastas para armazenar a parte de biblioteca e a parte de projeto:

Ou seja, o repositório de biblioteca ficava dentro de uma subpasta do repositório de projeto. Isso foi, em grande parte, uma medida forçada, para que houvesse pelo menos uma definição clara de onde os arquivos da biblioteca estariam localizados. Agora, vamos alterar esse acordo. Em vez da subpasta Include obrigatória dentro da pasta do projeto, passaremos a usar a pasta MQL5/Shared Projects. Temos grande esperança de que, no futuro próximo, ela continue existindo nesse mesmo local e mantenha sua finalidade atual.

Para isso, será necessário alterar dois trechos do código onde estão os comandos de inclusão dos arquivos de biblioteca. Mas, antes disso, vamos aplicar uma boa prática de desenvolvimento: alterações no código que resolvem uma tarefa específica devem ser feitas em uma branch separada do repositório. Depois, quando tudo estiver ajustado e funcionando, essa branch poderá ser fundida com a branch principal.

Vamos verificar quais branches já existem no repositório do projeto. Isso pode ser feito de diferentes formas:

• Pelo menu de contexto da pasta do repositório no MetaEditor: 

• Pela interface web do repositório, na página branches do repositório selecionado:

• Ou usando uma ferramenta externa que trabalhe com repositórios Git, como o Visual Studio Code. Ao lado do nome do repositório, está indicado o nome da branch atual main. Ao clicar nele, veremos a lista das branches disponíveis (e também as opções do menu para criar novas branches):

Portanto, neste momento, temos quatro branches no repositório:

• main — a branch principal. Ela é criada automaticamente junto com o repositório. No caso mais simples, além dela não seria necessário criar nenhuma outra branch, e todo o desenvolvimento poderia ser feito diretamente nela. Em cenários mais complexos, essa branch pode ser usada para armazenar o estado dos arquivos que representam uma versão estável do código em determinado momento. Todas as alterações ainda não concluídas e testadas devem ser feitas em outras branches.
• develop — a branch de desenvolvimento. Da mesma forma, em uma situação mais simples, poderia ser utilizada apenas essa branch para aplicar correções e adicionar novas funcionalidades ao projeto. Essa opção é suficiente se as novas funcionalidades são desenvolvidas de forma estritamente sequencial. Ou seja, não começamos a implementar uma nova funcionalidade até que o projeto esteja totalmente estável após a inclusão do recurso anterior. Antes de iniciar uma nova fase de desenvolvimento, é feito o merge das branches: as alterações feitas em develop são incorporadas em main. Já em um caso mais avançado, que envolve o desenvolvimento simultâneo de diversas funcionalidades em andamento, trabalhar em uma única branch de desenvolvimento se torna inconveniente. Por isso, pode-se criar branches separadas para cada parte isolada da nova funcionalidade.
• article-17608-close-manager e article-17607 são exatamente exemplos desse tipo de branch. Na primeira, foram reunidas as alterações que adicionam um módulo de gerenciamento de fechamento de posições ao atingir determinado lucro ou prejuízo. Essa branch já foi incorporada em develop, e depois develop foi incorporada em main. A outra branch contém alterações relacionadas à modernização do mecanismo de otimização automática, mas ela ainda não foi concluída, ou seja, suas alterações ainda não foram integradas nem a develop, nem a main.

Vale reforçar que o uso de um repositório Git não nos obriga a seguir regras rígidas de criação e uso de branches. Nesse aspecto, temos total liberdade para escolher a estratégia que considerarmos mais conveniente. Alguns padrões de trabalho com branches pareceram práticos para certos desenvolvedores, que compartilharam suas técnicas com outros, e assim elas também foram adotadas. Foi desse processo que surgiram as chamadas "melhores práticas" (best practices). Mas elas podem ser várias, e a escolha de quais adotar depende do projeto específico e dos desenvolvedores envolvidos. Para comparação, podemos consultar, por exemplo, um dos princípios sugeridos de criação de branches apresentados neste artigo.

Mas vamos voltar às branches do repositório que estamos analisando.

Alguém pode se perguntar: o que significa o prefixo origin/ ou, como mostrado no MetaEditor, refs/remotes/origin/? Isso nada mais é do que a indicação de que a branch já existe no repositório remoto e não apenas no computador local. Normalmente, tentamos manter as branches locais e remotas sincronizadas. MetaEditor praticamente nos obriga a isso: ao escolher no menu de contexto o comando Commit (confirmação das alterações na cópia local do repositório), ele executa automaticamente também o comando Push (envio do commit para o repositório remoto).

Se não utilizarmos a interface do MetaEditor para fazer o commit, é possível registrar alterações apenas localmente, sem enviá-las ao repositório remoto. Nesse caso, a branch com o mesmo nome pode estar em estados diferentes no repositório local e no remoto. Para podermos especificar exatamente a qual branch estamos nos referindo, utiliza-se o prefixo origin/. Se ele aparece, significa que estamos lidando com a branch no repositório remoto; se não aparece, estamos lidando com a branch local.

Criando uma nova branch

Como as alterações planejadas no código dizem respeito apenas a garantir sua compilação após a mudança do local da parte de biblioteca, faremos essas modificações em uma nova branch derivada de develop. Para isso, precisamos primeiro alternar para a branch origin/develop, assim, ela passará a aparecer na lista como branch local develop:

Depois disso, podemos selecionar a opção de criação de nova branch (New) e inserir o nome desejado. Vamos manter o padrão adotado anteriormente: os nomes das branches criadas para artigos começam com a palavra article, seguida por um identificador numérico único do artigo separado por hífen. Em seguida, pode ser adicionado um sufixo que reflita o tema do artigo. Portanto, criaremos a branch com o nome "article-17698-forge2".

Poderíamos também criar a branch de outras formas: usando a interface web, a interface do Visual Studio Code ou a linha de comando. Nesse último caso, basta executar o seguinte comando na pasta raiz do repositório:

git checkout -b article-17698-forge2 develop

Ou seja, estamos pedindo ao Git para alternar (checkout) para uma nova branch (-b) chamada article-17698-forge2, derivada da branch chamada develop.

Se a branch não for criada pela interface web, então, até o primeiro envio de alterações para o repositório remoto (Push), ela existirá apenas no nosso computador local. O inverso também é verdadeiro: se a branch for criada no repositório remoto pela interface web, até o primeiro recebimento de alterações do repositório remoto (Pull), essa branch não existirá no nosso repositório local.

O envio dessas alterações pode ser feito assim:

ou assim:

O comando de console para a operação de Push, que precisa enviar as alterações incluindo a criação da nova branch, deve obrigatoriamente conter parâmetros adicionais, confirmando que realmente queremos criar a nova branch também no repositório remoto:

git push --set-upstream origin article-17698-forge2

Depois disso, a branch passa a existir tanto na cópia local do repositório quanto no repositório remoto dentro do MQL5 Algo Forge. Agora já podemos começar a aplicar correções sem o risco de comprometer a integridade do código em outras branches.

Fazendo as correções

As modificações necessárias serão bem simples. No arquivo SimpleCandles.mq5 alteramos a linha que conecta o arquivo da biblioteca Adwizard. Como agora as pastas raiz dos repositórios Simple Candles e Adwizard estão no mesmo nível dentro da pasta Shared Projects, para acessar o arquivo Expert.mqh, precisamos primeiro subir um nível (../) e só então descer até as subpastas do repositório da biblioteca:

#include "Include/Adwizard/Experts/Expert.mqh"
#include "../Adwizard/Experts/Expert.mqh"

No arquivo Strategies/SimpleCandlesStrategy.mqh será necessário fazer a mesma correção:

#include "../Include/Adwizard/Virtual/VirtualStrategy.mqh"
#include "../../Adwizard/Virtual/VirtualStrategy.mqh"

Após essas alterações, o EA SimpleCandles.mq5 volta a compilar com sucesso. Podemos então fazer o commit das alterações no repositório:

Como já mencionamos, ao confirmar alterações dessa forma, o comando Push é executado automaticamente, enviando as modificações para o repositório remoto no MQL5 Algo Forge.

Ao trabalhar com comandos de console, podemos alcançar o mesmo resultado da seguinte maneira. Se além de alterar arquivos existentes também tivermos criado novos, antes do commit precisamos executar o comando que adiciona esses novos arquivos ao índice do repositório:

git add .

Esse comando adiciona todos os novos arquivos encontrados na pasta do repositório. Se em vez do ponto (.) listarmos nomes de arquivos específicos, apenas eles serão adicionados. Em seguida, executamos o commit com um comentário e depois o push para enviar as alterações ao repositório remoto:

git commit -m "Fix relative paths to include files from Adwizard"
git push

Com isso, as alterações na branch article-17698-forge2 estão concluídas, e ela pode ser integrada à branch develop e encerrada.

Encontramos o segundo problema

Aqui, no entanto, surge uma surpresa desagradável. No MetaEditor, ainda não há ferramentas que permitam realizar merges de branches. Ou seja, já podemos criar novas branches, mas não conseguimos transferir as alterações de uma branch para outra! Resta esperar que essa funcionalidade seja adicionada em breve, mas, por enquanto, teremos de recorrer novamente a ferramentas alternativas para executar essas operações no repositório.

Temos dois métodos principais para realizar o merge de branches. O primeiro é utilizar a interface de merge do Visual Studio Code ou recorrer aos comandos de console. Por exemplo, para o merge que precisamos, bastaria executar os seguintes comandos:

git checkout develop
git pull
git merge --no-ff article-17698-forge2

Primeiro alternamos para a branch develop, depois a atualizamos por precaução (caso ela tenha recebido modificações que ainda não chegaram ao nosso computador local). O último comando executa o merge propriamente dito da branch atual. Nesse processo, podem ocorrer conflitos de merge, mas no nosso caso a probabilidade é bastante baixa, já que estamos tratando de um cenário de trabalho individual no projeto. Portanto, mesmo que se trabalhe a partir de diferentes locais, desde que se mantenha o hábito de atualizar os repositórios regularmente, não devem surgir conflitos.

Mas não vamos nos aprofundar nos detalhes desse método e, em vez disso, analisaremos mais de perto o segundo método. Para ele, precisaremos usar a interface web do repositório MQL5 Algo Forge.

Usando Pull Request para o merge

Assim como em outros serviços de hospedagem Git (como GitHub, GitLab, Bitbucket), o MQL5 Algo Forge também possui o mecanismo chamado Pull Request (PR).

Um Pull Request (PR) é um recurso que permite a um desenvolvedor propor que as alterações feitas em sua branch sejam incorporadas a um determinado repositório. Em outras palavras, criar um PR é uma forma de avisar ao dono do repositório e aos demais participantes do desenvolvimento: "Trabalhei nesta branch, por favor façam o merge (pull) dessas alterações na branch principal (main/master/develop) após a revisão".

O PR não é uma funcionalidade nativa do Git, mas sim uma camada adicional construída sobre ele, que organiza o processo de revisão de código (code review) e a discussão antes da integração das alterações na branch principal do repositório.

Os PRs geralmente resolvem também outras tarefas cruciais no desenvolvimento moderno, como integração contínua (CI) com execução automática de testes, controle de qualidade por outros desenvolvedores e registro das alterações através dos comentários do PR, explicando os motivos das mudanças no projeto. No entanto, tudo isso é mais relevante em projetos nos quais vários desenvolvedores trabalham simultaneamente no mesmo código, enquanto projetos em MQL5, na maioria das vezes, são individuais. Talvez, no futuro, alguns projetos evoluam para se tornarem colaborativos, mas até agora ainda não vimos exemplos realmente expressivos desse tipo dentro do ecossistema.

Ainda assim, acabamos de reproduzir o início de um fluxo de trabalho típico (Workflow) para adicionar uma nova funcionalidade ou aplicar correções utilizando PR:

1. Recebemos as últimas alterações. Antes de começar a trabalhar, atualizamos a branch principal local develop.

2. Criamos uma nova branch para a tarefa. A partir da branch develop atualizada, criamos uma branch com um nome claro, article-17698-forge2.

3. Trabalhamos na nova branch: Corrigimos/completamos o código em alguns arquivos, testamos e fizemos o commit das alterações.

Agora precisamos realizar os próximos passos.

4. Criar o Pull Request. Para isso, no web interface do repositório MQL5 Algo Forge, acessamos a aba correspondente e clicamos no grande botão vermelho "New pull request":

Em seguida, chegamos à página de seleção das branches do PR que estamos criando. Nessa etapa ele ainda não foi efetivamente criado, pois precisamos primeiro escolher de qual branch para qual branch queremos transferir as alterações. Após selecionar as branches, podemos visualizar a lista de modificações que serão aplicadas. Então clicamos novamente em "New pull request".

Será aberta uma página onde podemos adicionar um comentário detalhado explicando as alterações feitas. Nessa mesma tela também podemos selecionar os desenvolvedores que deverão revisar as modificações. Por padrão, o pedido de revisão é direcionado a nós mesmos, exatamente o que precisamos no nosso caso.

5. Processo de revisão e discussão. Esse passo vamos ignorar, já que estamos conduzindo o desenvolvimento sozinhos. Mas, em um fluxo normal, nessa etapa acontece o seguinte:

   • os revisores analisam o código e deixam comentários (gerais ou vinculados a linhas específicas);

   • o autor do PR responde aos comentários e faz as correções necessárias diretamente na mesma branch;

   • todos os novos pushes feitos nessa branch são automaticamente incorporados ao PR já existente.

6. Merge. Depois da aprovação dos revisores (caso existam) e da passagem pela CI (se houver), o PR pode ser fechado com o merge. Normalmente, existem algumas opções para aplicar as alterações na branch de destino:

• Merge commit: cria um commit de merge separado. O histórico é preservado exatamente como está.

• Squash and merge: todos os commits da branch do PR são unidos em um único commit, que é adicionado à branch de destino. Esse método é conveniente se não quisermos poluir o histórico com commits pequenos do tipo "corrigido erro de digitação".

• Rebase and merge: os commits do PR são reaplicados no topo da branch de destino (no nosso caso, develop). O histórico fica linear e limpo.

Entre as opções de merge oferecidas, escolhemos a primeira, pois queremos manter no histórico todos os commits feitos. Portanto, clicamos no botão "Create merge commit":

Chegamos à página final do processo de Pull Request. Marcamos a opção "Delete branch ...", para fechar imediatamente a nossa branch temporária de desenvolvimento. No histórico de commits continuará registrado que essa branch existiu. No entanto, não faz sentido deixá-la aberta, já que o objetivo para o qual foi criada foi alcançado. Para mudanças futuras, que tratarão de outras tarefas, criaremos novas branches. Assim, ao olhar para a lista de branches do repositório a qualquer momento, teremos uma visão clara de quais tarefas estão sendo desenvolvidas em paralelo.

Todo o restante na página pode ser deixado como está, bastando clicar no botão "Create merge commit".

Com isso, o processo de merge é concluído: a branch article-17698-forge2 foi incorporada à branch develop e depois removida:

De modo geral, o uso de Pull Request (PR) para realizar merges de branches, mesmo dentro do próprio repositório, é uma prática correta e recomendada, mesmo quando o desenvolvimento é feito individualmente. Antes do merge, temos a oportunidade de revisar todas as alterações em uma interface prática do repositório MQL5 Algo Forge. Esse tipo de verificação direcionada muitas vezes permite identificar detalhes que passaram despercebidos durante os commits: comentários desnecessários, arquivos adicionados por engano, alterações pouco otimizadas. Na prática, isso funciona como uma forma de autodisciplina. Além disso, a familiaridade com processos adequados ajuda a consolidar a rotina de trabalho nesse formato (criação de branch dedicada, revisão de código etc.). E, se surgir a necessidade de colaborar em equipe no futuro, não será preciso reaprender o fluxo, ele já estará bem estabelecido.

Portanto, sim, enviar PRs para si mesmo não só é possível, como também é recomendado em qualquer projeto minimamente sério. Isso melhora a qualidade do código e traz disciplina. É claro que, para correções rápidas compostas de um ou dois commits, nada impede de recorrer ao merge direto usando o comando git merge. Mas, para alterações mais substanciais, o uso de PR é a escolha mais adequada.

Conclusão

Assim, estabelecemos um fluxo de trabalho consistente com nossos repositórios. Percorremos o caminho desde a clonagem até a prática de aplicar alterações mantendo o código no repositório em estado funcional e pronto para evoluir. O repositório do projeto agora consegue utilizar de forma clara e organizada o código de outro (ou outros) repositórios que atuam como bibliotecas.

No entanto, até agora analisamos apenas um lado: quando o proprietário do repositório de projeto e do repositório de biblioteca é o mesmo usuário. O outro lado da questão surge quando o dono de um repositório de projeto deseja utilizar repositórios de terceiros como bibliotecas. E aqui, infelizmente, as coisas não são tão simples. Embora justamente esse tipo de uso — aproveitar ativamente o código de outros desenvolvedores e trabalhar de forma colaborativa — tenha sido declarado como um dos objetivos principais da transição para o novo repositório. Mas nem tudo acontece de uma só vez, o importante é que o primeiro passo já foi dado.

Por aqui fazemos uma pausa, até a próxima parte!