Práticas recomendadas de SVN - trabalhando em equipe

Estou começando com o SVN. Eu conheço os comandos básicos e entendo os princípios básicos. Eu queria saber se alguém tem dicas ou melhores práticas para trabalhar com o Subversion em um ambiente de equipe.

Posso ver a vantagem de adicionar mensagens razoavelmente detalhadas ao submeter o código, mas há outras coisas que devo ter em mente?

Obrigado por todas as ótimas respostas - elas ajudaram muito.

Incentive commits frequentes. Os colegas de equipe novos no controle de versão podem sentir que precisam manter o código fora do repositório até que "funcione direito". Ensine a todos a se comprometerem o quanto antes e com frequência para encontrarem os problemas o mais rápido possível. Em vez de segurar o código até que funcione, proponha que seus colegas de equipe criem branches para recursos que podem quebrar o tronco. Isso leva a ...

Estabeleça uma prática de ramificação e marcação. Além de branches para recursos, incentive seus colegas de equipe a usar branches para grandes correções de bugs. Marque as principais correções de bugs no início e no final do trabalho. Manter tags (e possivelmente ramificações) para lançamentos de produção / qa.

Estabeleça uma política para o tronco e cumpra-a. Um exemplo pode ser, "o tronco deve sempre construir sem erros." ou "o tronco deve sempre passar em todos os testes de unidade". Qualquer trabalho que ainda não atenda aos padrões do tronco deve ser feito em uma filial.

Não comprometa mudanças de formatação com mudanças de código

Se você deseja reestruturar o espaço em branco de um arquivo gigante ( Control+ K+ D), tudo bem. Confirme a alteração de formatação separadamente da alteração lógica real. O mesmo se aplica se você deseja mover funções em arquivos. Comprometa a mudança separadamente da edição real.

Um dos conceitos-chave que sempre mantenho é comprometer as alterações de código relacionadas juntos . O corolário é não confirmar alterações de código não relacionadas no mesmo commit . Isso significa não consertar 2 bugs em um commit (a menos que seja a mesma correção), e não cometer metade de uma correção de bug em cada um dos 2 commits. Além disso, se eu precisar adicionar algum novo aprimoramento ou algo a uma parte não relacionada do sistema que eu preciso para algum outro trabalho, eu comprometo o aprimoramento separadamente (e primeiro). A ideia é que qualquer mudança que alguém possa querer ter por conta própria (ou reverter por conta própria) deve ser um commit separado. Isso vai poupar toneladas de dores de cabeça quando chegar a hora de fazer mesclagens ou reverter recursos corrompidos.

Muito já foi mencionado, e aqui estão mais alguns:

1. Se você tiver arquivos que não deseja no controle de origem (por exemplo, configuração, arquivos compilados, etc.), adicione-os à lista de ignorados . Dessa forma, você percebe qualquer arquivo que se esqueceu de adicionar, sempre esperando uma lista vazia de arquivos exibida como desconhecida para o SVN.

2. Adicione um evento post commit que enviaria um e-mail para sua lista de discussão de desenvolvedores (ou um específico para este destino) relacionado à alteração confirmada e, de preferência, o patch para ela.

3. Integre com o seu rastreador de bug para que as referências aos commits apareçam nos bugs / solicitações de recursos com links para os diffs. Rastreadores de bugs como o MantisBT suportam isso.

4. Considere a integração com integração contínua (por exemplo, CruiseControl.NET ), NAnt para Build e NUnit / VS para testes de unidade. Dessa forma, assim que um usuário faz o check-in do código ou em um intervalo agendado, o código é compilado, os testes de unidade são executados e o desenvolvedor obtém feedback do processo. Isso também alertaria o resto da equipe se o repositório estiver quebrado (ou seja, não compilado).

Bem, o básico:

• Crie tags antes de iniciar o controle de qualidade em uma versão
• Crie tags antes de mudanças arriscadas (ou seja, grandes refatores)
• Crie ramificações para versões lançadas para congelar o código.
• Certifique-se de que as pessoas saibam atualizar antes de começar a trabalhar em um trecho de código e atualize mais uma vez antes de enviá-lo.
• O SVN permite vários check-outs do mesmo arquivo por diferentes usuários. Certifique-se de que todos resolvam qualquer conflito que possa ocorrer.
• Nunca use a mesma conta SVN para mais de um usuário. Coisas terríveis podem resultar.

