1
KauaMelchioretto
2 min de leitura ·

Preciso de ajuda! Estratégia técnica de branching

Contexto

Onde trabalho estamos atuando com a conversão do nosso front-end, migrando de Windows Web Forms para React para resolver problemas de legado e de vulnerabilidades que o web forms apresenta.

No momento atual do projeto, estamos utilizando ferramentas disponibilizadas pela própria tecnologia da empresa para fazer os controles de comunicação entre o backend (C# ASP .NET) e o front com o React.

O grande problema

Estamos fazendo todas as altearções em uma branch master_tec_25 que foi uma branch criada a partir da branch master do projeto. A branch master não possuí nenhuma implementação necessária para o projeto React funcionar, porém, ela recebe diversas alterações dirárias como:

  • Correções
  • Implementações
  • Melhorias

Com isso, para que a branch do react master_tec_25 não fique desatualizada, fazemos merges da branch master em cima da master_tec_25, mantendo a atualização do restante do produto e das implementações necessárias para o React.

Acontece que, nesses merges, ocorrem diversos conflitos, seja em arquivos que nem se quer alteramos na branch do React, quanto arquivos que realmente mexemos em algo para o projeto React, gerando bastante trabalho de resolver conflitos e ficar aquele medo de ter feito alguma decisão de resolução de conflito incorreta. Suspeitamos desses conflitos aleatórios serem causados pois fizemos migração do Gitlab para o Azure há uns 2 meses.

A prioridade é sempre aceitar o que está vindo do incoming (branch master) para manter o comportamento do produto e resolver os conflitos de arquivos que foram alterados na em ambas as branches, ou seja, que precisam de determinada linha desenvolvida na branch do React (master_tec_25) para o funcionamento.

Possíveis soluções pensadas

1 - Continuar com a mecânica de fazer os merges da master em cima da master_tec_25 de forma frequente para manter a saúde e o alinhamento das branches.

  • Ganho: Garante a atualização da branch.
  • Perda:
    • 1 - Consome tempo do desenvolvedor de resolver os conflitos.
    • 2 - Risco de merge indevido.

2 - Reunir todos os commits feitos para o projeto React com referências de implementações ou palavras chaves e fazer um re-branch em cima da master ao final de cada sessão de implementações para gerar um pacote final

  • Ganho: Garante que nada do produto teve seu comportamento alterado/gerado algum bug.
  • Perda: Caso fique algum commit de fora importante para o projeto React funcionar pode gerar algum comportamento não desejado/quebrado ao final da geração da branch final.

3 - Ambas as alternativas ao decorrer do projeto

Caso já tenham passado por algo parecido, de que forma resolveram este problema?
Existem estratégias já consolidadas para isso?

Carregando publicação patrocinada...
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.

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.