Devo usar SVN ou Git? [fechadas]

Estou iniciando um novo projeto distribuído. Devo usar SVN ou Git, e por quê?

O SVN é um repositório e muitos clientes. Git é um repositório com vários repositórios de clientes, cada um com um usuário. É descentralizado a um ponto em que as pessoas podem rastrear suas próprias edições localmente sem precisar enviar as coisas para um servidor externo.

O SVN foi projetado para ser mais central, onde o Git se baseia em cada usuário que possui seu próprio repositório Git e esses repositórios enviam as alterações novamente para o central. Por esse motivo, o Git oferece aos indivíduos um melhor controle de versão local.

Enquanto isso, você pode escolher entre TortoiseGit , GitExtensions (e se você hospedar seu repositório git "central" no github, seu próprio cliente - GitHub for Windows ).

Se você deseja sair do SVN, pode avaliar um pouco o Bazaar . É um dos sistemas de controle de versão da próxima geração que possuem esse elemento distribuído. Não depende do POSIX, como o git, por isso há versões nativas do Windows e tem algumas marcas poderosas de código-fonte aberto.

Mas você pode nem precisar desse tipo de recurso ainda. Veja os recursos, vantagens e desvantagens dos VCS distribuídos . Se você precisar de mais do que ofertas SVN, considere um. Caso contrário, convém manter a superior integração da área de trabalho do SVN (atualmente).

Eu nunca entendi esse conceito de "o git não é bom no Windows"; Eu desenvolvo exclusivamente no Windows e nunca tive problemas com o git.

Eu recomendaria definitivamente o git sobre a subversão; é simplesmente muito mais versátil e permite "desenvolvimento offline" de uma maneira que a subversão nunca poderia. Está disponível em quase todas as plataformas imagináveis ​​e possui mais recursos do que você provavelmente jamais utilizará.

Aqui está uma cópia de uma resposta que fiz de uma pergunta duplicada desde então excluída sobre Git vs. SVN (setembro de 2009).

Melhor? Além do link usual WhyGitIsBetterThanX , eles são diferentes:

um é um VCS Central baseado em cópia barata para ramificações e tags; o outro (Git) é um VCS distribuído com base em um gráfico de revisões. Veja também Principais conceitos do VCS .

Essa primeira parte gerou comentários mal informados, fingindo que o objetivo fundamental dos dois programas (SVN e Git) é o mesmo, mas que eles foram implementados de maneira bastante diferente.
Para esclarecer a diferença fundamental entre SVN e Git , deixe-me reformular:

• O SVN é a terceira implementação de um controle de revisão : RCS, CVS e, finalmente, SVN gerenciam diretórios de dados com versão. O SVN oferece recursos de VCS (rotulagem e mesclagem), mas sua tag é apenas uma cópia do diretório (como uma ramificação, exceto que você não deve "tocar em nada em um diretório de tags), e sua mesclagem ainda é complicada, atualmente baseada em meta -dados adicionados para lembrar o que já foi mesclado.

• O Git é um gerenciamento de conteúdo de arquivo (uma ferramenta feita para mesclar arquivos), evoluiu para um verdadeiro Sistema de Controle de Versão , baseado em um DAG ( Gráfico Diretivo Acíclico ) de confirmações, onde as ramificações fazem parte do histórico de dados (e não os dados em si) ) e onde as tags são verdadeiros metadados.

Dizer que eles não são "fundamentalmente" diferentes porque você pode conseguir a mesma coisa, resolver o mesmo problema, é ... completamente falso em muitos níveis.

• se você tiver muitas mesclagens complexas, fazê-las com o SVN será mais longo e mais sujeito a erros. se você precisar criar muitas ramificações, precisará gerenciá-las e mesclá-las, novamente com muito mais facilidade com o Git do que com o SVN, especialmente se houver um grande número de arquivos envolvidos (a velocidade se tornará importante)
• se você tiver mesclagens parciais para um trabalho em andamento, aproveitará a área de teste (índice) do Git para confirmar apenas o que você precisa, esconder o restante e seguir em outra ramificação.
• se você precisar de desenvolvimento offline ... bem, com o Git, você está sempre "online", com seu próprio repositório local, seja qual for o fluxo de trabalho que você deseja seguir com outros repositórios.

Ainda assim, os comentários sobre essa resposta antiga (excluída) insistiam:

VonC: Você está confundindo diferença fundamental na implementação (as diferenças são muito fundamentais, ambos concordamos claramente com isso) com diferença de propósito.
As duas ferramentas são usadas com o mesmo objetivo: é por isso que muitas equipes que usavam o SVN anteriormente conseguiram despejá-lo com sucesso em favor do Git.
Se eles não resolvessem o mesmo problema, essa substituibilidade não existiria.

