3

O fluxo está correto:

main       A──B──C──D──E──F──G──H──I──J
            \     \        \        \
main_react   R1──M──R2──R3──M──R4──M──R5
                 ▲         ▲       ▲
                 │         │       │
               main      main    main

O problema dessa abordagem é: se um dos computadores tiver mal configurado e enviar as quebras de linha /r/l (padrão windows) enquanto todos os outros envia só /l (padrão linux / git) já acusa como conflito

A questão é: são conflitos reais? ou apenas conflitos que se resolvem automaticamente?

Suspeitamos desses conflitos aleatórios serem causados pois fizemos migração do Gitlab para o Azure há uns 2 meses

o próprio servidor ser configurado de forma diferente também impacta.

se estão acontecendo conflitos desnecessários é preciso fazer uma investigação do que está acontecendo, se é base suja, configuração errada, ...


eu sempre mantenho o desenvolvimento secundário em paralelo e merge frequente entre as duas branchs. se não fizer esses merges frequentes as duas ficarão "descoladas" e o merge final será extremamente doloroso.

ficar aquele medo de ter feito alguma decisão de resolução de conflito incorreta

Se a sua suíte de testes estiver bem desenvolvida, redondinha, pegando casos reais o medo deve diminuir, pois qualquer alteração real de produto deve ser pega pelos testes automatizados.

Carregando publicação patrocinada...
2

Show, também estava pensando sobre isso, sempre antes de fazer qualquer desenvolvimento fazer um pull da master e mergear na master_tec_25 (REACT) pra tornar sempre menos doloroso fazer uma vez no mês ou com menos recorrência.

A questão é: são conflitos reais? ou apenas conflitos que se resolvem automaticamente?

Os conflitos não se resolvem automaticamente, mas são conflitos que não deveriam acontecer, como artefatos de tabelas (Ex: Alguém adicionou campos novos na tabela e isso reflete pro artefato), por algum motivo conflita mesmo não termos alterado nada nesse artefato.

Ou até mesmo conflitos em arquivos Delphi (legado nosso) que nem se quer mexemos no projeto React.