As respostas que as pessoas estão dando são ótimas. Muito disso está resumido na documentação do usuário svn para melhores práticas para SVN .
Repetir:

1. Configure a estrutura do seu repositório (você deve ter a raiz do projeto com tronco, ramos e tags por baixo)
2. Escolha sua política de ramificação (ramos privados, ramos por marco / lançamento / bug, etc) e cumpra-a - eu recomendaria mais ramos em vez de menos, mas não há necessidade de ramos privados
3. Escolha sua política de reclassificação - quanto mais tags, melhor, mas o mais importante é decidir sobre suas convenções de nomenclatura de tag
4. Escolha sua política ao comprometer-se com o tronco - mantenha o tronco o mais "limpo" possível, ele deve ser liberado a qualquer momento

Gostaria de resumir as práticas recomendadas que adoto:

1. Não submeta binários . Deve haver um repositório separado para binários, como Nexus , Ivy ou Artifactory .

2. Deve haver estrutura de repositório . Pessoalmente, eu uso a seguinte estrutura de repositório:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Use uma lista específica de tipos de ramificação . Minha lista é a seguinte: experimental , manutenção , versões , plataformas , lançamentos .
4. Use tipos específicos de tags : PA(pré-alfa), A(alfa), B(beta), AR(lançamento alfa), BR(lançamento beta), RC(candidato a lançamento), ST(estável).
5. Minimize a necessidade de fusão . Deve haver regras quando a fusão é possível / incentivada e quando não é.
6. Numeração de versão . Deve haver uma abordagem de numeração de versão estabelecida para seguir. Normalmente, é descrito em um documento como Plano de Gerenciamento de Configuração de Software, é uma parte da documentação do projeto de alto nível. Pessoalmente, eu uso uma abordagem de numeração de versão complexa. De acordo com essa abordagem, as versões têm os seguintes padrões: Nxx ( ramificações de manutenção / suporte), NMx (ramificação de versão), NxK (construção), NMK (versão).
7. Comprometa-se tão frequentemente quanto possível . Se tende a ser difícil (por exemplo, quando deve haver muitas mudanças a serem feitas para implementar o recurso e até mesmo compilar o código), ramificações experimentais devem ser usadas.
8. O tronco deve conter o desenvolvimento mais recente . Por exemplo, quando há a escolha de onde desenvolver a nova versão principal ( Nxx ) do aplicativo, em tronco ou em ramal, a decisão deve ser sempre feita em favor do tronco . A versão antiga deve ser ramificada no ramo de manutenção / suporte . Ele assume que há uma distinção clara entre as versões principais e suas especificidades (arquitetura, compatibilidade) surgem o mais cedo possível .
9. Política estrita de 'não quebrar a construção' em ramos de lançamento . Nesse ínterim, não deve ser necessariamente restrito para o tronco , contanto que ele possa ter desenvolvimento experimental ou base de código que precisa de problemas de mesclagem para ser resolvido.
10. Use svn: externals . Permitirá modularizar seu projeto, estabelecer procedimentos transparentes de gerenciamento de releases, dividir e conquistar diferentes funcionalidades.
11. Use o rastreamento de problemas . Você poderá apontar a referência do problema dentro da mensagem de confirmação.
12. Desative mensagens de confirmação vazias . Isso pode ser feito usando ganchos de pré-confirmação.
13. Defina quais ramificações você deseja integrar continuamente . Por exemplo, eu prefiro usar integração contínua para ramos de tronco , manutenção e liberação .
14. Estabelecer política de integração contínua para diferentes tipos de filiais. Como mencionei anteriormente, as regras mais rígidas de "não quebre a compilação" se aplicam para liberar branches, enquanto o trunk e os branches de manutenção podem ser quebrados às vezes. Também há uma diferença entre a lista de inspeções executadas no tronco / manutenção e ramos de liberação .

Você pode encontrar um esboço de minhas melhores práticas de subversão na forma de um diagrama que ilustra os princípios principais da abordagem de gerenciamento de configuração de software que uso.

Uma coisa que achei muito útil é a propriedade svn: external que significa que você pode fazer referência a diretórios de outros repositórios em seus próprios. Oferece maneiras realmente interessantes de organizar seu código e dados. Alguns exemplos são:

