Você sente código fusão confortável?

Question

Esta manhã, li dois pareceres sobre refatoração.

• Opinião 1 (página não presente)
• Opinião 2 (página não presente)

Eles recomendam ramificação (e, posteriormente, a fusão) código para:

1. Mantenha o tronco limpo.
2. Permitir que um desenvolvedor se afastar de alterações de risco.

Na minha experiência (principalmente com StarTeam da Borland), a fusão é uma operação não-trival. E por essa razão, eu só ramificar quando eu devo (ou seja, quando eu quiser congelar um release candidate).

Em teoria, ramificando sentido marcas, mas a mecânica de fusão torná-lo uma operação muito arriscada.

As minhas perguntas:

• Você sente código fusão confortável?
• Você código ramo para outros fins que o congelamento de uma liberação razões candidato?

Answer 1

Alguns princípios solta orientadores:

• Ramo tarde e somente quando você precisa
• Merge cedo e muitas vezes
• Obter a pessoa certa para fazer a fusão, seja a pessoa que fez as alterações ou a pessoa que escreveu a versão original são os melhores

Ramificação é apenas mais uma ferramenta, você precisa aprender a usá-lo de forma eficaz se você deseja que o benefício máximo.

A sua atitude em relação à ramificação provavelmente deve diferir entre projetos distribuídos de Open Source (tais como aqueles em Git) e projetos de desenvolvimento da sua empresa (possivelmente em execução no SVN). Para projetos distribuídos você vai querer incentivar ramificação para maximizar a inovação e experimentação, para o último variedade que você vai querer maior controle e políticas checkin ditar para cada linha de código que ditam quando ramificação deve / não deve ocorrer, principalmente para "proteger" o código.

Aqui está um guia para a ramificação:
http://www.vance.com/steve/perforce/Branching_Strategies.html

Aqui está um guia mais curto com algumas das melhores práticas de alto nível:
https: //www.perforce. com.br / sites / default / files / pdf / high-level-forçosamente-best-practices.pdf

Answer 2

Ramificação pode ser doloroso, mas não deve ser.

Isso é o que git-como projetos (mercurial, bazar) nos diz sobre CVS e SVN. Em git e mercurial, ramificação é fácil. No SVN é fácil, mas com grandes projetos pode ser um pouco incondicional para gerenciar (por causa do tempo gasto na ramificação / processo de fusão que pode ser muito longo - em comparação com alguns outros como git e mercurial - e difícil se existem não conflitos -obvious). Que não ajudam os usuários que não são usados ??para ramificar muitas vezes a ter confiança na ramificação. Muitos usuários desconhecem os usos poderosos de ramificação apenas mantê-lo afastado para não adicionar novos problemas para os seus projectos, deixando o medo do desconhecido make-los longe de eficiência.

A ramificação deve ser uma ferramenta fácil e poderosa que teria que usar por qualquer razão boa o suficiente para ramo.

Algumas boas razões para filiais:

• trabalhando em um recurso específico em paralelo com outras pessoas (ou enquanto estiver trabalhando em outras características, alternativamente, se você está sozinho no projeto);
• ter várias versões de marca da aplicação;
• ter versões paralelas do mesmo aplicativo - como técnicas simultâneas desenvolvidas no mesmo tempo, a parte da equipe para ver o que funciona melhor;
• com recursos do aplicativo que está sendo mudado em um artista / designers (por exemplo, em jogos) ramo específico onde a aplicação é "estável", enquanto outros galhos e tronco são usadas para funções além e depuração;
• [acrescentar aqui usos úteis]

Answer 3

Ramificação é trivial. Fusão não é. Por essa razão, nós qualquer coisa raramente ramo.

Answer 4

Usando SVN, eu encontrei ramificação para ser relativamente indolor. Especialmente se você mesclar periodicamente o tronco para seu ramo de mantê-lo de ficar muito longe para fora de sincronia.

Answer 5

Nós usamos svn. Ele só nos leva cerca de 5 minutos para código ramo. É trivial em comparação com a quantidade de dor que nos salva de bagunçar tronco.

Answer 6

Trabalhando em uma base de código de milhões de linhas de código com centenas de desenvolvedores de ramificação é uma ocorrência diária. A vida do ramo varia dependendo da quantidade de trabalho que está sendo feito.

