Ramificar ou não ramificar?

Até recentemente, meu fluxo de trabalho de desenvolvimento foi o seguinte:

1. Obtenha o recurso do proprietário do produto
2. Criar uma filial (se o recurso for mais de 1 dia)
3. Implementá-lo em uma filial
4. Mesclar alterações da ramificação principal para a minha ramificação (para reduzir conflitos durante a fusão reversa)
5. Mesclar minha ramificação de volta à ramificação principal

Às vezes, havia problemas com a fusão, mas em geral eu gostei.

Recentemente, porém, vejo cada vez mais seguidores da ideia não criar ramificações, pois torna mais difícil praticar a integração contínua, a entrega contínua, etc. Git, Mercurial, etc.

Então a pergunta é: devemos usar ramos hoje em dia?

A menos que todos estejam trabalhando na mesma árvore de trabalho, você está usando ramificações, quer as chame assim ou não. Toda vez que um desenvolvedor faz check-out em sua árvore de trabalho, ele cria um ramo local de desenvolvimento separado e toda vez que faz check-in, ele faz uma mesclagem. Para a maioria das equipes, a questão não é se você usa ramos, as perguntas são quantas e com que finalidade ?

A única maneira de fazer uma integração verdadeiramente "contínua" é que todos trabalhem na mesma árvore de trabalho. Dessa forma, você saberá imediatamente se suas alterações afetam adversamente as de outras pessoas. Obviamente, isso é insustentável. Você precisa de um certo grau de isolamento em uma ramificação para realizar qualquer coisa, mesmo que essa "ramificação" seja apenas o diretório de trabalho local. O que é necessário é um equilíbrio adequado de integração e isolamento.

Na minha experiência, o uso de mais ramificações melhora o grau de integração, porque a integração é feita precisamente com as pessoas que precisam ser feitas, e todos os outros podem isolar mais facilmente problemas não relacionados, conforme necessário.

Por exemplo, passei o último dia rastreando três bugs relacionados à integração introduzidos recentemente em nossa compilação que estavam bloqueando meu trabalho "real". Depois de fazer a devida diligência em relatar esses bugs às pessoas que precisam corrigi-los, agora devo esperar até que eles terminem para continuar meu trabalho? Claro que não. Criei uma ramificação local temporária que reverte essas alterações para que eu possa ter uma linha de base estável contra a qual trabalhar enquanto ainda recebo as alterações mais recentes do upstream.

Sem a capacidade de criar uma nova ramificação para esse fim, eu seria reduzido a uma das três opções: reverter as alterações no repositório central, manter manualmente os patches que as revertem na minha árvore de trabalho e tentar não fazer check-in acidentalmente ou volte para uma versão antes da introdução desses bugs. A primeira opção provavelmente quebrará alguma outra dependência. A segunda opção é muito trabalhosa, portanto a maioria das pessoas escolhe a terceira opção, o que basicamente impede que você faça mais trabalhos de integração até que os erros encontrados anteriormente sejam corrigidos.

Meu exemplo usou uma ramificação local privada, mas o mesmo princípio se aplica a ramificações compartilhadas. Se eu compartilhar minha ramificação, talvez outras 5 pessoas possam continuar com suas tarefas principais, em vez de executar um trabalho de integração redundante, assim, em conjunto, é realizado um trabalho de integração mais útil. O problema com ramificação e integração contínua não é quantas ramificações você tem, é a frequência com que você as mescla.

a questão é se devemos usar filiais hoje em dia?

Há cerca de meio ano, fui designada para realizar um estudo para responder a essa pergunta. Aqui está o resumo, com base nas referências estudadas (listadas abaixo)

• não há uma "melhor" estratégia de ramificação comummente acordada aplicável a qualquer projeto
  • a maioria dos recursos parece concordar que a escolha da estratégia produtiva depende das especificidades específicas do projeto
  • nota. Com base no exposto acima, parece que quaisquer alterações na estratégia de ramificação do projeto precisam ser testadas, medidas e comparadas com outras opções testadas.
• A opinião popular é que a fusão com o Subversion exige muito esforço. Todos que compararam SVN e Git observam que a fusão é criticamente mais fácil com o Git
• um fator importante parece ser se as liberações de produção são originárias de tronco ou ramificações. As equipes que fazem lançamentos de produtos a partir do tronco (que parecem não ser muito populares) são essencialmente proibidas de usar uma estratégia de tronco instável . As equipes que fazem lançamentos de produtos das filiais têm mais opções de ramificação para escolher.
• estratégias populares parecem ser tronco estável, tronco instável e ramo de desenvolvimento (integração)

referências