, ao qual respondi:

"substituibilidade" ... termo interessante ( usado em programação de computadores ).
Obviamente, o Git dificilmente é um subtipo de SVN.

Você pode obter os mesmos recursos técnicos (marca, ramificação, mesclagem) com ambos, mas o Git não interfere no seu caminho e permite que você se concentre no conteúdo dos arquivos , sem pensar na ferramenta em si.

Você certamente não pode (sempre) simplesmente substituir o SVN pelo Git "sem alterar nenhuma das propriedades desejáveis ​​desse programa (correção, tarefa executada, ...)" (que é uma referência à definição de substituibilidade acima mencionada ):

• Uma é uma ferramenta de revisão estendida, a outra é um verdadeiro sistema de controle de versão.
• Um é adequado para projetos monolíticos de pequeno a médio porte com fluxo de trabalho de mesclagem simples e (não muito) versões paralelas. O SVN é suficiente para esse fim, e talvez você não precise de todos os recursos do Git.
• O outro permite projetos de médio a grande porte com base em vários componentes ( um repositório por componente ), com grande número de arquivos a serem mesclados entre várias ramificações em um fluxo de trabalho de mesclagem complexo, versões paralelas em ramificações, mesclagens de retrofit e assim por diante. Você poderia fazer isso com o SVN, mas está muito melhor com o Git.
  O SVN simplesmente não pode gerenciar nenhum projeto de qualquer tamanho com nenhum fluxo de trabalho de mesclagem. Git pode.

Novamente, sua natureza é fundamentalmente diferente (o que leva a uma implementação diferente, mas esse não é o ponto).
Um vê o controle de revisão como diretórios e arquivos, o outro apenas vê o conteúdo do arquivo (tanto que os diretórios vazios nem se registram no Git!).

O objetivo final geral pode ser o mesmo, mas você não pode usá-los da mesma maneira, nem a mesma classe de problemas (no escopo ou na complexidade).

2 principais vantagens do SVN que raramente são citadas:

1. Suporte a arquivos grandes. Além do código, eu uso o SVN para gerenciar meu diretório pessoal. O SVN é o único VCS (distribuído ou não) que não engasga com meus arquivos TrueCrypt (corrija-me se houver outro VCS que lide com mais de 500 MB de arquivos). Isso ocorre porque as comparações de diferenças são transmitidas (este é um ponto muito essencial). O Rsync é inaceitável porque não é bidirecional.

2. Repositório parcial (subdir) check-out / check-in. Mercurial e bzr não suportam isso, e o suporte ao git é limitado. Isso é ruim em um ambiente de equipe, mas inestimável se eu quiser verificar algo em outro computador do meu diretório doméstico.

Apenas minhas experiências.

Depois de fazer mais pesquisas e analisar este link: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Alguns extratos abaixo):

• É incrivelmente rápido. Nenhum outro SCM que eu usei foi capaz de acompanhá-lo, e eu usei muito, incluindo Subversion, Perforce, darcs, BitKeeper, ClearCase e CVS.
• É totalmente distribuído. O proprietário do repositório não pode ditar como eu trabalho. Posso criar ramificações e confirmar alterações enquanto estiver desconectado no meu laptop, e depois sincronizá-lo com qualquer número de outros repositórios.
• A sincronização pode ocorrer em várias mídias. Um canal SSH, via HTTP via WebDAV, por FTP ou enviando e-mails contendo patches a serem aplicados pelo destinatário da mensagem. Um repositório central não é necessário, mas pode ser usado.
• Os ramos são ainda mais baratos do que no Subversion. Criar uma ramificação é tão simples quanto gravar um arquivo de 41 bytes no disco. Excluir uma ramificação é tão simples quanto excluir esse arquivo.
• Diferentemente, os ramos do Subversion carregam sua história completa. sem ter que executar uma cópia estranha e percorrer a cópia. Ao usar o Subversion, sempre achei estranho olhar para o histórico de um arquivo no ramo que ocorreu antes da criação do ramo. from #git: spearce: Eu não entendo uma coisa sobre SVN na página. Eu criei um ramo no SVN e navegando no histórico, mostrei um arquivo inteiro no histórico
• A mesclagem de ramificações é mais simples e mais automática no Git. No Subversion, você precisa se lembrar de qual foi a última revisão da qual você mesclou para poder gerar o comando de mesclagem correto. O Git faz isso automaticamente, e sempre faz o que é certo. O que significa que há menos chances de cometer um erro ao mesclar dois ramos.
• Mesclagens de ramificação são registradas como parte do histórico adequado do repositório. Se eu mesclar dois galhos juntos, ou se um galho voltar ao tronco de onde veio, essa operação de mesclagem será registrada como parte do histórico do repostório como tendo sido executada por mim e quando. É difícil contestar quem executou a mesclagem quando está bem ali no log.
• Criar um repositório é uma operação trivial: mkdir foo; cd foo; git init É isso. O que significa que eu crio um repositório Git para tudo hoje em dia. Eu costumo usar um repositório por classe. A maioria desses repositórios tem menos de 1 MB em disco, pois apenas armazena notas de aula, tarefas de casa e minhas respostas do LaTeX.
• Os formatos de arquivo interno do repositório são incrivelmente simples. Isso significa que o reparo é muito fácil, mas ainda melhor, porque é tão simples que é muito difícil ser corrompido. Eu não acho que alguém já tenha um repositório Git corrompido. Eu vi o Subversion com o fsfs corrompido. E eu vi o Berkley DB se corrompendo muitas vezes para confiar no meu código no backend bdb do Subversion.
• O formato de arquivo do Git é muito bom na compactação de dados, apesar de ser um formato muito simples. O repositório CVS do projeto Mozilla é de cerca de 3 GB; são cerca de 12 GB no formato fsfs do Subversion. No Git, ele tem cerca de 300 MB.