1. Se você tiver repositórios separados para códigos de módulos / bibliotecas diferentes e referência nos que você está usando. Isso significa que você pode ter um meta-repositório para cada executável. Se for um pequeno executável que usa apenas alguns módulos, você não precisará fazer o checkout de toda a árvore. Um efeito disso é que você obtém números de revisão SVN por módulo.
2. Adicionar grandes dados binários, como versões compiladas de bibliotecas ao repositório de código, geralmente é considerado um mau hábito, mas pode ser muito conveniente. Se você apenas adicionar todas as versões de todas as bibliotecas que usa a um repositório diferente, você pode obter o melhor de dois mundos. Você faz referência nas versões das bibliotecas que usa em seu repositório de código. Ao verificar seu repositório de código, você obterá o código e os binários também. No entanto, os binários são armazenados em um grande repositório do qual você não precisa fazer backup tão rigorosamente quanto o seu código-fonte e o repositório de código-fonte permanece pequeno e contém apenas texto.

Use integração com seu software de rastreamento de bugs. Se você usa o Bugzilla , você pode configurá-lo de forma que se o seu comentário começar com "Bug XXXX", seu comentário SVN será adicionado automaticamente como um comentário para o bug fornecido, incluindo um link para a interface da web do SVN para essa revisão.

Aprenda sobre as convenções e ferramentas de ramificação e fusão do SVN.

A melhor maneira de trabalhar com outros membros da equipe é dividir o trabalho em recursos / correções de desenvolvimento completos e, em seguida, trabalhar em alterações individuais, cada um em um branch. Em seguida, mescle as alterações de volta para a ramificação / tronco da linha principal quando concluído / pronto / aprovado para serem mescladas.

Desta forma, os indivíduos podem trabalhar para um objetivo comum (no mesmo ramo ou ramos separados) sem colidir com outras mudanças.

Sua milhagem pode variar, e isso pode ser um exagero para apenas duas ou mais pessoas.

Fica muito mais fácil se você estiver usando boas ferramentas que se integram bem com o SVN. Isso torna mais fácil ver o que foi alterado e, em seguida, comprometer todas ou parte de suas alterações e atualizar frequentemente sua cópia de trabalho para a versão mais recente no SVN.

Eu recomendo Tortoise SVN (se você estiver usando Windows) e Visual SVN (se você estiver usando VS).

Veja também se você pode configurá-lo para receber e-mail ou notificação semelhante sempre que uma alteração for confirmada (geralmente incluindo a mensagem de confirmação e uma lista de arquivos alterados). Serviços como o CVSDude oferecem isso. Acho útil saber que uma atualização foi feita e então ter alguma idéia do que está contido nessa atualização antes de atualizar minha cópia de trabalho.

Além de políticas de ramificação et al. (onde um tamanho definitivamente não serve para todos), você deve ter bons commits:

• O commit deve estar relacionado a um único peça de trabalho, se possível; uma correção de bug, um novo recurso - deve haver alguma 'lógica' para as mudanças que você cometeu
• O commit deve ter um comentário descritivo que o ajudará a localizá-lo navegando no histórico do repositório. A maioria das pessoas sugere escrever uma única frase no início que descreva todo o commit e um relato mais detalhado abaixo
• Se possível, você deve vincular o commit ao seu sistema de rastreamento de bugs, se possível. Trac, Redmine et al. permitem criar links de bugs para commits e vice-versa, o que é muito útil.

A regra de ouro para o controle de origem: check-in antecipado, check-in frequente

Para dicas de como organizar seu repositório:

• Como você organiza seu repositório de controle de versão?
• Livro SVN Capítulo 5. Administração do Repositório
• Layout do repositório

Consulte sua equipe sobre as mudanças, ou pelo menos observe o diff com muito cuidado, antes de consertar qualquer conflito de mesclagem. Peça a eles que revisem o código mesclado para garantir que suas adições não tenham sido perdidas na mesclagem.

Uma coisa que eu vi que reduz os commits quebrados é ter bons scripts de pré-commit. Por exemplo, você pode executar qualquer teste de unidade antes que a alteração seja confirmada. Isso fará com que os commits sejam um pouco lentos, mas você economiza tempo evitando pisar no pé de alguém e ter que se desculpar. Claro que isso se torna muito mais difícil de gerenciar quando você tem uma grande equipe de desenvolvimento e commits muito frequentes.