• http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
  

  ... Decidir sobre a melhor estratégia de ramificação é um ato de equilíbrio. Você deve trocar os ganhos de produtividade contra um risco aumentado. Uma maneira de validar uma estratégia escolhida é considerar um cenário de mudança. Por exemplo, se você decidir alinhar ramificações com a arquitetura do sistema (por exemplo, uma ramificação representa um componente do sistema) e esperar mudanças significativas na arquitetura, poderá ser necessário reestruturar suas ramificações e os processos e políticas associados a cada alteração. Escolher uma estratégia de ramificação inadequada pode causar sobrecarga no processo e longos ciclos de integração e liberação que são frustrantes para toda a equipe ...

• http://www.cmcrossroads.com/bradapp/acme/branching/
  

  ... A integração frequente e incremental é um dos sinais de sucesso, e sua ausência costuma ser uma característica do fracasso. Os métodos atuais de gerenciamento de projetos tendem a evitar modelos estritos de cascata e abraçam os modelos em espiral do desenvolvimento iterativo / incremental e entrega evolutiva. Estratégias de integração incremental, como Merge Early e Freqüentemente e suas variantes, são uma forma de gerenciamento de riscos que tenta liberar o risco mais cedo no ciclo de vida, quando há mais tempo para responder a ele. A regularidade do ritmo entre integrações é vista por [Booch], [McCarthy] e [McConnell] como um indicador líder da saúde do projeto (como um "pulso" ou um "batimento cardíaco").  
   
  A integração precoce e frequente não apenas aumenta o risco mais cedo e em pequenos "pedaços", como também comunica mudanças entre colegas de equipe ...

• http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
  

  ... Na maioria dos sistemas de controle de origem, você pode criar centenas de ramificações sem problemas de desempenho; é a sobrecarga mental de acompanhar todos os galhos com os quais você realmente precisa se preocupar ... Ramificar é um animal complexo. Existem dezenas de maneiras de ramificar, e ninguém pode realmente dizer se você está fazendo certo ou errado ...

• http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
  

  ... Há muitos aspectos de um sistema a serem considerados ao ramificar seu código ... No final, o objetivo é fornecer uma caixa de proteção para o contexto em que o código está sendo gravado. Compreender as opções disponíveis, quando cada opção é mais adequada à situação atual e o custo dessas opções , ajudará você a decidir como e quando ramificar ...

• http://www.snuffybear.com/ucm_branch.htm
  Observe outras referências listadas aqui, afirma o autor que "Este artigo descreve três principais modelos de ramificação usados ​​em projetos de engenharia de software" não parece justificado. A terminologia usada não parece generalizada ( EFIX , Model-1,2,3 etc).

• http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf A
  referência apresenta um exemplo interessante de dificuldades na comunicação de estratégias de ramificação.

• http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
  ... Mantenha as coisas simples. Trabalhar diretamente fora do porta-malas é de longe a melhor abordagem na minha opinião.  
   
  Parece quase heresia quando realmente digito na tela, mas se você me aguentar por um momento, não apenas mostrarei por que acho que isso é essencial para um processo ágil, mas também mostrarei como para fazer funcionar ...  
   
  ... Se eu tivesse que basear meu raciocínio em um argumento sólido, seria o valor da integração contínua. Eu escrevi no blog sobre o valor do IC e as melhores práticas no passado. Sou um grande defensor da CI ...  
   
  ... Você realmente tem que perguntar a si mesmo uma pergunta aqui: "É tudo a sobrecarga você está incorrendo de fazer a sua ramificação complicada e fundindo estratégia, resultando em um valor real que não existe mais de uma estratégia mais simples?" ...  
   
  .. .Uma estratégia que efetivamente usei no passado e desenvolvi ao longo do tempo. Vou resumir brevemente aqui.

  • Todo mundo trabalha fora do porta-malas.
  • Ramifique quando você libera o código.
  • Ramifique uma versão quando precisar criar uma correção de bug para o código já lançado.
  • Ramo para protótipos.
    ...
    • http://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ... instruções detalhadas ...

• http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
  ... Finalmente, lembre-se de que não há uma estratégia ideal de ramificação e fusão. Depende do seu ambiente de desenvolvimento exclusivo ...

• http://blog.perforce.com/blog/?cat=62
  ... O pior cenário é que você apresenta um problema de "mesclagem semântica", em que o resultado de uma mesclagem automática está incorreto, mas compila OK e passa despercebido teste, possivelmente até sobrevivendo o tempo suficiente para ser um bug visível ao cliente. Eek!  
   
  Adicionando insulto à lesão, porque eles podem escapar da detecção por mais tempo, os problemas de mesclagem semântica são mais difíceis de corrigir posteriormente, pois a mudança não é mais recente na mente do desenvolvedor que originou a alteração. (Geralmente, é melhor mesclar as alterações logo após as alterações, de preferência pelo desenvolvedor que originou a alteração, se for prático) ...

  • http://blog.perforce.com/blog/?p=1635
    Observe que a política recomendada parece semelhante ao ramo de desenvolvimento, conforme definido em http://www.infoq.com/articles/agile-version-control#q11 e http : //msdn.microsoft.com/en-us/library/bb668955.aspx
  • Explicação do modelo de promoção: http://www.perforce.com/perforce/papers/life.html

