Conflitos de Git podem ocorrer em diversos momentos ao tentar unir duas alterações diferentes de um mesmo arquivo. Por exemplo, aplicar um pull entre os repositórios remoto e local ou por merge entre duas branchs.
Se seu projeto foi criado na versão 2.7.x do Cronapp e o arquivo .gitignore não estiver configurado corretamente, é possível que alguns conflitos ocorram ao aplicar merge entre branchs. Projetos web e mobile possuem o diretório node_modules, essa pasta possui milhares de arquivos e é utilizada pelo Cronapp para armazenar diversas bibliotecas necessárias apenas durante o período de desenvolvimento do seu projeto. Por isso, recomendamos não versionar esse diretório em seu repositório remoto Git, afim de melhorar o desempenho ao usar e recompilar o seu projeto e evitar manter conteúdos desnecessários em seu repositório remoto.
Veremos como solucionar problema de conflito nas seguintes situações:
Caso queira saber como verificar se o diretório node_modules do seu projeto está configurado corretamente no .gitignore, acesse diretamente o subtópico Ignorar arquivos do node_modules.
Pré-requisitos
Antes de começar os passos, é necessário seguir os requisitos abaixo:
- Habilitar a opção Modo Avançado.
- Realizar um backup manual ou fazer o download do projeto (opção Baixar no menu de contexto do projeto).
Conflitos em merge
A forma de como resolver um conflito de merge será diferente em um arquivo do seu projeto e arquivos de biblioteca (pasta node_modules). Assim que o conflito ocorrer, os arquivos e seus diretórios pais ficam destacados em vermelho e uma mensagem de erro é exibida (Figura 1.1).
Figura 1.1 - Conflito em arquivos de bibliotecas
Caso 1: Arquivos do projeto
Conflito em arquivos do projeto, exemplo formulários (*.view.html), blocos de programação (*.blockly), diagramas (*.umlcd) e outros, devem ser resolvidos manualmente. Ou seja, acesse o arquivo em conflito para abrir a janela de conflitos e decidir qual conteúdo será persistido (Figura 1.2).
Figura 1.2 - Corrigindo conflitos em arquivos do projeto
Para mais detalhes, acesse o tópico Janela de revisões em Versionamento usando Git.
Caso 2: Arquivos de bibliotecas
Quando o conflito ocorrer em arquivos de bibliotecas (pasta node_modules), será necessário realizar alguns passos a mais. Nesse processo serão perdidas todas as alterações feitas desde o último commit.
Primeiro, vamos acessar o terminal e executar 2 comandos Git (Figura 1.3).
O comando a seguir tem o objetivo de tirar o repositório local do estado de merge, atualmente em conflito. (documentação)
$ git merge --abort
Vamos executar o comando abaixo para retornar o repositório local ao ponto do último commit. (documentação)
$ git reset --hard
Figura 1.3 - Comandos Git
Em seguida vamos executar o npm para obter e atualizar todas as bibliotecas dos projetos web e mobile (Figura 1.4).
Os comandos abaixo acessam o diretório node_modules web e instala o npm.
$ cd src/main/webapp/node_modules/ $ npm i
Figura 1.4 - instalando o npm
Os comandos abaixo acessam o diretório node_modules mobile e instala o npm como fizemos no projeto web acima (Figura 1.4)
$ cd ~/project/src/main/mobileapp/www/node_modules/ $ npm i
Ignorar arquivos do node_modules
Em projetos criados após a versão 2.8 do Cronapp, esse diretório já vem listado no arquivo .gitignore e qualquer atualização dentro do diretório node_modules é automaticamente desconsiderada ao realizar as ações de commit e push do Git. Porém, se esse arquivo não estiver configurado corretamente, alguns conflitos podem surgir ao realizar comandos de pull ou merge.
Para verificar se a configuração está correta, habilite a opção Modo Avançado, abra o arquivo .gitignore na raiz do projeto (destaque 1 da figura 1.5) e verifique se possui o termo "node_modules" (2). Caso não possua o termo "node_modules", adicione-o na última linha (2 da figura 1.5) e salve em seguida (para mais detalhes sobre o gitignore, acesse a sua documentação). Após isso, faça um commit e push do seu projeto.
Figura 1.5 - Ignorando os diretórios node_modules nos projetos mobile e web
O termo node_modules não deve estar acompanhado de caracteres, por exemplo "**/node_modules/**" ou "node_modules/**", caso esteja, retire os caracteres.
Após os passos acima, os diretórios node_modules do projeto web (Endereço: src/main/mobileapp/www/) e do projeto mobile (Endereço: src/main/webapp/) serão exibidos em cinza (destaque 1 da Figura 1.6), informando que não serão mais rastreados pelo Git.
Figura 1.6 - Diretório não rastreado pelo Git
Caso já tenha feito o push do diretório node_modules para o seu repositório remoto Git, recomendamos excluir esses diretórios diretamente por lá.
Dependendo do serviço Git em que seu projeto está hospedado, o processo para excluir o diretório pode variar um pouco. No GitHub, basta acessar o diretório, clicar o botão "..." (destaque 1 da figura 1.7), selecionar a opção Delete directory e realizar o commit pelo site.
Figura 1.7 - Deletando um diretório em um repositório remoto
Para os servidores Git que não possuem em seu ambiente visual uma opção para deletar um diretório do seu repositório remoto, será necessário executar comandos Git. Acesse o Terminal (destaque 1 da figura 2.8) e informe os comandos abaixo para remover todos os arquivos da pasta node_modules (web e mobile) no índice da árvore de arquivos Git, o conteúdo local não será afetado. Acesse a documentação oficial para mais detalhes sobre o comando git rm.
$ git rm -r --cache src/main/mobileapp/www/node_modules $ git rm -r --cache src/main/webapp/node_modules
Figura 1.8 - Removendo os índices dos arquivos da pasta node_modules do projeto web
Finalizada a execução dos 2 comandos, acesse a janela de Commit (menu de contexto Equipe > Commit ) e verifique que agora possui milhares de arquivos que serão removidos do repositório remoto (destaque 1 da figura 1.9). Informe uma mensagem e execute o Commit / Push.
Figura 1.9 - Executando o commit e push das últimas alterações
Caso 3: Erro de árvore suja
Esse problema pode ocorrer por diversas razões e caso ocorra com você, recomendamos que entre em contato com o nosso suporte para melhor orientação (Figura 1.10).
Figura 1.10 - Erro de árvore de trabalho suja