Um dos exemplos de integração com bug-tracker e aplicação de políticas de commits poderia ser os scripts de gancho svn pre / post-commit do Trac , que podem recusar commit se a mensagem de commit não referenciar qualquer ticket no bug-tracker e adicionar comentários aos existentes tickets com base no conteúdo da mensagem (isto é, a mensagem de confirmação pode conter algo como "Correções # 1, # 2 e # 8", onde # 1, # 2, # 8 são os números dos tickets).

Prática recomendada para usar SVN :

1. Quando você veio pela primeira vez ao escritório e abriu seu projeto Eclipse , a primeira etapa a ser realizada é atualizar seu projeto.

2. Depois de fazer a atualização, comece seu trabalho. Ao terminar a codificação, verifique se o seu aplicativo está funcionando corretamente, sem nenhuma exceção. Depois de ter certeza de que seu código está funcionando bem, é hora de confirmá-lo.

Nota: Enquanto confirma o código, não faça commit diretamente. Faça uma sincronização com o servidor e verifique o que precisa ser confirmado. Nota: Não comprometa a pasta inteira uma vez. Porque você pode ter feito algumas alterações no arquivo de acordo com sua necessidade ou pode ter excluído alguns arquivos do sistema local. Mas as configurações são diferentes no servidor. Portanto, verifique os arquivos individualmente e confirme o código.

3. Não submeta / atualize arquivos de conflito diretamente.

4. Quando substituir e atualizar?

   Quando você tem quase certeza de que não precisa de nenhuma das alterações locais e deseja atualizar a cópia do servidor completamente. Observe que, uma vez que você substitua e atualize, não obterá nenhuma das alterações locais.

   Nota: Não mantenha o projeto sem atualizar por mais de um dia. Também não guarde o código sem se comprometer por muitos dias.

5. Comunique quem está trabalhando no mesmo componente e discuta quais mudanças eles fizeram todos os dias.

6. Não confirme as propriedades e o arquivo de configuração, a menos que haja algum motivo. Porque as configurações serão diferentes em um servidor e na nuvem.

7. Não envie pastas de destino para o SVN, apenas o código-fonte e as pastas de recursos devem ser mantidas em um repositório SVN.

8. Quando você perdeu seu código, não entre em pânico! Você pode recuperar a cópia anterior do histórico do SVN.

9. Não faça checkout do projeto em vários locais do disco. Faça o checkout em um local e trabalhe com ele.

O SVN por si só é um bom começo e alguns dos outros pôsteres ofereceram ótimas sugestões sobre as melhores práticas.

A única coisa que gostaria de acrescentar é que você deve conectar o SVN com CruiseControl ou TeamCity para conduzir um processo de integração contínua. Isso enviará e-mails de construção e permitirá que todos saibam quando alguém violou a construção.

Será muito revelador no início quem está seguindo seu processo e quem não está. Pode causar algum atrito, mas sua equipe ficará melhor no longo prazo.

• Comentário preciso para cada commit

• Não quebre a construção (linha principal)!

• Confirme assim que uma unidade lógica mudar

• Evite usar o Subversion como ferramenta de backup

• Um pouco de ramificação / mesclagem possível

.

Mais detalhes podem ser encontrados nas melhores práticas de SVN .

Faça trabalho DEV em ramos

1. Compromissos frequentes para o seu ramo
2. Commits discretos / modulares para o seu ramo ( veja aqui )
3. Atualizar / mesclar do tronco com freqüência. Não sente em seu galho sem se basear

Tronco comunitário

1. Deve sempre construir / funcionar
2. Um problema por confirmação ( novamente, veja aqui ) Principalmente para que você ou outros possam restaurar um de cada vez
3. Não misture mudanças de refatoração / espaço em branco com mudanças lógicas. Seus colegas de equipe terão dificuldade em extrair o que você realmente fez de um commit

Lembre-se de que quanto mais incremental, modular, discreto e sucinto você fizer seus commits, mais fácil será para você (ou provavelmente outros):

• Desfazer mudanças incrementalmente
• Perceba visualmente o que você realmente fez sem peneirar toneladas de espaço em branco e mudanças de nomes de variáveis.
• As mensagens de confirmação significam mais quando a proporção do trabalho realizado para o comprimento da mensagem é menor.

Use isso para o modelo de comentários:

[tarefa / história xxx] [menor / maior] [comentário] [comentário de acompanhamento] [URL para bug]