• https://stackoverflow.com/questions/34975/branching-strategies Os
  membros da comunidade compartilham experiências diferentes em vários projetos usando várias estratégias de ramificação. Não há consenso acordado sobre "melhor" ou "pior".

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    leitura "clássica" - terminologia explicada como modelo de linha principal , linha de código etc.

• http://www.stickyminds.com/s.asp?F=S16454_COL_2
  Essencialmente, um breve resumo do material apresentado em http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

  • http://www.stickyminds.com/s.asp?F=S16511_COL_2
    ... Existem três abordagens comuns para decidir quando e como ramificar:
    • Crie a ramificação de liberação quando estiver com o "recurso completo" e planeje corrigir problemas de última hora nessa linha de código. Nesse caso, o ramo de lançamento é realmente uma "linha de código de preparação de lançamento", conforme descrito em Padrões de gerenciamento de configuração de software , pois você espera que ainda haja trabalho a ser feito.
    • Mude seu estilo de trabalho para evitar o trabalho final de integração, trabalhando fora da linha de desenvolvimento ativa.
    • Ramifique para o novo trabalho criando uma ramificação de tarefas e mesclando esse trabalho na linha de desenvolvimento ativa após a conclusão da liberação.
      ... Uma justificativa para ramificação é isolar o código no final de um release para que ele possa se estabilizar. O isolamento por ramificação muitas vezes oculta um problema de qualidade que acaba se manifestando no custo adicional de manter fluxos paralelos antes que um produto seja lançado. Ramificar é fácil. Em vez disso, é a fusão e a sobrecarga cognitiva de entender como as mudanças fluem entre ramificações que são difíceis, por isso é importante escolher um processo que minimize o custo de ramificação e fusão ...

• http://nvie.com/posts/a-successful-git-branching-model/ Estratégia orientada a Git.
  ... Consideramos origem / mestre como o principal ramo em que o código fonte do HEAD sempre reflete um estado pronto para produção .  
   
  Consideramos origem / desenvolvimento como o principal ramo em que o código fonte do HEAD sempre reflete um estado com as últimas alterações de desenvolvimento entregues para a próxima versão. Alguns chamariam isso de "ramo de integração". É aqui que todas as compilações noturnas automáticas são criadas ....

  • Um pouco semelhante à estratégia de ramificação de desenvolvimento , conforme definido em http://www.infoq.com/articles/agile-version-control#q11 e http://msdn.microsoft.com/en-us/library/bb668955.aspx

• http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
  ... as políticas do projeto variam amplamente quanto exatamente quando é apropriado criar uma ramificação de recurso. Alguns projetos nunca usam ramificações de recursos: as confirmações em / trunk são gratuitas. A vantagem desse sistema é que é simples - ninguém precisa aprender sobre ramificação ou fusão. A desvantagem é que o código do tronco geralmente é instável ou inutilizável. Outros projetos usam ramos ao extremo: nenhuma mudança está sempre comprometida com o tronco diretamente. Até as alterações mais triviais são criadas em um ramo de vida curta, cuidadosamente revisadas e mescladas ao tronco. Em seguida, o ramo é excluído. Este sistema garante um tronco excepcionalmente estável e utilizável em todos os momentos, mas ao custo de tremendassobrecarga do processo.  
   
  A maioria dos projetos adota uma abordagem intermediária. Eles geralmente insistem que / trunk compila e passa nos testes de regressão o tempo todo. Uma ramificação de recurso é necessária apenas quando uma mudança requer um grande número de confirmações desestabilizadoras. Uma boa regra geral é fazer esta pergunta: se o desenvolvedor trabalhasse por dias isoladamente e depois cometesse a grande alteração de uma só vez (para que / trunk nunca fosse desestabilizado), seria uma alteração muito grande para revisar? Se a resposta para essa pergunta for "sim", a alteração deve ser desenvolvida em um ramo de recurso. À medida que o desenvolvedor efetua alterações incrementais na ramificação, elas podem ser facilmente revisadas pelos pares.  
   
  Finalmente, há a questão de como manter melhor um ramo de recursos em "sincronização" com o tronco à medida que o trabalho avança. Como mencionamos anteriormente, há um grande risco de trabalhar em uma filial por semanas ou meses; as alterações no tronco podem continuar a chegar, a ponto de as duas linhas de desenvolvimento diferirem tanto que podem se tornar um pesadelo tentando mesclar o ramo de volta ao tronco.  
   
  É melhor evitar essa situação mesclando regularmente alterações de tronco na ramificação. Defina uma política: uma vez por semana, mescle o valor da última semana de alterações de tronco na filial ...

