Olá Pessoal, tudo bom?
Há 3 anos atrás construí uma serie de artigos sobre versionamento de Projetos de Software, mas nunca mais mudei esses artigos ou acrescentei coisas novas. Essa é uma nova série, com todas as atualizações que a ferramenta do Bitbucket e do Eclipse sofreram nesses últimos 3 anos. Para ver todos os artigos sobre versionamento acesse esta página. Lá haverá um mapa mental com todos os artigos. Esse artigo mostra como resolver o conflito de arquivos diferentes que pode ocorrer durante uma operação de commit. Veja na continuação.
Eclipse – Resolvendo conflito entre arquivos diferentes – non-fast-forward
O erro de conflito entre arquivos, mais conhecido como non-fast-forward, é uma ocorrência que acontece diversas vezes durante o versionamento de projetos, principalmente se a equipe tiver um número grande desenvolvedores ou se determinadas classes sofrerem alterações constantemente.
Para mostrar como realizar a solução desse conflito é necessário primeiro fazer uma simulação de conflito. Assim vamos dividir esse artigo em duas partes. A primeira tratará como construir a simulação, que normalmente ocorrerá no dia a dia do versionamento do projeto. A segunda parte mostrará como corrigir o conflito e voltar a normalidade. No caso desse artigo, o conflito está ocorrendo porque temos versões diferentes de commits, e não pelos arquivos propriamente ditos.
Para uma explicação rápida com um exemplo, veja o vídeo abaixo:
Simulação de conflitos com arquivos distintos
Precisamos escolher dois arquivos distintos para realizar a simulação. Vamos escolher o arquivo SeminariosCientificosException para realizar a edição via Bitbucket e o arquivo Instituição para editar via Eclipse.
A primeira coisa a ser feita é adicionar um comentário a classe SeminariosCientificosException via o site do BitBucket, simulando dessa forma que alguém fez uma alteração no arquivo e realizou um commit. Para fazer essa edição online, por favor veja esse artigo. No nosso exemplo colocamos o comentário “Comentario para testes de conflito com arquivos diferentes”. O arquivo deverá ficar parecido com a Figura 01.
Agora abra no Eclipse a classe Instituicao e realize a adição de mais um comentário. No nosso caso adicionamos o comentário “comentario para testes de conflito entre arquivos diferentes”. Veja a classe Instituicao como exemplo na Figura 02
Realize o commit do arquivo Instituicao, adicionando este arquivo como staged changes e com uma mensagem descrevendo o porque do commit, conforme Figura 03. Feito esse processo clique no botão Commit and Push…
A dialog Push Results será exibida, Figura 04, como sempre acontece após um commit, o problema é que agora apareceu um Reject. Como é um pequeno detalhe que diferencia, é muito mais complicado ver se deu erro. No caso aqui deu um erro de non-fast-forward.
Vamos analisar o que aconteceu. Como mencionamos na primeira parte desse artigo, na ferramenta GIT a cada commit é criada uma nova versão dos arquivos para o repositório. Assim, suponha que ambos os repositórios estavam na versão 10.
No momento em que você foi até o repositório remoto e alterou um arquivo, o GIT alterou a versão do repositório para a versão 11, mas seu repositório local ainda permanecia na versão 10. Quando você realizou o commit de um novo arquivo, o seu repositório local passou para a versão 11, mas quando ele comunicou-se com o repositório remoto lá já havia a versão 11, então o GIT, para não perder nenhum arquivo commitado, força o erro non-fast-forward, rejeitando o commit.
Lembrando que não é somente quando você vai até o Bitbucket e altera um arquivo que ocorre esse erro. Se você estiver trabalhando em uma equipe, outras pessoas irão realizar commits e pushes para o repositório remoto, alterando assim a versão dos arquivos do repositório, ocasionando o conflito.
Antes de corrigirmos esse erro faça uma operação de Synchronize para ver como estão dispostos os arquivos alterados localmente e remotamente, conforme a Figura 05. No detalhe da Figura 05, podemos ver o compare do arquivo SeminariosCientificosException, mostrando o comentário realizado remotamente. Além disso, não há indicação de conflitos nos arquivos. Por fim, veja ao lado do nome do projeto as setas para cima com o número 1 e para baixo com o número 1. Elas indicam que existe uma versão mais recente no repositório local (seta pra cima) e uma versão mais recente no repositório remoto.
Correção da rejeição do Commit
Nesse momento começamos a correção dessa rejeição, ou seja, vamos deixar o repositório local novamente apto para realizar commits para o repositório remoto. O primeiro passo a ser realizado é fazer a operação de pull, através do Team > Pull. Essa operação faz com que o Eclipse traga os arquivos que estão no repositório remoto e apresente a dialog Pull Result, com todos os commits realizados, conforme Figura 06.
Após fechar a dialog, repare que as setas ao lado do número do projeto foram modificadas, Figura 07. Ao invés de haver uma seta para cima e outra para baixo ambas com o número 1 ao lado, agora temos apenas a seta para cima com o número 2. Indicando que existem duas versões locais que precisam ser enviadas para o repositório remoto. Mas porque duas? Uma é o commit que foi realizado e rejeitado anteriormente e outra é o merge automático que o Eclipse fez entre as versões do repositório remoto e local.
Agora é possível realizar uma operação de push para o repositório remoto, que tudo ocorrerá normalmente com o Eclipse apresentando a dialog Push Results conforme a Figura 08.
finnaly{
A resolução de conflitos entre arquivos commitados, principalmente quanto está dentro de uma equipe de desenvolvimento de software é muito importante. Ao conseguir o domínio sobre a correção de conflitos isso permite trabalhar mais facilmente com a equipe, muitas vezes gerenciando projetos muito grandes.
Duvidas ou sugestões? Deixe seu feedback! Isso ajuda a saber a sua opinião sobre os artigos e melhorá-los para o futuro! Isso é muito importante!
Até um próximo post!
Leave a Reply