É melhor usar a mesclagem ou rebase quando duas pessoas estão no mesmo ramo de recurso remoto e tendo conflitos que serão dcommitidos com svn - git, git-svn, git-rebase, git-merge?

Meu colega e eu estamos tendo uma discussão vigorosa sobre estratégias de mesclagem e espero que possamos obter algumas informações para ajudar a resolvê-lo.

O tl: dr é: Devemos usar a mesclagem ou a reestruturação ao extrair alterações de uma ramificação remota para não refazermos constantemente a resolução de conflitos.

• svn: nosso repositório mestre de ouro
• tronco: svn remoto de rastreamento de ramificação git. Usado para preparar a mudança do git antes de se comprometer com o subversion.
• feature-branch: filial remota git onde o trabalho de mais de 2 colegas em um recurso é combinado
• colega1: filial local do primeiro colega
• colega2: filial local do segundo colega.

Estamos usando o excelente fluxo de trabalho de Sebastien Varette da O git-svn dcommit após a fusão no git é perigoso?.

O problema que estamos enfrentando é que toda vezo colega1 rebase do svn (rebatizando para o tronco e depois rebatizando para o colega1 antes de avançar para o recurso-ramificação quando terminar), em seguida, confirma no recurso-ramificação que conflitos entre si devem ser refazidos. A mesma resolução de conflito deve ser feita repetidamente - sempre que o fluxo de trabalho do svn rebase for concluído.

Note que estamos usando git rebase mirror un-3451 para esta rebase.

Meu argumento é que devemos usar git merge mirror un-3451. Meu entendimento é que isso resultaria em um commit marcado como a fusão de dois commits anteriores. Portanto, o git saberia não usar os commits anteriores, mas sim o merge commit.

Meu colega, por outro lado, argumenta queusar merge tornará o eventual merge com svn muito mais difícil e muito prefere usar rebase. Ele acha isso fácil - infelizmente não é ele quem está resolvendo todos os conflitos. Ele argumenta que usar um squash commit produziria o mesmo efeito.

Meu argumento é que o merge tem o mesmo efeito que um squash, mas inclui marcar os commits que foram incluídos.

Estado 1

svn-trunk:      A

git-trunk:       A"

remote-feature:   A"-----C
     /
c1-feature:        A"--C

c2-feature:         A"--D

Estado 2

C está em conflito com D no Arquivo 1 (F1). F1 tem o conflito resolvido, então D se torna D ".

git pull --rebase remote feature
git add F1
git rebase --continue
git push

Gráfico de consolidação:

svn-trunk:      A-----B
     (svn rebase)
git-trunk:       A"----B"

remote-feature:   A"-----C---------D"
     /        /
c1-feature:        A"--C        / (git push)
           /
c2-feature:         A"-------C--D"

Estado 3

Agora, o colega1 deseja obter as alterações do svn-trunk:

git checkout trunk
git svn rebase

e, em seguida, rebase-os para c2-feature

git checkout feature-branch
git rebase trunk

O rebase coloca B1 em c2-feature e então C e então pega D "e força a mesma resolução de conflito a se tornar D" "

Gráfico de consolidação:

svn-trunk:      A--------B
         (svn rebase)
git-trunk:       A"--------B"
         
remote-feature:   A"-----C-------D"
     / ----  
c1-feature:        A"--C          
               
c2-feature:         A"----------B"-C--D""

Cada vez que o git checkout trunk; git svn rebase; git checkout feature-branch; git rebase trunk; git push remote ciclo acontece todas as resoluções de conflito têm que ser feitas de novo e de novo.

Questões

1. se você rebase de svn, empurre para o remotobranch, faça com que o colega2 envie alguns commits para o branch remoto e, então, mais tarde, o colega1 faça um pull merge do branch remoto e o commit de mesclagem resultante mencionará os commits svn (e, portanto, causará um problema nos rebases subsequentes).
2. O que é melhor no cenário acima: rebase ou mesclagem?
3. A funcionalidade de releitura seria mais útil?

Muito Obrigado!

Respostas:

0 para resposta № 1

Primeiro, irei omitir os nós idênticos e reorganizá-los de forma que cada ramo tenha seu cabeçalho como o nó mais à direita, para representar melhor a árvore. (me corrija se a árvore estiver errada). Meus comentários estão em negrito.

Estado 1

svn-trunk:     A

git-trunk:       A"

c1/remote-feature: ----C



c2-feature:            --D

Em seguida, D foi rebaseificado como D "em C. Esta é a parte fácil (de entender). Poderia ter sido escolhida a dedo (ou D" simples ") se não houvesse conflito.

Estado 2

C está em conflito com D no Arquivo 1 (F1). F1 tem o conflito resolvido, então D se torna D ".

svn-trunk:     A-----B
     (svn rebase)
git-trunk:       A"----B"


c1-feature:         C

c2/remote feature:    D"

Agora chegamos à parte difícil.

Estado 3

Agora, o colega1 deseja obter as alterações do svn-trunk:

git checkout trunk
git svn rebase

e, em seguida, rebase-os para c2-feature

git checkout feature-branch
git rebase trunk

O rebase coloca B1 em c2-feature e então C e então pega D "e força a mesma resolução de conflito a se tornar D" "

Gráfico de consolidação:

svn-trunk:     A

git-trunk:       A"----B"
     
     
c1-feature:         C     
     
remote feature:       D"    

c2-feature:                   C----D""

Eu tenho alguma dificuldade em entender otransição do estado 2 para o estado 3, uma vez que seus comentários não parecem corresponder ao estado do gráfico (que parece mais uma tentativa de realocar o recurso c2 / remoto no tronco (em B "), com o recurso c2 como o resultado. Acredito que o que você realmente queria é este:

Estado Desejado 3

svn-trunk:     A-----B
     (svn rebase)
git-trunk:       A"----B"


c1-feature:               C

c2/remote feature:          D"

o que significa que você não conseguiu rebase A "-C-D"em A "-B" sem necessidade de resolução de conflito em relação a D ", o que é estranho porque isso não deveria acontecer (tentei reproduzir isso em um repo git-svn e funciona como pretendido). Estritamente falando, não é até mesmo um problema git-svn, já que você está meramente rebaseando um branch git contra outro. Realmente parece que você está tentando fazer o rebase corretamente, então posso presumir que algumas informações estão faltando, ou seja, o que descrevi não é o que realmente aconteceu.

---

0 para resposta № 2

Sou colega2.

Minha posição é que são os rebases frequentes deSVN para nosso branch de recursos que está causando a dor. Cada vez que fazemos o rebase, o conjunto de alterações é reproduzido em cima das alterações do SVN. Os conflitos reais estão em nosso conjunto de alterações reproduzido.

Idealmente, nós esmagaríamos nosso conjunto de mudanças em um único commit para que os conflitos ocorridos no conjunto de mudanças fossem resolvidos e não precisassem ser resolvidos novamente após outro rebase.

Como alternativa, poderíamos esperar para rebase do SVN até que o branch do recurso esteja completo e pronto para ser confirmado.

Não estou convencido de que mudar de rebasequando puxarmos para a fusão melhorará nosso processo em tudo. O ponto problemático são os rebases frequentes do SVN e eu não acredito que a fusão entre o branch de recursos e nossos branches locais irá melhorar o rebase do SVN.

---