Para possibilitar o controle de versões, edições por múltiplos usuários e manter os dados em um espaço confiável, todo o código fonte das bibliotecas, indicadores e robôs são mantidos em um repositório Git.
O acesso ao repositório é controlado por usuário e senha, e são individuais para cada desenvolvedor. Caso você tenha interesse em baixar e contribuir para o código, envie uma mensagem através do formulário de contato, ou outros meios de comunicação disponíveis da comunidade, solicitando a sua inclusão no cadastro de usuários do repositório, mantido no GitLab. Com isso você receberá um convite para acesso ao grupo e repositório e seus dados de login poderão ser usados ao seguir estes passos para a configuração do ambiente de desenvolvimento.
Preparação do Ambiente de Desenvolvimento
O software básico necessário para manipular os dados existentes no repositório é o Git. Como o Metatrader é baseado em Windows, é necessário instalar um pacote com os aplicativos Git para este sistema operacional. (O Git foi usado inicialmente para controle do código fonte do Linux, e tradicionalmente estava disponível apenas para este sistema operacional). O Git para Windows pode ser encontrado neste link:
https://git-scm.com/download/win
Adicionalmente, para se obter uma interface mais amigável, além de facilitar a operação com os comandos existentes no Git, sugere-se a instalação do TortoiseGit:
https://tortoisegit.org/download/
Ambos os programas tem instaladores que fazem todo o trabalho automaticamente, bastando manter as opções padrão. Ao final da instalação do TortoiseGit, é possível fazer uma configuração básica do Git, que inclui um nome de usuário e e-mails que serão registrados em todas as atualizações de código feitas por você.
Os arquivos de código fonte de MetaEditor (.mq5 e .mqh), como a maioria dos programas baseados em Windows, são salvos com uma codificação do tipo UTF-16LE, que não é suportado nativamente pelo Git. Com isso, algumas funcionalidades para exibição da diferenças entre versões de um mesmo arquivo ficam comprometidas. Para diminuir este problema, deve ser instalado mais um pacote adicional que permite realizar a conversão do padrão UTF-16 para UTF-8. Este programa é o iconv, que pode ser encontrado aqui:
http://gnuwin32.sourceforge.net/packages/libiconv.htm
Nesta página, selecionar a opção “Complete package, except sources” para download e fazer a instalação em seguida. Por padrão este programa será instalado em “C:\Program Files (x86)\GnuWin32\bin”, sendo que este diretório deve ser acrescentado no PATH do Windows. Para fazer isso, abrir a janela de propriedades do sistema (normalmente com o atalho Tecla_do_Windows+Pause/Break), e selecionar a opção “Configurações avançadas do sistema”.
Na janela “Propriedades do Sistema”, clicar na aba “Avançado” e a seguir no botão “Variáveis de ambiente…”.
Na próxima janela serão listadas as variáveis de ambiente configuradas, e deve-se editar a variável chamada “Path”:
Neste ponto basta incluir o caminho para o diretório de instalação do programa iconv: “C:\Program Files (x86)\GnuWin32\bin”.
Para finalizar a configuração basta abrir o menu de contexto (botão direito do mouse) em qualquer pasta do computadore, e selecionar a opção “TortoiseGit->Settings”:
Na janela de configurações, escolher o item “Git” na árvore da esquerda e clicar no botão “Edit global .gitconfig”:
Isto abrirá um editor de texto com o conteúdo do arquivo de configurações globais. Neste arquivo devem ser acrescentadas as linhas destacadas na imagem abaixo:
Segue o texto para cópia, se necessário:
[diff "utf16"] textconv = iconv -sc -f utf-16le -t utf-8
Após realizar estas etapas prévias, seu computador estará pronto para receber, editar e atualizar os códigos de robôs e indicadores da RobotCrowd.
Clonando o repositório da RobotCrowd
Após a instalação das ferramentas necessárias, o próximo passo é clonar o repositório na sua máquina. Para isso, abra a pasta de dados do Metatrader e acesse a pasta “MQL5”, conforme imagem abaixo:
A pasta “MQL5” de seu terminal é a raiz de todo código fonte usado no Metatrader. Os códigos compilados e settings também são encontrados nesta pasta. Para integrar o código fonte da RobotCrowd à sua instalação do Metatrader é importante configurar o espelho do repositório Git também nesta pasta. O Git não permite clonar um repositório para uma pasta que já contenha dados, portanto vamos primeiramente trazer os dados para uma pasta temporária para na sequência mover para a pasta “MQL5”.
Estando no diretório “MQL5” da pasta de dados do seu terminal Metatrader, clicar com o botão direito do mouse e escolher no menu de contexto a opção “Git Clone…”.
Será aberta uma janela para informações sobre o repositório remoto. Nesta janela deverá ser preenchido o campo URL com o endereço do repositório: https://gitlab.com/robotcrowddev/robotcrowd.git. O nome do diretório destino será preenchido automaticamente com base no nome do Repositório do link, portanto não é necessário alterá-lo. Após preencher o endereço basta clicar em “OK”, que o repositório será clonado para sua máquina.
Quando é feito o clone do repositório pela primeira vez, será necessário entrar com as suas credenciais no site GitLab:
Ao final da operação, você deve ver uma mensagem de sucesso:
Feito este procedimento, será criado um diretório “RobotCrowd-dev” em sua pasta MQL5:
Dentro desta pasta “RobotCrowd-dev” serão encontrados os arquivos do código fonte, além de alguns arquivos auxiliares do Git:
Observar a existência de uma pasta chamada “.git”, que está marcada na imagem acima. Esta pasta é extremamente importante, e nela fica armazenado todo o histórico do repositório local. Esta pasta é oculta, por isso aparece meio apagada na imagem. Caso você não esteja visualizando no seu Explorer, deve ser habilitada a opção para mostrar arquivos e pastas ocultos. A seguir exemplos de como isso é feito para Windows 7 e Windows 10.
O próximo passo é copiar todo este conteúdo da pasta “RobotCrowd-dev” e colar um nível acima, na pasta “MQL5”. Quando solicitado se deseja mesclar pastas e sobrescrever alguns arquivos, responder SIM. Ao final, sua pasta “MQL5” estará preparada com um repositório Git.
Trabalhando com o Git
O Git faz o controle de todos os arquivos do código fonte, comparando alterações com as versões anteriores e registrando tudo isso em um histórico. Quando uma etapa de desenvolvimento é cumprida, é necessário formalizar isso realizando um “commit”. Basicamente, todo o histórico de modificações de um repositório é controlado por commits, os quais podem ser verificados e pode-se inclusive retornar o código para uma versão anterior de maneira simples.
Os repositórios Git também são organizados em ramos de desenvolvimento, ou “branches”. Cada branch pode conter uma versão independente do código fonte, e a priori não interferem um no outro, a não ser que seja explicitamente solicitado. O branch principal do repositório é chamado de “master”, e neste ramo de desenvolvimento deve ser colocado apenas o código estável. Outros branches podem ser usados para desenvolvimento e testes, de forma que após a validação os arquivos podem ser mesclados (“merge”) com o branch master. A seguir será mostrado o processo básico de criação de branches e realização de commits com o Git.
Um novo branch pode ser criado a qualquer momento usando o menu de contexto dentro da pasta principal, no caso a “MQL5”. Basta clicar com o botâo direito do mouse e escolher a opção no menu de contexto “TortoiseGit->Create Branch…”.
Após a seleção desta opção, será aberta uma janela para preencher os dados do novo branch. Nesta janela deverá ser informado o nome do novo branch, além de uma descrição sucinta. Pode-se escolher também em que o branch será baseado, normalmente usamos o código válido do branch master, mas poderia ser usado um outro branch qualquer ou até um commit específico.
Completado este passo, o branch é apenas criado, mas ainda não está ativo na configuração. Para mudar o branch atual, deve-se usar o menu de contexto com a opção “TortoiseGit->Switch/Checkout…”. Lembrando que para mudar de branch não devem existir alterações sem commit, caso contrário o Git carrega as mesmas para o ouro branch. Dessa forma, deve-se sempre realizar um commit de qualquer modificação que tenha sido feita no código antes de trocar o branch ativo.
Quando a opção “Switch/Checkout” é selecionada, será mostrado um diálogo com os branches disponíveis, onde pode ser selecionado o branch criado anteriormente para ativação.
Ao selecionar um outro branch, todos os arquivos de código fonte são automaticamente atualizados para contemplar a revisão corrente no branch acionado. Neste exemplo, na primeira mudança o branch terá todos os arquivos iguais ao master, então serão feitas algumas modificações para exemplificar o comportamento do sistema de controle de versões. Conforme a imagem abaixo, foi inserido um comentário em um dos arquivos da biblioteca, e o mesmo foi salvo.
Os ícones mostrados na árvore da esquerda não são referentes ao controle do Git, mas sim da MQL Storage, que corretamente verifica as modificações no arquivo editado. Feita esta modificação, deve ser realizado um commit para que a mesma seja registrada no repositório. Para fazer isso, basta usar o menu de contexto na pasta “MQL5” e escolher a opção “Git Commit -> ‘teste’….”, como mostrado na próxima imagem.
Após selecionada esta opção, será aberta uma janela de commit, conforme mostrado na próxima imagem.
A janela de commit possui um espaço para inclusão de um comentário, descrevendo as alterações feitas, além de uma área onde são listados todos os arquivos que sofreram modificações. Estes arquivos podem ser selecionados ou não para fazer parte do commit. Caso se deseje corrigir um último commit feito, ou até acrescentar alguma coisa ao mesmo, pode-se marcar a opção “Amend Last Commit”. É interessante que os commits contenham etapas de desenvolvimento fechadas, portanto caso se tenha interesse em fazer um commit para registrar o trabalho e continuar posteriormente, pode-se usar esta funcionalidade “Amend Last Commit” para prosseguir com o trabalho em outro momento.
Para mostrar como os códigos de cada branch são independentes, vamos novamente fazer um checkout para o branch master, selecionando o mesmo com a opção “TortoiseGit->Switch/Checkout…” já usada anteriormente. Quando abrimos o mesmo arquivo no branch master, podemos ver que aquela linha de comentário acrescentada no branch teste não existe:
Agora podemos fazer uma alteração também no branch master para exemplificar a divergência entre os ramos de desenvolvimento.
Para registrar a modificação, é necessário também fazer um commit no branch master.
Neste ponto temos ambos os branches com commits diferentes, ou seja, seguiram revisões distintas que posteriormente deverão ser mescladas (TortoiseGit->Revision Graph).
A união destes branches pode ser feita com a função “merge”. Para isso, deve-se estar com o branch que receberá as modificações de outro selcionado, neste caso o branch master, e acessar a função através do menu de contexto “TortoiseGit->Merge…”.
Ao selecionar esta opção será apresentado um diálogo, onde pode ser escolhido o que será mesclado com o branch atual.
Após a seleção do branch, o Git tentará mesclar os dados, mas caso algum arquivo tenha sido modificado em ambos os branches (como ocorreu neste exemplo) será sinalizado um conflito que deverá ser solucionado manualmente.
Os conflitos devem ser analisados caso a caso e corrigidos para formar um código definitivo. Pode-se optar por procedimentos mais simples, como escolher a versão de um ou outro branch, mas em muitos casos deve ser feita a comparação entre os arquivos e verificar como pode ser composta a versão final.
Para ter acesso às opções, pode-se clicar no botão “Resolve”. Na janela seguinte serão mostrados todos os conflitos com as opções de resolução correspondentes.
Neste caso vamos usar a opção “Edit conflicts”, que abrirá uma espécie de editor de texto que permite fazer a comparação entre as versões do arquivo. Neste editor pode-se ver três janelas: na da esquerda temos a versão do arquivo do branch teste; na direita a versão do branch master; já na janela de baixo já é apresentada uma sugestão de composição entre os dois arquivos. Se a solução apresentada pelo editor atender basta marcar como resolvido o conflito e salvar o arquivo, caso contrário pode ser editado manualmente para gerar a versão final.
Após a edição dos conflitos ainda é necessário realizar o commit destas modificações para o branch master.
Concluídos esses passos teremos o branch master mesclado com o branch teste, e isso fica evidenciado no histórico de revisões:
Caso seja aberto o arquivo alterado após o “merge” no MetaEditor, podemos perceber agora ambas as linhas de comentário existentes na versão final.
Integração com o repositório remoto
O repositório remoto Git deve sempre conter o código atualizado e estável, especialmente em relação ao branch master. Pode ser usado também para fazer o backup de branches distintos, o que pode ser feito por qualquer usuário.
Uma vez que o branch master remoto pode ser atualizado a qualquer momento por outros usuários, é uma boa prática sempre fazer a atualização de sua cópia local antes de tentar realizar um “merge” entre branchs locais.
Para atualizar qualquer branch local a partir de um remoto, principalmente no caso do branch master, deve ser usada a função “TortoiseGit->Pull…”. Isso fará com que todas as revisões do repositório remoto sejam trazidas para o local e atualizá-lo, se necessário.
Para enviar um código alterado localmente para o mesmo branch no repositório remoto, ou mesmo caso se deseje criar uma cópia de um branch local no repositório remoto, é necessário usar a função “TortoiseGit->Push…”.
Na janela de preparação para o envio de dados (“Push”), é necessário escolher o branch local que será enviado, bem como o branch remoto que receberá os dados. Caso o branch remoto fique em branco, um novo branch será criado com o mesmo nome do local (quando for diferente do master). Se foi usada a função “Amend Last Commit” para um commit que já existia no repositório remoto, por padrão o Git não aceita revisões que não sejam para frente. Para contornar isso, deve-se marcar a opção “known changes”, que faz com que o Git sobrescreva a versão anterior do commit no repositório.
Esta foi uma descrição sucinta com exemplos de funcionamento do sistema de controle Git. Uma parte muito pequena das funcionalidades foi abordada aqui, já que o Git possui uma série de outras funções que podem ajudar no desenvolvimento colaborativo de códigos fonte.
Caso fique alguma dúvida, ou tenha alguma coisa a mais para compartilhar sobre o Git, pode-se usar o fórum da comunidade para discussão do assunto.