É melhor mesclar "frequentemente" ou somente após a conclusão uma grande mesclagem de ramificações de recursos?


40

Digamos que várias ramificações estejam sendo desenvolvidas Ae B, assim como uma ramificação incremental de "correção de bugs" C.

Agora Cjá está "terminado" e mesclado no mestre. Ae Bainda estão em desenvolvimento e não serão corrigidos antes (talvez) de outro ramo de correção de erros ser mesclado no master.

É uma boa ideia mesclar o Cquanto antes nas ramificações dos novos recursos? Para que os novos recursos fiquem o mais próximo masterpossível? Ou é melhor deixar que o novo recurso seja desenvolvido em seu próprio "mundo", unindo-se ao mestre assim que terminar?

De qualquer forma, haverá conflitos, portanto é necessário gastar tempo em consertá-los.



5
@gnat que trata da fusão de ramificações de recursos em uma linha principal, estou me perguntando se é bom mesclar novamente o principal no recurso enquanto o recurso está sendo desenvolvido, para "resolver conflitos mais cedo".
paul23 22/07

1
@ paul23, eu diria que é uma necessidade prática.
Berin Loritsch 22/07

3
Honestamente, muitos dos meus problemas de versão desapareceram quando comecei a usar o design adequado no meu código, como isolar módulos e criar um modelo de trabalho bem definido. Se você está tropeçando demais em questões durante as mesclagens, pode ter outro problema mais sério à espreita em algum lugar. Um bom design é incrivelmente útil para evitar conflitos desnecessários.
T. Sar - Restabelece Monica

2
Você pode entrar no mestre regularmente para ficar perto "o suficiente" para não tornar a fusão mais tarde dolorosa.
Thorbjørn Ravn Andersen

Respostas:


71

Quanto mais tempo um ramo permanecer, mais ele poderá divergir do ramo principal e mais confusa e complicada será a mesclagem resultante quando finalmente terminar. Dez conflitos pequenos são mais fáceis de resolver do que um conflito maciço e podem realmente impedir que os desenvolvedores dupliquem ou desperdiçam esforços. Dado que, você deve se fundir masterem Ae Bregularmente; uma vez por dia é uma recomendação bastante comum, mas se você tiver muita atividade em suas filiais, poderá mesclar várias vezes ao dia.

Além de facilitar a resolução de conflitos, você menciona especificamente Cum ramo de correção de erros. Como desenvolvedor, eu gostaria que minha filial tivesse todas as correções mais recentes, para garantir que não estou repetindo o comportamento que levou a um bug ou escrevendo testes com base em dados errados.

De qualquer forma, haverá conflitos, portanto é necessário gastar tempo em consertá-los.

Se você sabe que haverá conflitos, talvez queira adotar uma estratégia de ramificação diferente. Mantenha várias alterações nos mesmos arquivos na mesma ramificação sempre que possível e reduza ou elimine o número de conflitos. Refatore as histórias para que elas sejam completamente independentes, tanto quanto possível, e refaça as ramificações para cobrir várias histórias (ramificação, recurso e história nem sempre são intercambiáveis).


33
Mesclar ou refazer , pois a reorganização geralmente produz um histórico de consolidação mais limpo.
chrylis -on strike - 22/07

11
@chrylis: O rebasing pode ser perigoso se "ramificações cobrirem várias histórias" for usado para significar que dois desenvolvedores trabalham na mesma ramificação.
meriton - em greve 23/07

9
@meriton a partir dos documentos oficiais: Não rebote os commit existentes fora do seu repositório e as pessoas podem ter baseado nele um trabalho. Se você seguir essa orientação, ficará bem. Caso contrário, as pessoas o odiarão e você será desprezado por amigos e familiares. LOL
Xtreme Biker restabelece Monica

6
@XtremeBiker: Uma nova versão do Git muda o histórico. O Git funciona como na vida real nesse sentido: para mudar a história, você precisa de uma conspiração. Há uma ramificação no repositório para o próprio Git que é regularmente reestruturada e é altamente pública. A razão pela qual isso funciona é que existe uma conspiração: todos que usam esse ramo concordam em reescrever a história em determinados momentos, para garantir que estejam em posição de ter tudo mesclado nesses momentos.
Jörg W Mittag

1
@ paul23 Considere seriamente entregar A e B em uma nova ramificação compartilhada antes de entregá-las ao mestre. Se os dois são revisões radicais, você os deseja juntos para uma rodada de testes antes de infligir a combinação ao mestre. Se você estiver confiante, poderá entregar um diretamente para o mestre e depois entregar o outro para uma nova filial atualizada. Você provavelmente deseja ver o código original do segundo recurso, caso a mesclagem ocorra mal ou precise reprojetar algo.
Sinc 23/07

11

Supondo que sua intenção seja eventualmente mesclar A, B de volta ao mestre e manter uma única base de código, nunca é uma boa idéia desviar-se do mestre demais. Desviar do master por muito tempo, especialmente quando correções de bugs e outros desenvolvimentos estão sendo mesclados para master, pois A, B está sendo desenvolvido, certamente causará conflitos.

