Migrando para o MQL5 Algo Forge (Parte 1): Criando o repositório principal

Conteúdo

• Introdução
• O que temos até agora
• Começando a migração
• Ferramenta de trabalho com repositório
• Criando o repositório principal
• Clonando o repositório
• Configurando arquivos ignorados
• Exportando alterações
• Criando um branch de arquivamento
• Preparando para criar branches de projetos
• Considerações finais

Introdução

Ao trabalhar em um projeto de porte médio ou grande, é inevitável a necessidade de acompanhar as alterações feitas no código, agrupá-las por contexto lógico e possibilitar o retorno a versões anteriores. Para isso, geralmente se utilizam diferentes sistemas de controle de versão, como o Git ou o Subversion (SVN).

Normalmente, as IDEs oferecem ferramentas integradas para trabalhar com os repositórios de alguma dessas soluções de versionamento. MetaEditor não é exceção, e também permite o uso do armazenamento próprio chamado MQL Storage baseado no sistema de controle de versão SVN. Como mencionado na documentação:

O MQL5 Storage é um armazenamento online pessoal de códigos-fonte em MQL4/MQL5. Ele está integrado ao MetaEditor: você pode salvar e acessar dados do repositório diretamente no editor.

O armazenamento utiliza um sistema de controle de versão. Isso significa que você sempre pode ver quando e como os arquivos foram modificados, pode desfazer qualquer alteração e voltar a uma versão anterior.

No MQL5 Storage seus códigos-fonte estão sempre seguros. Os dados são armazenados em um servidor protegido e só você tem acesso. Em caso de falha no disco rígido, todo o código salvo anteriormente pode ser facilmente recuperado.

Por meio do armazenamento, é fácil compartilhar e sincronizar modelos e perfis de gráfico, conjuntos de parâmetros para teste de programas MQL5 e listas de instrumentos de negociação entre diferentes plataformas.

O MQL5 Storage também permite o desenvolvimento remoto colaborativo de aplicações por meio de projetos em grupo.

No entanto, o sistema de controle de versão Git é mais popular e, na nossa opinião, com toda razão. Provavelmente por isso, algum tempo atrás, foram anunciados no fórum os planos de adoção do Git como sistema de controle de versão nativo no MetaEditor, junto com o lançamento de uma plataforma própria semelhante ao GitHub, MQL5 Algo Forge.

Esse repositório já está disponível para uso, mas por enquanto a integração com o MetaEditor ainda não foi finalizada. Portanto, permanecendo dentro do uso do MetaEditor como ambiente principal de desenvolvimento, só nos resta utilizar o armazenamento MQL Storage com base em SVN que está atualmente disponível.

Durante o desenvolvimento de diversos projetos, utilizamos ativamente o sistema de controle de versões existente. No entanto, ao trabalhar na série de artigos "Desenvolvendo um EA multimoeda", sentimos de forma mais acentuada a ausência de suporte para desenvolvimento de código em branches paralelos com posterior fusão. Embora o SVN permita o uso de branches, essa funcionalidade não está implementada na interface do MetaEditor. Para utilizá-los, seria possível recorrer a um cliente externo de SVN, mas isso já exigiria certo esforço para reconfigurar o ambiente de trabalho habitual.

Por isso, a notícia da transição para o uso do MQL5 Algo Forge foi recebida com muito entusiasmo. Nossas expectativas estavam justamente ligadas ao fato de que o MetaEditor finalmente passaria a suportar branches. Mas já se passaram sete meses, e essas expectativas ainda não se concretizaram. Sendo assim, vamos analisar como é possível contornar essa limitação usando os recursos que já estão disponíveis para tornar o desenvolvimento mais confortável.

Para melhor compreensão do que será abordado a seguir, é necessário pelo menos um conhecimento básico sobre sistemas de controle de versão. Por isso, recomendamos — se necessário — consultar materiais sobre o assunto no site da MQL5 ou em outras fontes, como o artigo Trabalhando com Git: primeiros passos no GitHub.