Para uma pequena correção:

• designer faz uma sidebranch fora da corrente principal
• faz alterações
• testes
• comentários
• fusões acumulado das alterações de fluxo principal para sidebranch
• itera através de uma ou mais das etapas anteriores
• fusões voltar ao fluxo principal

Para um recurso equipe multi-pessoa:

• equipe faz uma sidebranch recurso fora da corrente principal
• membro individual da equipe opera em função sidebranch como na abordagem "pequena correção" e fusões de recurso sidebranch.
• O primeiro-sidebranch funde periodicamente variações acumuladas da corrente principal para recurso sidebranch. fusões incrementais pequenas do mainstream para recurso sidebranch são muito mais fáceis de lidar.
• quando o recurso funciona, faça merge final fluxo principal de recurso sidebranch
• recurso de mala sidebranch a corrente principal

Para uma versão do software cliente:

• Faça um ramo release
• entregar correções conforme necessário para ramo release
• correções são propogated de / para o fluxo principal, conforme necessário

fluxos de versão do cliente pode ser muito caro para apoiar. Requer testar recursos - pessoas e equipamentos. Depois de um ano ou dois, o conhecimento desenvolvedor em específico córregos começa a ficar obsoleto como o fluxo principal se move para frente.

Você pode imaginar o quanto ele deve custar para a Microsoft para apoiar XP, Vista e Windows 7 ao mesmo tempo? Pense sobre os bancos de ensaio, a administração, documentação, atendimento ao cliente e, finalmente, as equipes de desenvolvedores.

Regra de ouro: Nunca quebrar a corrente principal desde que você pode parar um grande número de desenvolvedores. $$$

Answer 7

O problema ramificação é por isso que eu uso um sistema distribuído de controle de versão (Git no meu caso, mas também há Mercurial e Bazaar), onde a criação de um ramo é trivial.

Eu uso ramos vida curta o tempo todo para o desenvolvimento. Isso me permite mexer no meu próprio repositório, cometer erros e más escolhas, e depois rebase as alterações para o ramo principal de mudanças tão somente limpas são mantidos na história.

Eu uso tags para marcar código congelado, e é fácil nestes sistemas para voltar e se ramificam estes para correções de bugs sem ter uma carga de ramos de vida longa na base de código.

Answer 8

Eu uso o Subversion e considerar ramificação muito simples e fácil. Então, para pergunta de resposta 1 .. Sim.

A razão para ramificação pode variar enormemente. Eu ramo se eu sinto que eu deveria. Muito difícil colocar regras e razões para baixo para todas as possibilidades.

No entanto, na medida em que o "Permitir que um desenvolvedor se afastar de alterações de risco." Comente. I totalmente concordar com isso. I criar uma filial sempre que eu quiser realmente brincar com o código e desejo que eu era o único desenvolvedor trabalhando nisso .. Quando você ramo, você pode fazer isso ...

Answer 9

Eu estive em um projeto usando svn e TFS e ramificação por si só é uma coisa muito simples.

Usamos ramificação para release candidate, bem como para longa duração ou recursos experimentais e para isolar a interferência da outra equipe.

No momento só é doloroso na ramificação está se fundindo, porque um ramo velho ou intensamente desenvolvidos podem diferir muito do tronco e pode exigir um esforço significativo para merge de volta.

Dito acima, eu diria que ramificação é uma prática poderosa e útil que deve ser levado em conta durante o desenvolvimento.

Answer 10

Se a fusão é muito de uma dor, considere migrar para uma melhor VCS. Isso vai ser uma dor maior, mas apenas uma vez.

Answer 11

Nós usamos svn e adotaram uma regra para mudanças quebrando filiais. Pequenas mudanças são feitas direito no tronco.

Nós também lançamentos de filiais.

ramificação e mesclagem têm funcionado bem para nós. Concedido há momentos em que temos que sentar e pensar sobre como as coisas se encaixam, mas normalmente svn faz um ótimo trabalho de mesclar tudo.

Answer 12

