Como o Jenkins lida quando há conflito durante a realização do merge dos branchs para o branch de integração?
Existe alguma estratégia utilizada para eliminar a existência de conflitos?
Como o Jenkins lida quando há conflito durante a realização do merge dos branchs para o branch de integração?
Existe alguma estratégia utilizada para eliminar a existência de conflitos?
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:
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."