O que temos até agora

Logo após a notícia sobre a criação do MQL5 Algo Forge, vimos que foi criado um repositório com o nome mql5, no qual estavam localizados todos os arquivos do nosso repositório atual no MQL Storage. Porém, esses arquivos foram adicionados por um único commit feito pelo usuário super.admin, então, naturalmente, nenhum histórico de alterações (commits) do armazenamento atual foi mantido. Isso não chega a ser um problema grave. E é compreensível: migrar todo o histórico de mudanças entre diferentes tipos de sistemas de controle de versão é praticamente impossível.

Há algum tempo, em certas partes do MetaEditor, o nome do repositório utilizado foi alterado. Por exemplo, no título da janela de exibição do histórico de mudanças, vemos o nome "MQL5 Algo Forge":

No entanto, a essência ainda continua a mesma: todas as alterações são salvas no MQL Storage, e não no MQL5 Algo Forge. Portanto, os arquivos transferidos para o novo repositório há 7 meses não foram atualizados desde então, pois isso não ocorreu de forma automática.

Agora podemos usar diferentes repositórios! No armazenamento atual, havia apenas um repositório. Para trabalhar com projetos diferentes, éramos obrigados a criá-los em pastas separadas dentro da pasta de dados MQL5, que sempre é considerada a pasta raiz do repositório. Isso resultava no seguinte: ao criar uma nova cópia do terminal para desenvolver um novo projeto e ativar o armazenamento, recebíamos todo o código dos projetos anteriores vindos do repositório. Quando esses projetos começaram a se acumular em quantidade significativa, isso passou a causar certo incômodo.

Não era possível excluir simplesmente da pasta de dados o código dos projetos que não eram mais necessários, pois a cada commit de alterações, teríamos que marcar manualmente que a exclusão desses arquivos não deveria ser aplicada também no repositório.

Com a chegada de um repositório Git completo, agora temos a possibilidade de adotar diferentes formas de organizar o armazenamento e o gerenciamento do código de vários projetos:

• Cada projeto em um repositório separado.
• Cada projeto em um branch separado dentro de um único repositório.
• Uma combinação dos dois: para alguns projetos, criamos um repositório próprio, enquanto outros podem coexistir em branches diferentes dentro de um único repositório.

Obviamente, cada uma dessas abordagens tem seus prós e contras. De imediato, percebe-se que, se diferentes projetos utilizam a mesma biblioteca, seria inconveniente armazená-la em um repositório separado, e o ideal seria mantê-la em um branch próprio e fazer fusões periódicas das alterações com os branches dos projetos que a utilizam. Por outro lado, se o projeto for autossuficiente, o mais adequado será armazená-lo em um repositório próprio para não carregar código desnecessário de outros projetos.

Começando a migração

Ao mudarmos algo, é sempre prudente garantir que o que já temos esteja salvo. Provavelmente não vale a pena usar o repositório existente com o nome mql5, pois, durante as futuras etapas de integração feitas pela MetaQuotes, ele ainda poderá receber ações adicionais do usuário super.admin. Por isso, o primeiro passo será criar um novo repositório, em que reuniremos todos os projetos existentes até o momento. Para esse novo repositório, adotaremos o modelo no qual diferentes projetos são armazenados em branches distintos. Para viabilizar essa separação, adotaremos os seguintes critérios:

• A branch principal main ou ficará vazia, ou conterá apenas uma pequena quantidade de código que seja necessário para todos os projetos.
• Uma branch separada chamada archive conterá todo o código disponível no momento da migração. A partir dela, poderemos extrair o código para criar as branches específicas de cada projeto.
• As demais branches estarão associadas a um projeto específico e terão o nome do projeto no início de seu nome.
• Para um mesmo projeto, podem ser criadas várias branches conforme o modelo escolhido (por exemplo, é possível usar a abordagem proposta no artigo Uma boa estratégia de branching para Git).

