Conflito durante o merge

Olá Daniel,

o git já é uma ferramenta bem esperta no sentido que ela vai fazer o melhor possível para resolver os conflitos quando você tenta fazer um merge ou rebase entre branchs. Mas eventualmente existem realmente cenários em que mesmo o git não consegue resolver sozinho algum conflito, então se isso acontece quando o Jenkins tenta fazer o Merge before build o teste já vai falhar automaticamente acusando problema de conflito no merge.

Nestas situações, o que o pessoal acaba fazendo é o merge manual da branch que teve conflitos para você mesmo resolvê-los no seu projeto e mandar para o repositório. E para tentar minimizar os problemas de conflito uma estratégia é ter um número pequeno de branchs a todo instante no projeto.

Então, pelo que entendi, normalmente devem existir alguns branchs para o projeto. Os que percebi foram:

• Master - contém o código utilizado para a geração do produto para a usuário final. Aqui a aplicação está estável, testada e integrada. Sem qualquer impedimento para deploy.
• Branch de Integração - contém o merge de todas as branchs de desenvolvimento com o Master, podendo eventualmente ficar inconsistente devido a problemas de merges ou falhas na execução de testes unitários.
• Branch de desenvolvimento - 1 ou mais branchs que contém o trabalho em andamento.

Está correto este entendimento?

Se estiver, é feito um novo merge do branch de integração para o Master? Como evitar um novo conflito neste merge e deixar o branch Master instável?

Ou o Master é simplesmente substituído pelo conteúdo do branch de integração, desconsiderando o conteúdo anteriormente ali existente e fazendo uma completa sobrescrita?

Olá Daniel,

a estratégia das branchs que existem variam bastante de projeto para projeto. Em geral, a única que aparece na grande maioria dos projetos é a Master como a branch principal, onde basicamente qualquer funcionalidade pronta do produto deveria estar e é a branch usada para o deploy.

Essa estratégia de branch de desenvolvimento é onde cada empresa acaba escolhendo a sua estratégia. Por exemplo, uma é a chamada feature branch, em que cada funcionalidade que será desenvolvida no sistema vira uma branch no repositório remoto. Neste casos o Merge before build ajuda bastante justamente para testar todas as branchs juntas. Mas o problema começa a existir justamente quando você acaba tendo muitas branches e conflitos começam a surgir entre elas, principalmente se as funcionalidades possuem dependências entre si.

Outra estratégia é você ter uma branch de desenvolvimento chamada de work apenas no repositório local de cada um dos integrantes do time. Qualquer funcionalidade tem que ser feita nesta branch work e depois enviada para a master no repositório remoto, seja usando a estratégia merge ou rebase. Isso evita ter muitas branchs no repositório remoto e exclui a necessidade do Merge before build dado que tudo vai para a Master. Mas para isso funcionar precisa de uma cuidado muito grande com a integração contínua, dos desenvolvedores enviarem commits novos para a master com frequência e deixando o projeto estável.

Por fim, no curso usamos a própria master como a branch de integração que você comentou, em que serão feitos os merges pelo Jenkins de todas as outras branchs. Mas como você comentou, caso não queria usar a Master como branch de integração você poderia criar uma branch separada para servir como integração. Como comentado na aula, o importante é que a branch usada para integração "não seja usado pelos membros da equipe para alterações."