• http://thedesignspace.net/MT2archives/000680.html
  ... Esta seção do tutorial do Eclipse CVS é ​​baseada no artigo de Paul Glezen no site do Eclipse: Ramificação com Eclipse e CVS e é usado com sua permissão sob os termos de a licença EPL. As alterações que estou fazendo na versão dele são principalmente para expandi-lo com mais imagens e explicações passo a passo e integrá-lo aos meus próprios tutoriais para iniciantes, na tentativa de torná-lo mais acessível para iniciantes e designers. Desenvolvedores experientes provavelmente preferirão trabalhar com a versão de Paul ...

  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

• http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
  ... Aqui estão alguns dos modelos comuns de ramificação:  

  1. Modelo de ramificação por liberação: Uma das estratégias de ramificação mais comuns é alinhar ramificações com as liberações de produtos. Uma filial mantém todos os ativos de desenvolvimento de software para uma única liberação. Ocasionalmente, as atualizações precisam ser mescladas de uma versão para outra, mas geralmente nunca são mescladas. As ramificações serão descontinuadas quando uma liberação for retirada.  
  2. Filial por promoção: Outra abordagem muito comum é alinhar filiais com os níveis de promoção de ativos de software. Uma versão de desenvolvimento específica é ramificada em uma ramificação Teste, na qual todos os testes de integração e sistema são executados. Quando você conclui o teste, os ativos de desenvolvimento de software são ramificados na ramificação Produção e, finalmente, implantados.  
  3. Ramificação por tarefa: para evitar sobreposição de tarefas (ou atividades) e perda de produtividade, você pode isolá-las em uma ramificação separada. Lembre-se de que são ramificações de curto prazo que devem ser mescladas assim que a tarefa for concluída; caso contrário, o esforço de mesclagem necessário poderá exceder os benefícios de produtividade de criá-las em primeiro lugar.  
  4. Ramificação por componente: você pode alinhar cada ramificação com a arquitetura do sistema. Nesta estratégia, você ramifica componentes individuais (ou subsistemas). Em seguida, cada equipe que desenvolve um componente decide quando mesclar seu código de volta à linha de desenvolvimento que serve como ramo de integração. Essa estratégia pode funcionar bem se a arquitetura do sistema estiver em vigor e os componentes individuais tiverem interfaces bem definidas. O fato de você desenvolver componentes nas filiais permite um controle mais refinado dos ativos de desenvolvimento de software.  
  5. Filial por Tecnologia: Outra estratégia de ramificação alinhada à arquitetura do sistema. Nesse caso, as filiais estão alinhadas às plataformas de tecnologia. O código comum é gerenciado em uma ramificação separada. Devido à natureza exclusiva dos ativos de desenvolvimento de software gerenciados nas filiais, eles provavelmente nunca se fundem ...

• http://msdn.microsoft.com/en-us/library/bb668955.aspx
  ... Consulte as diretrizes de ramificação e mesclagem em "Diretrizes de controle de origem" neste guia para obter um resumo das diretrizes de ramificação e mesclagem. ... Ao ramificar, considere o seguinte:

  • Não ramifique, a menos que sua equipe de desenvolvimento precise trabalhar no mesmo conjunto de arquivos simultaneamente. Se você não tiver certeza disso, poderá rotular uma compilação e criar uma ramificação a partir dessa compilação posteriormente. A mesclagem de ramificações pode ser demorada e complexa, especialmente se houver alterações significativas entre elas.
  • Estruture suas árvores de ramificação para que você só precise mesclar ao longo da hierarquia (para cima e para baixo na árvore de ramificação) em vez de atravessar a hierarquia. A ramificação na hierarquia exige que você use uma mesclagem sem base, o que requer mais resolução manual de conflitos.
  • A hierarquia da filial é baseada no pai da filial e no filho da filial, que podem ser diferentes da estrutura física do código fonte no disco. Ao planejar suas mesclagens, lembre-se da estrutura lógica da ramificação em vez da estrutura física no disco.
  • Não se ramifique muito profundamente. Como leva tempo para executar cada mesclagem e resolver conflitos, uma estrutura de ramificação profunda pode significar que as alterações em uma ramificação filha podem levar muito tempo para serem propagadas para a ramificação principal. Isso pode afetar negativamente os cronogramas do projeto e aumentar o tempo para corrigir bugs.
  • Ramifique em alto nível e inclua arquivos de configuração e de origem.
  • Evolua sua estrutura de ramificação ao longo do tempo.
  • A mesclagem requer que um ou mais desenvolvedores executem a mesclagem e resolvam conflitos. A origem mesclada deve ser exaustivamente testada, pois não é incomum tomar decisões de mesclagem incorretas que podem desestabilizar a compilação.
  • A mesclagem na hierarquia de ramificações é especialmente difícil e requer que você lide manualmente com muitos conflitos que poderiam ser tratados automaticamente.  
    A decisão de criar uma ramificação pode ser reduzida se o custo de mesclar conflitos em tempo real for maior que o custo indireto de mesclar conflitos entre ramificações ...