Então, vamos supor que temos a pasta MetaTrader5 com o terminal instalado e o armazenamento MQL Storage já ativado. Ou seja, a pasta de dados do terminal MetaTrader5/MQL5 contém, junto com alguns arquivos padrão fornecidos com o terminal, o código dos nossos projetos.

Vamos criar uma nova pasta MetaTrader5.forge e copiar para ela dois arquivos executáveis:

Vamos iniciar o terminal MetaTrader a partir dessa pasta em modo portátil (portable). Ao darmos um duplo clique, ele já iniciou automaticamente nesse modo. Mas pode ser necessário especificar manualmente a chave /portable ao iniciar pela linha de comando, ou criando um atalho e adicionando essa chave ao comando de execução do aplicativo. Não é necessário abrir uma conta demo de negociação por enquanto, nem fazer login na conta da comunidade MQL5.community.

Uma estrutura inicial de pastas será criada nessa nova pasta, incluindo a pasta de dados MQL5. Neste momento, ela ainda não contém os nossos arquivos:

Vamos iniciar o MetaEditor a partir do terminal aberto pressionando F4.

Se clicarmos com o botão direito sobre o nome de alguma pasta, no menu de contexto aparece na última opção a sugestão para ativar o armazenamento MQL5 Algo Forge (embora na prática ainda seja ativado o MQL Storage). Não iremos ativá-lo, pois queremos migrar para o uso de um repositório do novo tipo.

Fechamos o terminal MetaTrader e o MetaEditor, já que não serão necessários por algum tempo e, além disso, precisaremos executar algumas ações diretamente na pasta do terminal.

Ferramenta de trabalho com repositório

A seguir, precisamos escolher uma ferramenta para trabalhar com o novo repositório. No futuro, essa ferramenta poderá ser o próprio MetaEditor, mas por enquanto será necessário usar outra. Qualquer ferramenta que permita trabalhar com repositórios Git serve, como o Visual Studio Code (VSCode) ou o próprio Git. A versão para Windows pode ser baixada em gitforwindows.org.

Portanto, instalamos o Git e o VSCode (ou verificamos se já estão instalados). No VSCode, instalamos a extensão MQL Tools para trabalhar com arquivos MQL5:

Após instalar a extensão, nas configurações da extensão definimos o parâmetro "Metaeditor5 Dir" com o caminho do executável do MetaEditor. Como não há necessidade de trabalhar com arquivos-fonte MQL5 que estejam fora da pasta de trabalho de uma instância específica do terminal, podemos seguir a recomendação e definir o caminho relativo à pasta atualmente aberta no VSCode:

E mais abaixo, nas configurações dessa extensão, é altamente recomendável marcar a opção "Portable MT5".

Também será necessário instalar a extensão C/C++ for Visual Studio Code para obter realce de sintaxe:

Infelizmente, apesar de a linguagem MQL5 ser muito parecida com C++, ela possui algumas construções que são consideradas inválidas em C++. Por isso, em alguns pontos veremos mensagens dessa extensão informando erros de sintaxe C++, embora do ponto de vista do MQL5 o código esteja correto.

Agora, vamos abrir a pasta de dados do terminal MetaTrader5.forge/MQL5 no VSCode:

Vamos tentar abrir algum arquivo de EA:

A realce de sintaxe está funcionando, e no canto superior direito da janela apareceram os botões de verificação de sintaxe MQL5 e de compilação do arquivo usando o MetaEditor. No entanto, todas as diretivas #include geram mensagens de erro. Isso acontece porque, apesar de o MQL5 se parecer com C++, ele não é C++, e a estrutura de diretórios dos arquivos padrão da biblioteca difere. Para corrigir esse erro, basta seguir a sugestão dada: adicionar nas configurações da extensão C/C++ for Visual Studio Code o caminho para a pasta MetaTrader5.forge/MQL5/Include:

Depois disso, a mensagem de erro desaparece, e o arquivo do EA é compilado com sucesso:

