working Como usar o SVN, Branch? Tag? Tronco?




tutorial merge svn (13)

Outros afirmaram que isso depende do seu estilo.

A grande questão para você é com que frequência você "integra" seu software. Desenvolvimento baseado em testes, Agile e Scrum (e muitos, muitos outros) dependem de pequenas mudanças e integração contínua. Eles pregam que pequenas mudanças são feitas, todos encontram os intervalos e os consertam o tempo todo.

No entanto, em um projeto maior (pense em governo, defesa, 100k + LOC), você simplesmente não pode usar a integração contínua, pois não é possível. Nessas situações, talvez seja melhor usar ramificação para fazer muitos pequenos commits, mas trazer de volta para o tronco SOMENTE o que funcionará e está pronto para ser integrado à construção.

Uma ressalva com ramificação é que se eles não forem gerenciados adequadamente, pode ser um pesadelo em seu repositório para trabalhar no tronco, já que todo mundo está desenvolvendo a partir de diferentes pontos no tronco (que é, aliás, um dos maiores argumentos para integração contínua).

Não há uma resposta definitiva sobre esta questão, a melhor maneira é trabalhar com sua equipe para encontrar a melhor solução de compromisso.

Eu estava pesquisando um pouco e não consegui encontrar um bom guia de "iniciantes" para SVN , não no sentido de "como eu uso os comandos"; Como faço para controlar meu código-fonte?

O que eu gostaria de esclarecer são os seguintes tópicos:

  • Com que frequência você se compromete? Tão frequentemente quanto alguém pressionar Ctrl + S ?
  • O que é um Branch e o que é um Tag e como você os controla?
  • O que entra no SVN? Apenas código-fonte ou você compartilha outros arquivos aqui também? (Não é considerado arquivos versionados ..)

Eu não tenho ideia do que ramo e tag é, então eu não sei o propósito, mas meu palpite é que você faz upload de material para o tronco e quando você faz uma grande construção você move para o ramo? Então, o que é considerado uma grande compilação neste caso?


A frequência de confirmação depende do seu estilo de gerenciamento de projetos. Muitas pessoas se abstêm de se comprometer se quebrar a compilação (ou funcionalidade).

As ramificações podem ser usadas de duas maneiras, tipicamente: 1) Uma ramificação ativa para desenvolvimento (e o tronco permanece estável) ou 2) ramificações para caminhos de desenvolvimento alternativos.

As tags geralmente são usadas para identificar lançamentos, para que não se percam no mix. A definição de 'lançamento' é com você.



A política do nosso trabalho é assim (equipe multi-desenvolvedor trabalhando em framework orientado a objeto):

  • Atualizar a partir do SVN todos os dias para obter as alterações do dia anterior

  • Comprometa-se diariamente, por isso, se estiver doente ou ausente no dia seguinte, alguém pode facilmente assumir o lugar de onde parou.

  • Não cometa código que quebre nada, pois isso afetará os outros desenvolvedores.

  • Trabalhe em pequenos pedaços e comprometa-se diariamente COM COMENTÁRIOS SIGNIFICATIVOS!

  • Em equipe: mantenha uma ramificação de desenvolvimento e mova o código de pré-lançamento (para QA) para uma ramificação de produção. Este ramo só deve ter um código totalmente funcional.


Eric Sink, que apareceu no podcast de SO # 36 em janeiro de 2009, escreveu uma excelente série de artigos sob o título Source Control How-to .

(Eric é o fundador da SourceGear que comercializa uma versão compatível com plug do SourceSafe, mas sem a horribilidade.)


Para cometer, utilizo as seguintes estratégias:

  • cometer com a maior freqüência possível.

  • Cada mudança de característica / bugfix deve ter seu próprio commit (não comprometer muitos arquivos de uma vez, pois isso fará com que o histórico desse arquivo não seja claro - por exemplo, se eu alterar um módulo de logging e um módulo GUI independentemente e eu confirmar ambos de uma vez, ambas as alterações serão visíveis nos dois históricos de arquivos. Isso dificulta a leitura do histórico de arquivos),

  • não quebre a compilação em nenhum commit - deve ser possível recuperar qualquer versão do repositório e construí-lo.