• http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/

  • http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
  • http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
  • http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
    ... Alguma dessas reclamações do Subversion parece familiar?
    • Você é instruído aleatoriamente que "você precisa executar a atualização". Você faz uma atualização - que leva séculos para ser concluída. E então, finalmente, você vê que não houve alterações que precisavam ser baixadas.
    • Você é instruído aleatoriamente que "você precisa executar a limpeza".
    • Você tem grandes problemas de mesclagem. Por exemplo, você usa o ReSharper para renomear uma classe e, enquanto isso, outras pessoas atualizam essa classe. Você vê o temido erro de conflito em árvore (tremor). Ou ainda pior, você renomeia um espaço para nome e uma pasta inteiros (tremor duplo). Agora você realmente está em um mundo de dor.
    • Suas mesclagens tendem a ser cada vez mais manuais. Você frequentemente precisa usar o WinMerge porque o Subversion não tem idéia.
    • Você está sempre esperando o Tortoise atualizar / verificar modificações / qualquer coisa.  
       
      Eu tenho um repositório de subversão no meu pen drive USB. Eu recebo conflitos de árvore e fundo problemas com isso, e sou o único usuário!  
       
      O principal problema é a fusão ...  
       
  • "subversão é péssima" parece familiar. Hora de ouvir Joel e Linus ?

• http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
  discussão sobre as melhores práticas para estratégia de ramificação de isolamento de versão no caso de sistemas em evolução.

• http://branchingguidance.codeplex.com/
  "Orientação de ramificação do Microsoft Team Foundation Server" - documento enorme e detalhado com recomendações personalizadas para diferentes projetos: aqui a versão HTML . Prova que a Microsoft não acredita em estratégias de ramificação por abordagem de tamanho único.

• https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
  Qual é a melhor estratégia de ramificação a ser usada quando você deseja fazer a integração contínua? ... A resposta depende do tamanho da sua equipe e da qualidade do seu controle de origem e da capacidade de mesclar conjuntos de alterações corretamente complexos ...

  • http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ análise mais detalhada da interação de ramificação com integração contínua, com base na experiência concreta com Hudson / Jenkins - junto com algumas referências úteis
    . .A minha maior descoberta foi que, embora o IC seja sobre confirmar, forçar e obter feedback com frequência (ou seja, o cluster de IC fornece a você um feedback que sua estação de trabalho nunca poderia fornecer na mesma quantidade de tempo), o verdadeiro IC purista realmente tem mais um requisito - que a equipe precise trabalhar na mesma linha de base ...
    Materiais usados
    • Práticas recomendadas para várias ramificações - postar na lista Jenkins
    • É possível lidar com várias ramificações onde alguns trabalhos devem ser executados em cada uma sem duplicar - postar na lista Jenkins
    • Desenvolvimento paralelo com filiais - postar na lista de Jenkins
    • Configurar ou criar tarefa do Hudson automaticamente - stackoverflow.com
    • Integração Contínua com Desenvolvimento de Múltiplas Filiais - stackoverflow.com
    • Manipulando várias ramificações na integração contínua - stackoverflow.com
    • Integração contínua - Martin Fowler
    • Integração contínua - Wikipedia

• http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
  ... O CVS e o SVN estavam desencorajando toda a estratégia de ramificação / mesclagem, pois eram totalmente incapazes de fazê-lo ... ... Regra simples: crie uma ramificação de tarefas para cada novo recurso ou correção de bug que você deve implementar ... Pode parecer um exagero para usuários do SVN / CVS, mas você sabe que qualquer SCM moderno permitirá criar ramificações em um segundo, para que não haja sobrecarga real.  
   
  Nota importante: se você olhar com cuidado, verá que estou falando sobre o uso de ramificações de tarefas como listas de alterações de homens ricos ...

• http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
  ... A política de ramificação é influenciada pelo desenvolvimento objetivos do projeto e fornece um mecanismo para controlar a evolução da base de código. Existem tantas variações de política de ramificação quanto organizações que usam o controle de versão do Rational ClearCase. Mas também há semelhanças que refletem a adesão comum às melhores práticas ...