Com isso, vamos minimizar o VSCode por enquanto, pois agora entra em cena o protagonista principal, o MQL5 Algo Forge.

Criando o repositório principal

Acessamos o site https://forge.mql5.io/ e criamos uma nova conta ou utilizamos uma conta já existente da comunidade MQL5.community para fazer login:

No canto superior direito, no menu, escolhemos a opção "New repository":

Escolhemos um nome qualquer para o repositório (por exemplo, mql5-main). Ao clonar o repositório no computador local, será possível definir outro nome para a pasta raiz dos arquivos, então o nome aqui não é algo com que precisamos nos preocupar muito. Também já ativamos a inicialização do repositório, incluindo os arquivos .gitignore e README.md:

Perfeito, o repositório foi criado, e o primeiro commit foi feito automaticamente:

Para as próximas etapas, precisaremos copiar a URL do repositório, que no nosso caso é https://forge.mql5.io/antekov/mql5-main.git. Agora voltamos do navegador para o VSCode, o MetaEditor e o terminal MetaTrader 5.

Clonando o repositório

Para clonar o repositório para o computador local, precisaremos de uma pasta MQL5 vazia dentro da pasta do terminal. Mas, no momento, ela já está cheia de arquivos, então vamos proceder da seguinte maneira:

• Fechamos o VSCode, o MetaEditor e o terminal MetaTrader5.
• Renomeamos a pasta MQL5 (por exemplo, para MQL6).

Agora, a pasta com o nome MQL5 não existe mais dentro da pasta do terminal MetaTrader5.forge:

Abrimos essa pasta no VSCode e iniciamos o terminal integrado pressionando [Ctrl + `].

Copiamos URL do repositório e executamos no terminal o comando de clonagem, informando após a URL o nome da pasta raiz do repositório no computador local (que deve ser MQL5):

git clone https://forge.mql5.io/antekov/mql5-main.git MQL5

Se for a primeira vez que essa operação está sendo realizada, será necessário inserir suas credenciais, caso o repositório tenha sido criado como privado. Como resultado, será criada dentro da pasta do terminal uma subpasta MQL5 com dois arquivos (.gitignore e README.md)

Movemos todos os arquivos e pastas de MetaTrader5.forge/MQL6 para a pasta MetaTrader5.forge/MQL5 e excluímos MetaTrader5.forge/MQL6:

Abrimos a pasta MetaTrader5.forge/MQL5 no VSCode, clicamos no ícone do sistema de controle de versão na barra lateral esquerda e vemos que há muitos arquivos novos (581) na nossa pasta do repositório:

Mas nem todos esses arquivos precisam estar no nosso repositório, já que fazem parte da instalação padrão da plataforma MetaTrader. Em versões futuras, a composição, o local e o conteúdo desses arquivos da biblioteca padrão, bem como dos exemplos de EAs e indicadores, podem mudar. Não podemos fazer alterações nesses arquivos sem correr o risco de perdê-los ao atualizar o terminal MetaTrader ou ao migrar para outra pasta de trabalho. Portanto, não faz sentido incluí-los no nosso repositório.

Configurando arquivos ignorados

É exatamente para isso que serve o arquivo .gitignore. Nele, podemos listar quais arquivos devem ser ignorados pelo sistema de controle de versão Git. Isso é extremamente útil, pois em vez de centenas de arquivos aparecendo como alterações, veremos apenas os nossos próprios arquivos modificados. Como até agora não adicionamos nenhum código nosso ao repositório, todos os arquivos visíveis na lista de alterações devem ser ignorados.

Para isso, abrimos o arquivo .gitignore e substituímos o conteúdo padrão por algo como:

# ---> MQL5
# VSCode Preferences
.vscode/*

# Executables
*.ex5

# MQL5 Standard Files
/Experts/Advisors/
/Experts/Examples/
/Experts/Free Robots/
/Experts/Market/
/Files/
/Images/
/Include/Arrays/
/Include/Canvas/
/Include/ChartObjects/
/Include/Charts/
/Include/Controls/
/Include/Expert/
/Include/Files/
/Include/Generic/
/Include/Graphics/
/Include/Indicators/
/Include/Math/
/Include/OpenCL/
/Include/Strings/
/Include/Tools/
/Include/Trade/
/Include/WinAPI/
/Include/MovingAverages.mqh
/Include/Object.mqh
/Include/StdLibErr.mqh
/Include/VirtualKeys.mqh
/Indicators/Examples/
/Indicators/Free Indicators/
/Libraries/
/Logs/
/Profiles/
/Scripts/Examples/
/Scripts/UnitTests/
/Services/
/Shared Projects/
/experts.dat
/mql5.*

Dessa forma, informamos ao sistema de controle de versões que ele deve ignorar todos os arquivos de configuração do VSCode, todos os arquivos compilados de EAs e indicadores (já que, geralmente, apenas os códigos-fonte são mantidos no repositório) e todos os arquivos padrão localizados nas pastas listadas.

Exportando alterações

Após salvarmos as alterações no arquivo .gitignore, o VSCode mostra que há apenas uma modificação, justamente no próprio arquivo .gitignore. Todos os outros arquivos que voltaram para a pasta MQL5, que agora é a pasta raiz do nosso repositório mql5-main, parecem não existir. Ou seja, eles estão fisicamente na pasta, mas o sistema de controle de versão não os considera:

Vamos realizar o commit (confirmação) das alterações no repositório local: digitamos uma descrição para as mudanças feitas, por exemplo "Add standard files to .gitignore", e clicamos no botão Commit.

Neste momento, as informações sobre as alterações foram salvas apenas no repositório local. Para que elas sejam enviadas ao repositório remoto, é necessário executar o comando push. Isso pode ser feito de várias maneiras, por exemplo, clicando no botão "Sync Changes", selecionando a opção Push no menu que aparece ao clicar nos três pontos ao lado de CHANGES, ou executando o comando de terminal git push.

Antes de enviarmos o último commit ao repositório remoto, vale observar o histórico de commits em GRAPH. Atualmente, há dois commits visíveis com os comentários "Initial commit" e "Add standard files to .gitignore". À direita de cada commit, vemos o nome da branch colorido. No primeiro commit, aparece como origin/main, e no segundo, apenas main. Na verdade, trata-se da mesma branch main. O nome origin é um apelido do repositório remoto, portanto a prefixação origin/ indica que aquele commit é o último presente na branch main do repositório remoto. O segundo commit não possui essa marcação, o que significa que ele existe somente no repositório local até o momento.

Clicamos então em "Sync Changes":

As alterações foram enviadas com sucesso ao repositório remoto, e o marcador roxo da branch do repositório remoto foi movido para o segundo commit. Agora essas mudanças podem ser visualizadas acessando o repositório remoto via interface web:

Com isso, preparamos o novo repositório — que está praticamente vazio — para receber nossos arquivos. Atualmente, ele possui apenas uma branch chamada main, com apenas dois arquivos adicionados por nós. Todos os demais arquivos presentes na pasta de dados desta cópia do terminal estão sendo ignorados pelo sistema de controle de versões.

Criando um branch de arquivamento

Como mencionamos anteriormente, primeiro vamos colocar todos os nossos arquivos em uma única branch, para que eles passem a ser gerenciados pela ferramenta de controle de versões e, após um push, sejam enviados ao repositório remoto. Depois disso, poderemos acessar esses arquivos a partir do repositório remoto em qualquer outro computador, se necessário.

A criação de uma nova branch, assim como as demais operações de versionamento, pode ser feita de várias formas. No VSCode, por exemplo, podemos usar o menu de ações do repositório que aparece ao clicar nos três pontos. Devemos selecionar a opção "Checkout to...":

Em seguida, na lista de ações que aparece, escolhemos a opção "Create new branch..."

Na interface web do repositório remoto, podemos acessar a aba de branches (1 branch) e clicar no botão de criação de nova branch (destacado com um retângulo verde):

Existe uma diferença entre esses dois métodos. O primeiro cria uma nova branch no computador local, e, até que seja feito um push, o repositório remoto não saberá da existência dessa nova branch. O segundo método cria a branch diretamente no repositório remoto, e nesse caso o repositório local só tomará conhecimento da nova branch após a execução de um pull. Isso não representa nenhum problema, pois basta sincronizar os repositórios (executando os comandos pull & push).

Um terceiro método consiste no uso de comandos de terminal para gerenciar o repositório. Podemos criar uma nova branch com o nome "archive" no repositório local executando, por exemplo, o seguinte comando dentro da pasta do repositório:

git checkout -b archive

Se fizermos isso no terminal integrado do VSCode, veremos algo semelhante ao seguinte:

O terminal nos informa que o repositório foi trocado para a nova branch "archive", recém-criada. No histórico de commits, o nome da branch main foi substituído por archive. Na lista de alterações, aparece a sugestão de publicar essa nova branch no repositório remoto. Mas vamos aguardar para fazer isso depois que ela for preenchida com nossos arquivos.

Se você se lembra, tínhamos uma pasta inicial do terminal MetaTrader, na qual todos os nossos arquivos estavam localizados dentro da pasta MQL5. O repositório foi criado dentro de outra pasta do terminal. Agora, vamos copiar todo o conteúdo da pasta MQL5 do terminal antigo para a pasta MQL5 do novo terminal:

O sistema de controle de versões imediatamente detecta que novos arquivos apareceram na pasta do repositório, e eles são exibidos na lista de alterações, prontos para as próximas ações. Neste caso, queremos adicionar todos os arquivos novos ao índice (ou seja, colocá-los sob o controle do sistema de versões). Isso pode ser feito tanto pela interface do VSCode, clicando no botão "+" (Stage All Changes) no topo da lista de alterações, quanto executando o comando de terminal

git add .

Como podemos ver, agora ao lado de cada nome de arquivo na lista de alterações aparece a letra A em vez de U, indicando que o arquivo foi Adicionado (Added) ao índice. Resta apenas fazer o commit e enviar as alterações ao repositório remoto:

Como podemos ver, o último commit da branch main continua sendo o segundo commit, e o terceiro commit foi feito já na branch archive. Vamos verificar se essa nova branch foi enviada corretamente ao repositório remoto:

Sim, o último commit é visível no repositório remoto e pertence à nova branch archive. Ao clicar sobre ele, podemos visualizar quais alterações foram incluídas nesse commit:

Então, todos os arquivos foram adicionados à branch de arquivamento. Agora, vamos tentar voltar para a branch principal main.

Preparando para criar branches de projetos

Para alternar para a branch principal, executamos no terminal o comando

git checkout main

Nosso repositório local deve retornar ao estado em que estava antes de copiarmos todos os nossos arquivos. Mas, ao observar o conteúdo da pasta MQL5 após essa mudança, percebemos que várias pastas com arquivos de EAs ainda continuam lá:

Se olharmos com atenção, veremos que essas pastas contêm os arquivos compilados dos EAs. Acontece que, como esses arquivos foram excluídos do rastreamento do sistema de controle de versões, ao alternarmos da branch archive para a main, eles não foram afetados. Apenas os arquivos de código-fonte — que haviam sido adicionados ao índice do sistema de versionamento — foram removidos das pastas dos nossos projetos.

Isso não é muito prático, então vamos excluir os arquivos compilados e também os diretórios vazios que restaram após a exclusão desses arquivos. Claro, não vale a pena fazer isso manualmente, pois levaria tempo e provavelmente será uma tarefa recorrente. Por isso, vamos criar um script simples que execute esse processo.

Durante a criação do script, percebemos que apenas apagar os arquivos não é suficiente para restaurar a pasta raiz ao estado original após a troca de branch. Também precisamos remover as pastas que ficaram vazias depois da exclusão dos arquivos .ex5. Algumas pastas que podem, por padrão, estar vazias e não devem ser removidas serão adicionadas a uma lista de exceções. Nessa lista, incluiremos todas as pastas mencionadas no arquivo .gitignore, além da pasta .git, que contém os arquivos internos do sistema de controle de versões. 

O código do script pode ser algo assim:

import os


def delete_ex5_files_and_empty_dirs(path, excluded=['.git', '.vscode']):
    # Исключения
    excluded = {os.path.join(path, dir) for dir in excluded}

    # Обход всех директорий и файлов в дереве каталогов
    for root, dirs, files in os.walk(path, topdown=False):
        is_excluded = False
        for ex in excluded:
            if root.startswith(ex):
                is_excluded = True
                break
        if is_excluded:
            continue

        # Удаление всех файлов с расширением .ex5
        for file in files:
            if file.endswith('.ex5'):
                file_path = os.path.join(root, file)
                os.remove(file_path)
                print(f'File removed: {file_path}')

        # Удаление директорий, которые стали пустыми после удаления файлов
        for dir in dirs:
            dir_path = os.path.join(root, dir)

            # Если каталог пустой после удаления файлов
            if dir_path not in excluded and not os.listdir(dir_path):
                try:
                    os.rmdir(dir_path)
                    print(f'Empty folder removed: {dir_path}')
                except OSError:
                    pass  # Если что-то не так, просто игнорируем


excluded = [
    '.git',
    '.vscode',
    'Experts\\Advisors',
    'Experts\\Examples',
    'Experts\\Free Robots',
    'Experts\\Market'
    'Files',
    'Images',
    'Include\\Arrays',
    'Include\\Canvas',
    'Include\\ChartObjects',
    'Include\\Charts',
    'Include\\Controls',
    'Include\\Expert',
    'Include\\Files',
    'Include\\Generic',
    'Include\\Graphics',
    'Include\\Indicators',
    'Include\\Math',
    'Include\\OpenCL',
    'Include\\Strings',
    'Include\\Tools',
    'Include\\Trade',
    'Include\\WinAPI',
    'Indicators\\Examples',
    'Indicators\\Free Indicators',
    'Libraries',
    'Logs',
    'Presets',
    'Profiles',
    'Scripts\\Examples',
    'Scripts\\UnitTests',
    'Services',
    'Shared Projects',
]

if __name__ == '__main__':
    current_dir = os.getcwd()  # Текущая рабочая директория
    delete_ex5_files_and_empty_dirs(current_dir, excluded)

Salvamos o script com o nome clean.py na pasta raiz do repositório e o adicionamos ao sistema de controle de versões na branch principal. Assim, depois de trocar da branch de arquivamento para a main, basta executar esse script para que todos os arquivos compilados e as pastas vazias sejam removidos.

Considerações finais

Com isso, encerramos por ora nossos testes com a implantação do novo repositório. Todos os nossos arquivos foram transferidos com sucesso. Realizamos o trabalho preparatório para a futura criação de branches individuais no repositório, um para cada projeto. Como todo o código já está armazenado na branch archive, agora podemos criar novas branches aos poucos, conforme surgir a necessidade de retomar algum dos projetos iniciados anteriormente.

Também é bastante interessante experimentar a criação de um repositório público para publicar os códigos-fonte do nosso ciclo de artigos "Desenvolvendo um EA multimoeda". Ainda não está claro qual seria a melhor forma de organizar a separação do código correspondente a diferentes partes do ciclo, mas vamos trabalhar nessa questão em breve.

Obrigado pela atenção e até a próxima!

Conteúdo do repositório

#	Nome	Versão	Descrição
	MQL5		Pasta raiz do repositório (pasta de dados do terminal)
1	.gitignore	1.00	Arquivo com a lista de pastas e arquivos ignorados pelo sistema de controle de versões git
2	clean.py	1.00	Script para remover arquivos compilados e pastas vazias ao alternar para a branch principal do repositório