Todos os arquivos necessários para criar e executar o aplicativo devem estar no SVN. Arquivos de teste e tal não devem, a menos que sejam parte dos testes de unidade.


Aqui estão alguns recursos sobre frequência de confirmação, mensagens de confirmação, estrutura do projeto, o que colocar sob controle de origem e outras diretrizes gerais:

Essas perguntas sobre estouro de pilha também contêm algumas informações úteis que podem ser de interesse:

Com relação aos conceitos básicos do Subversion, como branching e tagging, eu acho que isso é muito bem explicado no livro do Subversion .

Como você pode perceber depois de ler um pouco mais sobre o assunto, as opiniões das pessoas sobre o que é a melhor prática nesta área são muitas vezes variadas e, por vezes, conflitantes. Acho que a melhor opção para você é ler sobre o que outras pessoas estão fazendo e escolher as diretrizes e práticas que você acha que fazem mais sentido para você.

Eu não acho que seja uma boa idéia adotar uma prática se você não entender o propósito dela ou não concordar com a lógica por trás dela. Portanto, não siga qualquer conselho cegamente, mas sim faça a sua própria opinião sobre o que você acha que funcionará melhor para você. Além disso, experimentar maneiras diferentes de fazer as coisas é uma boa maneira de aprender e descobrir como você gosta mais de trabalhar. Um bom exemplo disso é como você estrutura o repositório. Não há maneira certa ou errada de fazê-lo, e muitas vezes é difícil saber de que maneira você prefere até que você tenha realmente tentado na prática.


Eu acho que o principal problema é que a imagem mental do controle de origem é confusa. Normalmente, temos tronco e ramificações, mas obtemos idéias não relacionadas de tags / releases ou algo a esse efeito.

Se você usa a idéia de uma árvore mais completamente, fica mais claro, pelo menos para mim.

Obtemos o trunk -> forms branches -> produz frutos (tags / releases).

A ideia é que você desenvolva o projeto a partir de um tronco, que então cria galhos uma vez que o tronco esteja estável o suficiente para manter o galho. Então, quando o ramo produzir uma fruta, você a extrai da ramificação e a libera como uma etiqueta.

Tags são essencialmente entregáveis. Enquanto tronco e galhos os produzem.



Como outros já disseram, o Livro SVN é o melhor lugar para começar e uma ótima referência, uma vez que você tenha conseguido suas pernas no mar. Agora, para suas perguntas ...

Com que frequência você se compromete? Tão frequentemente quanto se usaria ctrl + s?

Muitas vezes, mas não com a mesma freqüência que você pressiona ctrl + s. É uma questão de gosto pessoal e / ou política de equipe. Pessoalmente, eu diria commit quando você concluir uma parte funcional do código, por menor que seja.

O que é um Branch e o que é um Tag e como você os controla?

Primeiro, o tronco é onde você faz o seu desenvolvimento ativo. É a linha principal do seu código. Um ramo é algum desvio da linha principal. Pode ser um grande desvio, como uma versão anterior, ou apenas um pequeno ajuste que você deseja experimentar. Uma tag é um instantâneo do seu código. É uma maneira de anexar um marcador ou marcador a uma revisão específica.

Também vale ressaltar que na subversão, tronco, galhos e tags são apenas convenções. Nada impede que você trabalhe em tags ou tenha ramificações que são sua linha principal ou desconsidere o esquema de tronco de tag-branch. Mas, a menos que você tenha uma boa razão, é melhor ficar com a convenção.

O que entra no SVN? Apenas código-fonte ou você compartilha outros arquivos aqui também?

Também uma escolha pessoal ou de equipe. Eu prefiro manter qualquer coisa relacionada à compilação no meu repositório. Isso inclui arquivos de configuração, scripts de construção, arquivos de mídia relacionados, documentos, etc. Você não deve fazer o check-in de arquivos que precisam ser diferentes em cada máquina do desenvolvedor. Nem você precisa verificar subprodutos do seu código. Estou pensando principalmente em criar pastas, arquivos de objetos e coisas do tipo.