Eu consideraria estratégias semelhantes às seguintes

  1. Quem é responsável por A, B deve observar o mestre de perto e se fundir em quaisquer alterações.
  2. Melhor ainda, se você possui automação de compilação e teste, certifique-se de que A, B sejam mescladas no mestre e passe nos testes todas as noites.
  3. Com base no seu comentário a outra resposta, parece que A, B pode demorar um pouco para se desenvolver. Nesse caso, você pode até considerar que A, B se fundem também para que, no final, você não tenha grandes problemas para mesclar os dois novamente ao mestre.
  4. Em um nível superior, pense por que você precisa de 2 linhas separadas de desenvolvimento longo. Você poderia dividir em fusões menores? Você poderia entrar em micro serviços separados?

5

Normalmente , muitas vezes é melhor do que um maciço.

Solicitações pull menores e mais frequentes são quase sempre melhores.

Comecei a usar sinalizadores de configuração principalmente para poder fazer solicitações pull menores mais cedo, para, por sua vez, mesclar o código com mais facilidade, mas deixar o recurso desativado. Quanto menor a solicitação pull, mais fácil é revisar o código, mesmo se houver mais solicitações pull totais. A maioria dos seres humanos de qualquer espécie não será capaz de fazer análises significativas de solicitações massivas de pull. É muito difícil para a RAM mental de alguém entender todas as implicações possíveis de uma mudança maciça de código.

Há uma sobrecarga extra na criação de um sinalizador de configuração, portanto, não vale a pena em recursos menores. Mas, de qualquer maneira, sua solicitação de recebimento será pequena.

Pode haver situações, no entanto, em que o recurso deve ser liberado de uma só vez. Mesmo assim, pode ser melhor fazer solicitações pull menores para outra ramificação feita para esse fim.

A maioria dos meus colegas geme quando alguém cria uma solicitação de recebimento massiva e, na maioria das vezes, com razão.

Observe também que, às vezes, eu preciso escolher os commits em ramos separados. Se o que precisa ser escolhido em cereja puder ser colocado em um único commit, será mais fácil movê-lo para outros ramos. Este é um caso em que, na verdade, ter poucos commits é melhor, mas não é exatamente o processo padrão se você está procurando.


1
Os sinalizadores de recursos podem ser caros (US $ 450 milhões em 45 minutos). Este exemplo também é mencionado pelo tio Bob (mas sem qualquer tipo de técnico (como seria de esperar)).
Peter Mortensen

1
Sim, existe a sobrecarga de eventualmente removê-los, embora geralmente não seja tão difícil. Pode-se mantê-los por mais tempo, mas a bandeira está fornecendo um uso maior. Concordo que, se feito por acaso ou sem acompanhamento, as coisas podem dar errado. Embora as coisas possam dar errado quando uma solicitação de recebimento grande se torna difícil de revisar. Por outro lado, algumas pessoas podem não estar em condições de adicionar algo como um sinalizador de configuração ao aplicativo em que estão trabalhando. Geralmente, ajuda com o UAT e a implementação de um recurso.
Mark Rogers

3

Em Refatoração de Martin Fowler, o conselho que ele dá é nunca deixar que um ramo se ramifique do mestre por mais de um dia. IIRC, faça uma pequena alteração, teste para garantir que não quebrou nada e depois faça a mesclagem novamente.


2
Bem, Ae Bmantenha grandes revisões radicais importantes sobre como o aplicativo funciona, elas não são "concluídas" dentro de um mês. No entanto, eles também são inúteis antes de terminar ...
paul23

8
Eles podem não ser inúteis antes de terminar - eles agregam valor, sendo um passo em direção ao resultado total e reduzindo o trabalho necessário no futuro. Usando técnicas como alternância de recursos, ramificar por abstração ou simplesmente fazer a parte da interface do usuário por último, deve ser possível mesclar com segurança o trabalho incompleto no mestre.
bdsl 22/07

1
é por isso que refazer seu local além de quaisquer alterações no ramo mestre é útil para o desenvolvimento a longo prazo. Mantém o seu trabalho como se tivesse acabado de ramificar o mais recente
NKCampbell

2

Outra opção para alterações de longa duração que podem estar concluídas, mas ainda não prontas para uso, é colocá-las atrás de um sinalizador de recurso para que possam ser mescladas no mestre, mas sem o risco de quebrar nada. Então, quando estiverem prontos para serem usados, o sinalizador de recurso poderá ser removido.


1
Sinalizadores de recursos = código zumbi (até ressuscitar)?
Peter Mortensen

@PeterMortensen Bem, você deve remover as bandeiras o mais rápido possível, mas isso pode funcionar em determinadas situações
Qwertie

3
@ PeterMortensen não se a bandeira estiver ativada para pelo menos uma pessoa
Ian
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.