• http://blogs.open.collab.net/svn/2007/11/branching-strat.html
  ... O modelo do Subversion (ou modelo geral de código aberto com mais precisão) é o que está sendo mostrado no modelo de tronco instável. .

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  No campo de desenvolvimento de software, trunk refere-se ao ramo (versão) não identificado de uma árvore de arquivos sob controle de revisão . O tronco costuma ser a base de um projeto no qual o desenvolvimento progride. Se os desenvolvedores estão trabalhando exclusivamente no tronco, ele sempre contém a versão mais recente do projeto, mas, portanto, também pode ser a versão mais instável. Outra abordagem é separar uma ramificação do tronco, implementar alterações nessa ramificação e mesclar as alterações novamente no tronco quando a ramificação tiver se mostrado estável e funcionando. Dependendo do modo de desenvolvimento e confirmaçãopolítica, o tronco pode conter a versão mais estável ou menos estável ou algo intermediário.  
   
  Freqüentemente, o trabalho principal do desenvolvedor ocorre no tronco e as versões estáveis ​​são ramificadas, e correções ocasionais de erros são mescladas das ramificações para o tronco. Quando o desenvolvimento de versões futuras é feito em ramificações que não são de tronco, geralmente é feito para projetos que não são alterados com frequência, ou nos quais se espera que uma mudança demore muito tempo até que esteja pronta para ser incorporada no tronco. .

• http://www.mcqueeney.com/roller/page/tom/20060919
  ... Essas são notas de um seminário on-line sobre as melhores práticas do Subversion , realizado em 30 de agosto de 2006 pela CollabNet. ... Duas estratégias organizacionais: tronco instável vs. tronco estável ... ... PREFERIR um tronco instável quando possível ...

• https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
  No SVN, o tronco é o local recomendado para o desenvolvimento principal e eu uso esta convenção para todos os meus projetos. No entanto, isso significa que o tronco às vezes é instável, ou mesmo quebrado ... ... não seria melhor fazer o "desenvolvimento selvagem" em algum ramo como / branch / dev e somente se fundir ao tronco quando a construção é razoavelmente sólido?

  • ... O porta-malas é onde o desenvolvimento contínuo deve acontecer. Você realmente não deve ter problemas com o código "quebrado", se todos estiverem testando suas alterações antes de enviá-las. Uma boa regra geral é fazer uma atualização (obtenha todo o código mais recente dos repositórios) depois de codificar suas alterações. Em seguida, crie e faça alguns testes de unidade. Se tudo se compilar e funcionar, você deverá verificar ...
  • ... Nope tronco não é o melhor lugar. Em nossa organização, sempre seguimos esta abordagem: o tronco contém código de liberação, portanto, ele sempre compila. Com cada novo lançamento / marco, abrimos um novo ramo. Sempre que um desenvolvedor possui um item, ele cria um novo ramo para esse ramo de lançamento e o funde em um ramo de lançamento somente após testá-lo. O ramo de lançamento é mesclado no tronco após o teste do sistema ...

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ... Eu costumava trabalhar no porta-malas porque, para todos os projetos em que trabalhei, era eu o único desenvolvedor ou a equipe garantiu que todos os códigos de check-in passassem nos testes locais. Caso contrário, criamos (ainda) ramificações para correções de bugs, código grande para novos recursos etc.  
   
  Cerca de dois meses atrás, eu tive uma curta sessão de git com Kamal e ele compartilhou comigo a ideia de história / ramificação . E quando minha equipe começou a crescer com mais desenvolvedores, sinto a necessidade de incentivar mais ramificações e agora isso se tornou uma regra. Para um projeto com testes automatizados definidos com a configuração do IC, é garantido um tronco estável e essa prática pode se encaixar muito bem nele.  
   
  Nós não usamos o git, mas o Subversion, porque foi assim que começamos e ainda estamos confortáveis ​​com ele agora (na maioria das vezes) ...

• http://www.ericsink.com/scm/scm_branches.html
  Isso faz parte de um livro on-line chamado Source Control HOWTO , um guia de melhores práticas sobre controle de fonte, controle de versão e gerenciamento de configuração ...  
   
  ... Ramificação preferida de Eric Prática ... Mantenha um tronco "basicamente instável". Faça seu desenvolvimento ativo no tronco, cuja estabilidade aumenta à medida que você se aproxima do lançamento. Após o envio, crie uma ramificação de manutenção e mantenha-a sempre muito estável ...  
   
  ... No próximo capítulo , abordarei o tópico de mesclagem de ramificações ...

• http://marc.info/?l=forrest-dev&m=112504297928196&w=2
  Iniciando o correio do thread discutindo estratégias de ramificação para o projeto Apache Forrest

  • observe que atualmente o projeto parece usar um modelo de tronco instável com ramificações de liberação:
  • "O trabalho de desenvolvimento é realizado no tronco do SVN ... Existem" ramificações de liberação "do SVN, por exemplo, forrest_07_branch." ( diretrizes do projeto )
  • "Criando os pacotes candidatos à liberação ... 17. Crie uma ramificação de manutenção no SVN ..." ( Como liberar )