Eu me fiz as mesmas perguntas quando viemos para implementar o Subversion aqui - cerca de 20 desenvolvedores espalhados por 4 - 6 projetos. Não encontrei nenhuma fonte boa com "a resposta". Aqui estão algumas partes de como nossa resposta se desenvolveu nos últimos 3 anos:

- cometer quantas vezes for útil; nossa regra é comprometer sempre que você tiver feito um trabalho suficiente, que seria um problema ter que refazê-lo se as modificações fossem perdidas; às vezes eu cometo a cada 15 minutos ou mais, outras vezes pode ser dias (sim, às vezes me leva um dia para escrever uma linha de código)

- usamos ramos, como sugerido por uma de suas respostas anteriores, para diferentes caminhos de desenvolvimento; agora, para um de nossos programas, temos 3 ramificações ativas: 1 para o desenvolvimento principal, 1 para o esforço ainda não concluído para paralelizar o programa e 1 para o esforço de revisá-lo para usar arquivos XML de entrada e saída;

- nós raramente usamos tags, mas achamos que devemos usá-las para identificar as liberações para a produção;

Pense no desenvolvimento seguindo um único caminho. Em algum momento ou estado de desenvolvimento de marketing decidir liberar a primeira versão do produto, então você planta uma bandeira no caminho marcado '1' (ou '1.0' ou o que você tem). Em algum outro momento, alguma faísca brilhante decide paralelizar o programa, mas decide que isso levará semanas e que as pessoas querem continuar seguindo o caminho principal nesse meio tempo. Então você constrói um garfo no caminho e pessoas diferentes vagam pelos diferentes garfos.

As bandeiras na estrada são chamadas 'tags' e os garfos na estrada são onde os 'branches' se dividem. Ocasionalmente, também, filiais voltam juntas.

- colocamos todo o material necessário para construir um executável (ou sistema) no repositório; Isso significa pelo menos código-fonte e fazer arquivo (ou arquivos de projeto para o Visual Studio). Mas quando temos ícones e arquivos de configuração e todas as outras coisas, isso entra no repositório. Alguma documentação encontra seu caminho no repositório; Certamente, qualquer documentação, como arquivos de ajuda que possam ser parte integrante do programa, é um lugar útil para colocar a documentação do desenvolvedor.

Nós até colocamos executáveis ​​do Windows para nossas versões de produção lá, para fornecer um único local para pessoas que procuram por software - nossas versões do Linux vão para um servidor, então não precisam ser armazenadas.

- não exigimos que o repositório seja sempre capaz de fornecer uma versão mais recente que constrói e executa; alguns projetos funcionam dessa maneira, outros não; a decisão cabe ao gerente de projeto e depende de muitos fatores, mas acho que ele se decompõe ao fazer grandes mudanças em um programa.


* How often do you commit? As often as one would press ctrl + s?

O mais frequente possível. Código não existe a menos que esteja sob controle de código :)

Confirmações freqüentes (depois conjuntos de mudanças menores) permitem que você integre suas mudanças facilmente e aumente as chances de não quebrar algo.

Outras pessoas notaram que você deve se comprometer quando você tem uma parte funcional do código, no entanto acho útil se comprometer com um pouco mais de frequência. Poucas vezes notei que uso o controle de origem como um mecanismo rápido de desfazer / refazer.

Quando trabalho em meu próprio ramo, prefiro comprometer o máximo possível (literalmente, sempre que pressiono ctrl + s).

* What is a Branch and what is a Tag and how do you control them?

Leia o livro SVN - é um lugar que você deve começar quando aprender SVN:

* What goes into the SVN?

Documentação, pequenos binários necessários para compilação e outras coisas que têm algum valor vão para o controle de origem.


Eu acho que há duas maneiras de cometer frequência:

  1. Commit frequentemente, para cada método implementado, pequena parte do código, etc.
  2. Confirme apenas partes concluídas do código, como módulos, etc.

Eu prefiro o primeiro - porque usar o sistema de controle de origem é muito útil não apenas para projeto ou empresa, o primeiro é útil para o desenvolvedor. Para mim, o melhor recurso é reverter todo o código durante a pesquisa da melhor implementação de tarefa atribuída.







version-control