Puxar alterações para a ramificação do recurso de rastreamento remoto, mantendo o fluxo de trabalho de ramificação simples

Question

Somos uma equipe de alguns desenvolvedores que possuem nosso branch master e desenvolvem recursos em branchs de recursos. Nós ramificamos os ramos de lançamento do master quando lançamos. Todas as correções de bugs são feitas no master e depois selecionadas no branch de lançamento relevante.

Queremos ter commits de mesclagem atômica para cada novo recurso que possamos reverter e dividir conforme descrito emhttps://gist.github.com/jbenet/ee6c9ac48068889b0912. Deveria nos dar uma história parecida com esta.

* aa55ffe -  (HEAD, master) D
* 88425f8 -  C
*   7bc519f -  Merge branch 'feature-X' into master
|\
| * 9364e61 -  feature-X: 2
| * bc76674 -  feature-X: 1
|/
* 88425f8 -  B
*   7bc519f -  Merge branch 'feature-Y' into master
|\
| * 0e0deea -  feature-Y: 4
| * 11079b5 -  feature-Y: 3
| * 9364e61 -  feature-Y: 2
| * bc76674 -  feature-Y: 1
|/
* c765ae3 -  A

Nosso problema surge quando temos vários desenvolvedores trabalhando no mesmo rastreamento de recursos para nossa versão remota do branch de recursos. Porque enquanto alguns desenvolvedores trabalham nesse recurso, a correção do bug pode ocorrer durante o desenvolvimento de um recurso no master. Agora queremos incluir essas correções de bugs no branch de recursos (ou seja, re-rebasear o branch de recursos de um novo estado no master onde o bug foi corrigido).

Existe uma maneira de fazer isso que não inclua corromper a ramificação de rastreamento remoto e, assim, estragar o histórico limpo e as outras cópias de trabalho dos desenvolvedores de recursos?

Fx Será possível escolher o bug no branch de recurso e fazer com que o git o resolva automaticamente após o rebase final, onde deixamos o branch de rastreamento remoto órfão antes de mesclar a nova versão rebaseada do branch de recurso no master?

Answer 1

Alguém poderia escolher o bug no ramo de recursos e fazer com que o git o resolvesse automaticamente

Isso pode funcionar se sua correção não apresentar conflitos. git clone https://gist.github.com/jbenet/7959265, veja o histórico e leia o reflog que colei lá.

Se você resolver o conflito na escolha seletiva, poderá remover o commit manualmente ao rebasear no master, logo antes de mesclar o PR (você pode marcá-lo/escrever um lembrete na mensagem de commit para resolver o conflito).

Mas, IMO, eu rebasearia o branch de recurso em cima do master quando o hotfix estivesse disponível. Isso é o mesmo que extrair quaisquer alterações do master (incluindo outras ramificações de recursos mescladas recentemente). Assim, você não fica preocupado com a desatualização de sua filial. Depende do que sua equipe gosta de lidar: remover hotfixes mesclados ou fazer rebases com frequência.

Answer 2

Se você realmente precisa da correção de bug em seu branch de recurso, mescle o branch de correção de bug. A conversa sobre bisect/rollback/o que quer que tenha sido FUD - bisect, na minha experiência, lida perfeitamente com históricos de mesclagem complicados. O modelo proposto naquele post cria problemas artificiais (como aquele sobre o qual você está fazendo perguntas) e, literalmente, seu único benefício é uma limpezaolhandohistória. Usamos esse modelo por alguns anos antes de percebermos o benefício de não fazer rebase. Eu faço rebase quando preciso limpar meu próprio histórico (squash commits, alterar mensagens de commit, etc), mas isso não afeta mais ninguém no downstream (como se eu estivesse trabalhando sozinho no branch).