Eu uso o svn, leva menos de um minuto para código ramo. Eu costumava usar Clearcase, demorou menos de um minuto para o código ramo. Eu também usou outros, menos, SCMs e eles nem não apoiar ramos ou eram muito doloroso para usar. sons StarTeam como o último.

Então, se você não pode migrar para um mais útil (na verdade, eu só ouvi coisas ruins sobre Starteam), então você pode ter que tentar uma abordagem diferente: ramificação manual. Trata-se de verificar o seu código, copiá-lo para um diretório diferente e, em seguida, adicioná-lo como um novo diretório. Quando você precisa mesclar, você iria verificar para fora ambos os diretórios e usar WinMerge para executar a fusão, o check-in os resultados para o diretório original. Estranho e potencialmente difícil se você continuar a usar o ramo, mas funciona.

O truque com ramificação não é tratá-la como um produto completamente novo. É um ramo - um dispositivo relativamente curta usado para fazer alterações separadamente e com segurança a um tronco principal produto. Quem pensa fusão é difícil ou é refatoração os arquivos de código tanto (ou seja, são renomear, copiar, criar novos, eliminar de idade) que o ramo se torna uma coisa completamente diferente, ou eles estão mantendo o ramo tanto tempo que as variações acumuladas suportar pouca semelhança com o original. Você pode manter uma filial por um longo tempo, você só tem que mesclar suas alterações de volta regularmente. Faça isso e ramificação / fusão torna-se muito fácil.

Answer 13

Eu só fiz isso algumas vezes, então eu não sou exatamente confortável com ele.

Já fiz isso para conduzir experimentos de design que se estendem por mais alguns checkins, então a ramificação é uma maneira fácil de parede off-se um jardim para brincar. Além disso, ele permitiu-me mexer enquanto outras pessoas trabalharam no ramo principal , então não perdemos muito tempo.

Eu também fiz isso ao fazer alterações de grande alcance que tornariam o tronco uncompilable. Tornou-se claro no meu projeto que eu teria que remover a segurança de tipos em tempo de compilação para uma grande parte da base de código (ir de genéricos para System.Object). Eu sabia que isso levaria um tempo e exigiria mudanças em todo o código base que iria interferir com o trabalho de outras pessoas. Seria também quebrar a construir até que eu estava completa. Então eu ramificada e retirados os genéricos, trabalhando até aquele ramo compilado. Eu, então, fundiu-lo de volta para o tronco.

Este acabou muito bem. Impediu um monte de toe-stepping, que foi ótimo. Esperemos que nada como isso nunca vai aparecer novamente. Seu tipo de uma coisa rara que um projeto vai mudar exigindo esse tipo de ampla edições que não resultam em um monte de código que está sendo jogado fora ...

Answer 14

Ramificada têm de ser correctamente geridos para fazer a fusão indolor. Na minha experiência (com Perforce) integração regular para o ramo da linha principal significava que a volta integração na linha principal correu muito bem.

Havia apenas raras ocasiões em que a fusão falhou. A integração constante a partir da linha principal para o ramo pode muito bem ter fusões envolvidos, mas eles eram apenas pequenas edições que as ferramentas automáticas poderia lidar sem intervenção humana. Isto significa que o usuário não "ver" estes acontecimento.

Assim, quaisquer fusões necessários na integração final muitas vezes poderiam ser manipulados automaticamente também.

Perforces 3-way ferramentas de mesclagem foram uma grande ajuda quando eles estavam realmente necessário.

Answer 15

Você se sente código de ramificação confortável?

Ela realmente depende da ferramenta que estou usando. Com Starteam, ramificação é, de facto não trivial (TBH, Starteam suga a ramificação). Com Git, ramificação é uma atividade regular e é muito fácil.

Você código ramo para outros fins que congelar um release candidate razões?

Bem, isso realmente depende do seu padrão de controle de versão, mas a resposta curta é sim. Na verdade, eu sugiro ler os seguintes artigos:

• Controle de Versão para várias equipes ágeis por Henrik Kniberg
• FeatureBranch por Martin Fowler

Eu realmente gosto o padrão descrito no primeiro artigo e ele pode ser aplicado a qualquer (não distribuído) Sistema de Controle de Versão, incluindo Starteam.

