Puxando as mudanças para o ramo de recurso de rastreamento remoto, mantendo o fluxo de trabalho de ramificação simples

Question

Somos uma equipe de alguns desenvolvedores que têm nossa ramificação principal e desenvolvem recursos em ramificações de recursos. Eu ramifico os ramos de lançamento do mestre quando eu liberar isto. Todas as correções de bugs são feitas no master e, em seguida, selecionadas no ramo de lançamento relevante.

Queremos ter confirmações de mesclagem atômica para cada novo recurso que podemos reverter e dividir como descrito no link . Deve nos dar uma história que se parece com isso.

* 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 ocorre quando temos vários desenvolvedores trabalhando no mesmo rastreamento de recurso para nossa versão remota do ramo de recursos. Como alguns desenvolvedores trabalham com esse recurso, a correção de bugs pode estar acontecendo durante o desenvolvimento de um recurso no master. Agora, queremos incluir essas correções de bugs no ramo de recursos (ou seja, re-rebaixando o ramo de recursos de um novo estado no mestre onde o bug é corrigido).

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

F.x. Poderia um cherry-pick o bug no branch de feature e ter o git resolvendo-o automaticamente após o rebase final, onde nós tornamos órfãos o branch de tracking remoto antes de mesclar a nova versão do branch de feature no master?

    

Answer 1

Could one cherry-pick the bug into the feature branch and have git automatically resolve it away

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 após a escolha, poderá remover manualmente o commit ao rebasing no início do master, antes de mesclar o PR em (você pode marcá-lo / escrever um lembrete na mensagem de confirmação resolvendo o conflito).

Mas IMO, eu rebasei o ramo de recurso em cima do mestre quando o hotfix estava disponível. Isso é o mesmo que extrair qualquer alteração do mestre (em outras ramificações de recursos mescladas recentemente). Assim, você não está preocupado com o fato de seu ramo estar desatualizado. Depende do que sua equipe gosta de manipular - removendo hotfixes mesclados ou fazendo rebasing com frequência.

    

Answer 2

Se você realmente precisa da correção do bug em sua ramificação de recursos, mescle a ramificação de correção de bug. A conversa sobre bisect / rollback / o que quer que seja FUD - bisect, na minha experiência, lida bem com complicados merge stories. O modelo proposto naquele post cria problemas artificiais (como aquele sobre o qual você está fazendo perguntas) e, literalmente, seu único benefício é uma história mais limpa . Usamos esse modelo por alguns anos antes de perceber o benefício de não rebaixar. Eu rebase quando preciso limpar meu próprio histórico (commits de squash, alterar mensagens de commit, etc) mas somente ele não afeta ninguém mais downstream (como se eu estivesse trabalhando no branch solo).