Depois de ler tudo isso, estou convencido de que o Git é o caminho a seguir (embora exista um pouco de curva de aprendizado). Também usei o Git e o SVN nas plataformas Windows.

Eu adoraria ouvir o que os outros têm a dizer depois de ler o acima?

Eu configuraria um repositório Subversion. Fazendo dessa maneira, os desenvolvedores individuais podem escolher entre usar os clientes do Subversion ou Git (with git-svn). O uso git-svnnão oferece todos os benefícios de uma solução Git completa, mas oferece aos desenvolvedores individuais um grande controle sobre seu próprio fluxo de trabalho.

Acredito que levará um tempo relativamente curto até que o Git funcione tão bem no Windows quanto no Unix e no Mac OS X (como você pediu).

O Subversion possui excelentes ferramentas para Windows, como a integração do TortoiseSVN for Explorer e AnkhSVN for Visual Studio.

O engraçado é que eu hospedo projetos no Subversion Repos, mas os acesso através do comando Git Clone.

Leia Desenvolver com Git em um projeto de código do Google

Embora o Google Code fale nativamente o Subversion, você pode facilmente usar o Git durante o desenvolvimento. A busca por "git svn" sugere que essa prática é generalizada, e também recomendamos que você experimente.

Usar o Git em um repositório Svn me oferece benefícios:

1. Eu posso trabalhar distribuído em várias máquinas, comprometendo e puxando de e para elas
2. Eu tenho um repositório svn central backup/public para outras pessoas verificarem
3. E eles são livres para usar o Git por conta própria

Não estou realmente respondendo à sua pergunta, mas se você deseja os benefícios do Controle de Revisão Distribuído - parece que sim - e você está usando o Windows, acho que seria melhor usar o Mercurial do que o Git como Mercurial tem um suporte muito melhor ao Windows. O Mercurial também possui uma porta Mac.

Se sua equipe já está familiarizada com os softwares de controle de versão e código-fonte, como cvs ou svn, então, para um projeto simples e pequeno (como o que você alega), eu recomendaria que você ficasse no SVN. Estou realmente confortável com o svn, mas para o atual projeto de comércio eletrônico que estou realizando no django, decidi trabalhar no git (estou usando o git no modo svn, ou seja, com um repositório centralizado para o qual empurro e puxo para colaborar com pelo menos um outro desenvolvedor). O outro desenvolvedor se sente à vontade com o SVN e, embora as experiências de outros possam ser diferentes, nós dois estamos tendo um momento muito ruim em adotar o git para este pequeno projeto. (Nós dois somos usuários hardcore do Linux, se é que isso importa.)

Sua milhagem pode variar, é claro.