• Documentos de ramificação do O'Reilly CVS:
  http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
  

  • ... A filosofia de ramificação basicamente estável afirma que o tronco deve conter dados do projeto que estão sempre perto de estar prontos para lançamento ... ... Mais variações brandas dessa filosofia permitem que qualquer coisa que passe no teste de unidade do desenvolvedor seja mesclada no tronco. Essa abordagem relaxada exige que um candidato a liberação seja ramificado e submetido a uma análise completa do controle de qualidade antes da publicação ...
  • ... A filosofia basicamente instável afirma que o tronco deve conter o código mais recente, independentemente de sua estabilidade, e que os candidatos a lançamento devem ser ramificados para o controle de qualidade.
     
     
    ... Variações mais brandas também permitem ramificações para código experimental, refatoração e outro código de caso especial. A mesclagem de uma ramificação de volta ao tronco é feita pelos gerentes da ramificação. ...
    • Observe que o recurso acima não apareceu em nenhuma das pesquisas que realizei (as diretrizes relacionadas ao CVS não são mais populares?)

• Práticas recomendadas no SCM (artigo da forforce) em
  http://www.perforce.com/perforce/papers/bestpractices.html
  ... seis áreas gerais da implantação do SCM e algumas práticas recomendadas de granularidade grossa em cada uma dessas áreas. Os capítulos a seguir explicam cada item ...
  Áreas de trabalho, linhas de código, ramificação, propagação de alterações, compilações, processos ...

Se você tem várias equipes trabalhando em recursos diferentes ao mesmo tempo, não há como omitir a ramificação. Você deve compartilhar o código (parcialmente implementado) com os membros da equipe, impedindo que outras equipes obtenham seus recursos não concluídos.

Os ramos são a maneira mais fácil de conseguir isso.

Embora seja bom reduzir o ciclo de vida das ramificações e evitar trabalhar no mesmo módulo em duas ramificações ao mesmo tempo - você não terá conflitos \ problemas de mesclagem.

Recentemente, porém, vejo cada vez mais seguidores da ideia não criar filiais, pois dificulta a integração contínua, a entrega contínua etc.

Bem, torna mais difícil praticar a integração contínua, a entrega contínua etc. para você concretamente?

Caso contrário, não vejo razão para mudar sua maneira de trabalhar.

Obviamente, é uma boa prática seguir o que está acontecendo e como as melhores práticas atuais evoluem. Mas eu não acho que precisamos abandonar nossos processos / ferramentas / outros enfeites só porque X (e / ou Y e / ou Z) disseram que não são mais moda :-)

Que conjunto interessante de respostas. Em mais de 20 anos, nunca trabalhei em uma empresa que fazia mais do que um uso trivial de ramificação (geralmente apenas para liberações de ramificações).

A maioria dos lugares em que trabalhei se baseia em check-ins bastante rápidos e detecção / resolução rápida de colisões - a metodologia Agile ensina que você pode resolver os problemas mais rapidamente se notar os problemas enquanto as duas partes estão pensando ativamente sobre esse trecho de código.

Por outro lado, não usei muito o git e talvez seja a inclusão da tag git que influenciou essas respostas - entendo que branch / merge é um dado do git porque é muito fácil.

Sim, você deve usar ramificações para isolar qualquer (pelo menos médio) esforço de desenvolvimento. Consulte " Quando você deve ramificar? ".

O problema é mais usar mesclagens de avanço rápido (que incluem um histórico de ramificação em outro), desde que você esmague primeiro todos os "commits de ponto de verificação intermediários" (que podem ser um problema em caso de reversão ou git bisect).
Consulte " Entendendo o fluxo de trabalho do Git ", para distinguir ramificações privadas (que não devem ser enviadas por push) de ramificações públicas, que serão concluídas por ff mesclas (mesclagens de avanço rápido), desde que você faça a limpeza necessária na ramificação que está mesclando .
Veja também " Por que o git usa a fusão de avanço rápido por padrão? ".

Você deve usar absolutamente ramos. Há uma série de pontos fortes nisso.

• Você pode verificar seu trabalho à medida que estiver se preocupando em perder o trabalho devido a falhas no HD, perda de laptop etc., e isso não interromperá o IC principal.
• Você ainda pode fazer o IC, basta configurar seu próprio IC local para assistir à sua filial.
• Se o recurso for subitamente colocado em espera (isso nunca acontece), você pode simplesmente estacioná-lo.

Muito difícil nunca é uma desculpa. Sempre é preciso mais esforço para fazer o certo.

