Como é que a sua empresa realiza a junção de branches (merge) ou a reescrita da história (rebase) no sistema de controlo de versões?

Na nossa equipa, seguimos um fluxo de trabalho baseado no Git. Para integrar alterações, usamos duas abordagens principais: merge e rebase, escolhendo-as consoante a situação e o tipo de ramo.

Merge:

• Geralmente aplicado para fundir ramos de longa duração, por exemplo, dev em main, ou para integrar ramos de funcionalidades em dev.
• Cria um commit de fusão que mostra claramente quando ocorreu a integração de alterações de outros ramos.
• Mantém toda a história de commits, incluindo todas as bifurcações.

git checkout dev  // Muda para o ramo alvo
git merge feature/nova-funcionalidade  // Faz a fusão do ramo de funcionalidade

Rebase:

• Usado para manter uma história limpa e linear nos ramos de funcionalidades até à sua integração (normalmente em dev).
• Transfere os commits do ramo atual para o topo do ramo alvo (dev), reescrevendo efetivamente a história.
• Simplifica a história, evitando commits de merge para cada pequena funcionalidade ou correção.
• Importante: Nunca faça rebase em ramos públicos nos quais outros desenvolvedores trabalham, pois isso pode criar conflitos ao fazer pull de alterações.

git checkout feature/nova-funcionalidade  // Muda para o ramo de funcionalidade
git rebase dev  // Transfere os commits do ramo de funcionalidade para o topo de dev
// Resolve conflitos se necessário
git push --force-with-lease  // Usa --force-with-lease para um push seguro após rebase

Nosso fluxo de trabalho padrão:

1. Uma nova funcionalidade ou correção é desenvolvida num ramo separado (feature/..., fix/...).
2. Periodicamente (antes de um pull request ou para sincronizar com dev), o ramo de funcionalidade é rebaseado na versão atual de dev. Isto ajuda a resolver conflitos numa fase inicial.
3. Após concluir o desenvolvimento e a revisão de código, o ramo de funcionalidade é fundido em dev com no-ff (não fast-forward), para manter a informação da fusão. Ou, menos frequentemente, é feito um squash num único commit antes de fundir em dev para alterações muito pequenas ou correções.
4. De dev, são feitos lançamentos periódicos em main (ramo de produção), sempre por merge.

Assim, equilibramos a preservação do histórico de commits (merge) com a manutenção de um ramo de desenvolvimento limpo (rebase de ramos de funcionalidades).