Eu poderia considerar a segunda abordagem (na verdade, uma mistura das duas estratégias) com (e apenas com) um Distributed Version Control Sistemas (DVCS) como Git, Mercurial ...

Answer 16

Nós usamos StarTeam e só ramo quando temos uma situação que exige (ou seja hotfix para a produção durante o ciclo de liberação ou algum projeto de longo alcance que as janelas se estende por vários libertação). Usamos Ver etiquetas para identificar lançamentos e que faz com que seja uma simples questão de criar ramificações mais tarde, conforme necessário. Todas as compilações são baseados nessas etiquetas vista e nós não construir código não marcado.

Os desenvolvedores devem estar seguindo um "código - teste - cometer" modelo e se eles precisam de uma visão para algum propósito testes ou desenvolvimento "arriscada" que criá-lo e gerenciá-lo. Eu gerenciar o repositório e criar filiais somente quando precisamos deles. Esses tempos são (mas não limitado a):

• Produção hotfix
• Os projectos com ciclos longos ou sobreposição de desenvolvimento
• reescrita extensiva ou desenvolvimento experimental

A ferramenta de mesclagem no StarTeam não é o maior, mas eu ainda tenho que correr em um problema causado por ele. Quem está fazendo a fusão só precisa ser muito certo de que eles sabem o que estão fazendo.

Criação de uma visão "Read Only Referência" em Star Team e defini-lo como uma configuração flutuante permitirá alterações no tronco para mostrar automaticamente no ramo. Definir itens para ramificar em mudança. Isso é bom para os esforços de desenvolvimento simultâneos.

Criação de uma visão "Read Only Referência" com uma configuração marcado é o que você usaria para hot fixes para lançamentos de produção existente (supondo que você tenha rotulado-los).

Answer 17

Ramificação é trivial, como a maioria ter respondido, mas a fusão, como você diz, não é.

As chaves reais são a dissociação e testes de unidade. Tentar dissociar antes você ramo, e manter um olho sobre o principal para ter certeza de que a dissociação ea interface são mantidos. Dessa forma, quando chega a hora de fusão, é como a substituição de uma peça de lego: remover o antigo peça, e os novos acessos peça perfeitamente em seu lugar. Os testes de unidade estão lá para garantir que nada foi quebrado.

Answer 18

A ramificação e fusão deve ser bastante simples.

• Eu me sinto muito confortável ramificação / fusão.
• Ramificação é feito por razões diferentes, dependendo do modelo do processo de desenvolvimento /

Há alguns modelos ramo diferente:

Aqui está um

  Trunk          
  .      
  .      
  .      
  ..         
  . ....     
  .   ...
  .      ..Release1
  .      
  .      
  ...        
  .  .... 
  .    ...Release2
  .      
  .      
  ..         
  . ...  
  .  .. 
  .    ...Release3
  .      
  .      

Agora, aqui está uma coisa curiosa. Suponha Release1 precisava de correções de bugs. Agora você precisa ramificar Release1 para desenvolver 1.1. Isso é OK, porque agora você pode ramificar R1, fazer o seu trabalho, e em seguida, mesclar volta para R1 para formar R1.1. Observe como isso mantém os diffs clara entre lançamentos?

Outro modelo ramificação é ter todo o desenvolvimento feito no tronco, e cada lançamento fica marcado, mas nenhum desenvolvimento adicional é feito em que a liberação particular. Ramos acontecer para o desenvolvimento.

  Trunk                                           
  .                                                         
  .                                                         
  .                                                         
  .Release1           
  .                       
  .                       
  .                   
  .                   
  .Release2           
  .                   
  .......                 
  .      ......       
  .           ...DevVer1
  .          .    
  .          .            
  .        ...DevVer2
  .      ....         
  .  ....             
  ...                     
  .Release3           
      .

Pode haver um ou dois outros modelos principais do ramo, eu não posso recordá-los fora do topo da minha cabeça.

A linha inferior é, o seu VCS precisa apoiar ramificação flexível e fusão. Por arquivo sistemas VCS apresentar uma grande dor IMO (RCS, Clearcase, CVS). SVN é dito ser um aborrecimento aqui também, não sei porquê.

Mercurial faz um ótimo trabalho aqui, como faz (eu acho) git.