Se duas equipes trabalharem em sua própria filial, elas não verão as alterações da outra equipe, mesmo que ambas integrem a masterfilial. Isso significaria que seus ramos de desenvolvimento se separariam e, se uma das equipes se fundir master, a outra equipe precisará refazer muitas alterações.

Portanto, mesmo que você possua ramificações para recursos, eu recomendaria que você faça "backports" de todas as refatorações para a ramificação principal e mantenha a ramificação apenas para novos recursos.

• Refatorações de backport

Às vezes, acho que pode ser mais fácil usar as opções de recursos para desativar recursos novos e não testados que ainda não devem entrar em produção. Dessa forma, todas as outras equipes verão as mudanças e não haverá mesclagem do big bang.

• Use comutadores de recursos

Acabamos de passar por isso (de novo). Primeiro, tivemos todo o debate GIT / SVN, o que nos levou a estratégias de ramificação em geral.

As empresas maiores usam uma estratégia baseada em tronco, onde todos trabalham no mesmo ramo, e cria e integra continuamente a partir desse ramo. Evitar conflitos é feito usando modularização de código, troca de recursos e ferramentas inteligentes. Isso parece difícil .. porque é. Mas se você está tendo esse debate, é porque você foi vítima das fantasias das pessoas sobre ramificação. Alguns afirmam que usam a ferramenta SCM de inserção aqui com um mecanismo de ramificação de promoção totalmente compatível com sarbanes-oxley, e tudo é brilhante. Eles estão mentindo, enganando a si mesmos ou não estão trabalhando na mesma escala de sistema que você.

Ramificar e mesclar é difícil. Especialmente se você tem um negócio que muda de idéia regularmente e exige reversões, etc.

Esta frase pode salvar sua vida: O que está no SCM não é o mesmo que está em seus artefatos construídos!

Se você está tendo problemas com ramificações, é porque está usando mal o seu SCM. Todos nós fazemos isso há anos. Você possui um sistema no qual o SCM está sendo usado para determinar o que entra em sua construção final.

Esse não é o trabalho do SCM. O SCM é um servidor de arquivos glorificado. O trabalho de determinar quais arquivos do seu SCM vão para a sua compilação pertence às suas ferramentas de compilação.

O módulo A está sendo trabalhado e entra no seu release semanal. O módulo B é o módulo A, mas com o projeto X, e está sendo trabalhado, na mesma ramificação, mas não está sendo incorporado ao seu release. Em algum momento no futuro, você deseja liberar o projeto X. Então você diz à sua ferramenta de construção para parar de inserir o módulo A e começar a inserir o módulo B.

Haverá muito choro e torção de mãos sobre isso. Que iffery e uivos gerais. Esse é o nível de emoção que envolve algo tão simples quanto um repositório de arquivos, por mais inteligente que seja.

Mas aí está a sua resposta.

O principal problema com a ramificação é a dificuldade de mesclar novamente à ramificação principal quando o desenvolvimento estiver concluído. A mesclagem pode ser um processo manual e propenso a erros, portanto, deve ser evitado na maioria das vezes.

Algumas exceções notáveis ​​em que eu prefiro a ramificação são a refatoração maciça, recursos gigantes que demoram mais que um sprint para se desenvolver ou recursos disruptivos que interromperiam o desenvolvimento de outros recursos durante a maior parte desse sprint.

Eu recomendo este tipo de esquema de ramificação:

liberação - teste - desenvolvimento

Depois, do desenvolvimento, ramifique pelo desenvolvedor e / ou pelo recurso.

Cada um dos desenvolvedores tem um ramo para brincar e mesclar, e depois para o ramo de desenvolvimento, rotineiramente - idealmente todos os dias (desde que compilado).

Esse tipo de esquema funciona muito bem com muitos desenvolvedores e vários projetos na mesma base de código.

Nós fazer usar galhos, mas não no nível granular de recurso. Usamos ramos para cada sprint. Ramificar em essência não é uma coisa ruim da IMO, porque simula o conceito de SOC no recurso ou na camada de sprint. Você pode facilmente reconhecer e gerenciar qual filial pertence a qual recurso ou sprint.

IMHO, então a resposta é sim . Ainda devemos usar ramificação.

O processo na minha organização faz uso extensivo de filiais e (um processo que se parece um pouco com) integração contínua.

Em uma visão de alto nível, os desenvolvedores não se preocupam muito com a fusão com a linha principal, eles apenas se comprometem com a filial. um processo (semi-) automatizado verifica quais recursos estão programados para entrar na linha principal, mescla essas ramificações e cria o produto. O processo funciona porque na verdade integramos esse processo de fusão a partir do rastreador de problemas, para que a ferramenta de construção saiba quais ramificações serão mescladas.