Definitivamente svn, como o Windows é - na melhor das hipóteses - um cidadão de segunda classe no mundo de git(consulte http://en.wikipedia.org/wiki/Git_(software)#Portability para obter mais detalhes).

UPDATE: Desculpe pelo link quebrado, mas desisti de tentar fazer com que o SO trabalhe com URIs que contêm parênteses. [link corrigido agora. -ed]

O ponto principal é que o Git é um VCS distribuído e o Subversion, centralizado. VCS distribuídos são um pouco mais difíceis de entender, mas têm muitas vantagens. Se você não precisar dessas vantagens, o Subversion pode ser a melhor escolha.

Outra questão é o suporte a ferramentas. Qual VCS é melhor suportado pelas ferramentas que você planeja usar?

EDIT: Há três anos, respondi desta maneira:

E o Git funciona no Windows no momento apenas via Cygwin ou MSYS . O Subversion suportou o Windows desde o início. Como as soluções git para Windows podem funcionar para você, pode haver problemas, pois a maioria dos desenvolvedores do Git trabalha com Linux e não tinha portabilidade em mente desde o início. No momento, eu preferiria o Subversion para desenvolvimento no Windows. Em alguns anos isso pode ser irrelevante.

Agora o mundo mudou um pouco. O Git tem uma boa implementação no Windows agora. Embora eu não tenha testado completamente no Windows (como não uso mais esse sistema), estou bastante confiante de que todos os principais VCS (SVN, Git, Mercurial, Bazaar) têm agora a implementação adequada do Windows. Essa vantagem para o SVN se foi. Os outros pontos (Centralizado vs. Distribuído e a verificação de suporte à ferramenta) permanecem válidos.

Eu optaria pelo SVN, pois ele é mais amplamente difundido e mais conhecido.

Eu acho que o Git seria melhor para o usuário Linux.

O Git ainda não é suportado nativamente no Windows. É otimizado para sistemas Posix. No entanto, a execução do Cygwin ou MinGW permite executar o Git com êxito.

Hoje em dia eu prefiro o Git ao invés do SVN, mas leva um tempo para ultrapassar o limite se você vier de CVS, SVN land.

Eu provavelmente escolheria o Git porque acho que é muito mais poderoso que o SVN. Existem serviços baratos de hospedagem de código disponíveis que funcionam muito bem para mim - você não precisa fazer backups nem fazer nenhum trabalho de manutenção - o GitHub é o candidato mais óbvio.

Dito isto, não sei nada sobre a integração do Visual Studio e os diferentes sistemas SCM. Eu imagino a integração com o SVN para notavelmente melhor.

Eu uso o SVN há muito tempo, mas sempre que usei o Git, senti que o Git é muito poderoso, leve e, embora envolva um pouco de curva de aprendizado, mas é melhor que o SVN.

O que observei é que cada projeto SVN, à medida que cresce, se torna um projeto de tamanho muito grande, a menos que seja exportado. Onde, o projeto GIT (junto com os dados Git) é muito leve.

No SVN, lidei com desenvolvedores de iniciantes a especialistas, e os iniciantes e intermediários parecem introduzir conflitos de arquivo se copiarem uma pasta de outro projeto SVN para reutilizá-lo. Considerando que, penso que no Git, você apenas copia a pasta e ela funciona, porque o Git não introduz pastas .git em todas as suas subpastas (como o SVN).

Depois de lidar muito com o SVN há muito tempo, finalmente estou pensando em mudar meus desenvolvedores e eu para o Git, pois é fácil colaborar e mesclar o trabalho, além de uma grande vantagem é que as alterações de uma cópia local podem ser comprometidas o máximo possível. desejado e, finalmente, enviado à filial no servidor de uma só vez, ao contrário do SVN (onde temos que confirmar as alterações periodicamente no repositório no servidor).

Alguém que pode me ajudar a decidir se eu devo mesmo ir com o Git?

Tudo se resume a isso:

Seu desenvolvimento será linear? Nesse caso, você deve ficar com o Subversion.

Se, por outro lado, seu desenvolvimento não for linear, o que significa que você precisará criar ramificações para diferentes alterações e, em seguida, mesclar essas alterações na linha de desenvolvimento principal (conhecida pelo Git como o ramo principal), e o Git fará MUITO mais para você.

você já experimentou Bzr ?

É muito bom, conônico (as pessoas que fazem o Ubuntu) fizeram isso porque não gostavam de mais nada no mercado ...

Posso expandir a pergunta e perguntar se o Git funciona bem no MacOS?

Responder aos comentários: Obrigado pelas notícias, eu estava ansioso para experimentá-las. Vou instalá-lo em casa no meu Mac.

Há um vídeo interessante no YouTube sobre isso. É do próprio Linus Torwalds: Goolge Tech Talk: Linus Torvalds no git

O SVN parece ser uma boa escolha no Windows, como apontado por outras pessoas.

Se algum de seu desenvolvedor quiser experimentar o GIT, ele sempre poderá usar o GIT-SVN, onde o repositório SVN é recriado em um repositório GIT. Em seguida, ele deve poder trabalhar localmente com o GIT e, em seguida, usar o SVN para publicar suas alterações no repositório principal.

Você precisa seguir um DVCS, é como um salto quântico no gerenciamento de fontes. Pessoalmente, uso o Monotone e seu tempo de desenvolvimento acelerou sem fim. Estamos usando-o para Windows, Linux e Mac e tem sido muito estável. Eu até tenho o buildbot fazendo builds noturnos do projeto em cada uma das plataformas.

O DVCS enquanto está sendo distribuído geralmente significa que você criará um servidor central apenas para as pessoas enviarem alterações de e para o local.