Devo usar SVN ou Git? [fechadas]


321

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


5
Sim, o git funciona no Mac. Se você usar o macports para instalá-lo, ele instalará um front end do Mac nas interfaces de confirmação e navegação.
Seth Johnson

3
possível duplicação de stackoverflow.com/questions/871/…

3
@ Andre - porque você pode usar o MonoDevelop - mudo do Vault para o SVN para poder desenvolver o software .NET no meu Mac ou PC. Não havia nenhum cliente para o Vault, mas não havia para SVN :-)
schmoopy


4
Github / bitbucket + sourcetree = céu! # sourcetreeapp.com
thecodeassassin

Respostas:


253

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).


24
Pode também ter um olhar para Hg (Mercúrio)
Joel

24
As coisas ficaram muito melhores desde outubro de 2008. Você pode instalar o TortoiseGit, pegar a versão portátil mais recente do MSysGit e informar ao TortoiseGit onde encontrá-lo. Acabei de mudar meu grande repositório svn para o git hoje porque o fraco suporte à renomeação do svn finalmente me deixou louco o suficiente.
We Are All Monica

4
Passando 2 anos, agora temos algumas boas ferramentas para Windows. Atualmente estou usando o netbeans com o MSysGit. Eu também tive sorte com o TortoiseGit. Eu acho que é bom o suficiente para ser usado na produção. Considerando o quão difícil é gerenciar conflitos simples no subversion git é uma grande melhoria.
Keyo 27/10/10

24
Usamos o Git no Windows fortemente e já há muito tempo. Git é absolutamente fantástico no Windows.
Charlie Flowers

13
@Oli Seria bom atualizar sua resposta (especialmente sobre o cliente git do Windows) com base nos comentários aqui e na sua experiência. A resposta atual parece tendenciosa agora que 2-3 anos se passaram desde que foi escrita.
Amit

111

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á.


9
Eu, por outro lado, tive alguns problemas com o git no Windows, isso fez coisas realmente estranhas ao meu repositório. E eu estava usando a versão mais recente do cygwin (era algo como um mês atrás).
Roman Plášil

7
@ Roman: bem, a porta Cygwin é quase a mesma coisa que a porta win32 nativa. Espero que o porto Cygwin é muito menos bem-testado ...
Samb

49
"mais recursos do que você provavelmente já usam" é uma bandeira vermelha no meu livro
BT

26
@ BT "red flag" Não concordo. Costumo me encontrar desejando que houvesse uma maneira de fazer alguma coisa e, depois de um pouco de pesquisa, descubro que existem alguns comandos que eu não sabia sobre isso, exatamente isso. Também uso o GIT na minha máquina Windows e ainda não tive grandes problemas.
testing123

@ testing123 mas, em seguida, eles não são recursos "que você provavelmente [n] jamais usará" porque acabou usando-os.
mulllhausen

77

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).


10
Não discordo de você que git e svn são fundamentalmente diferentes, mas discordo de muitos de seus pontos. svn pode ter sido escrito para substituir os cvs, mas eles não estão relacionados de maneira alguma, enquanto os cvs começaram como scripts no RCS, então existe uma relação direta. Ainda assim, a pessoa que você está citando tem toda a razão, ambas gerenciam fundamentalmente revisões de arquivos, a implementação e o processo em que isso acontece (ou como acontece) são detalhes da implementação. É como a diferença entre CRC e SHA1, fundamentalmente muito diferente, mas eles fazem a mesma coisa.
Erik Funkenbusch

37

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.


6
"por favor, corrija-me se houver outro VCS que lide com mais de 500 MB de arquivos" - Perforce, é claro!
James creasy

8
Força = não livre. Além disso, o Perforce não está disponível para todas as plataformas.
precisa saber é o seguinte

4
Por que não colocar o repositório SVN DENTRO dos contêineres de TrueCrypt? Você também pode encapsular esse ssh, e configurar o servidor para armazenar esse repositório específico dentro de outro arquivo truecrypt. Isso tem a vantagem adicional de fazer check-out parcial desse repositório.
precisa saber é o seguinte

1
@Hugo, tanto quanto sei, o cliente Perforce está disponível para Windows, Unix, variantes do Linux, Mac, Amiga, BeOS, Cygwin, HPUX, IBM AS / 400, OS / 2, DEC VMS e Novell File Server. Existe alguma plataforma relevante ausente na lista?
eis

1
Sim, o OpenBSD (e eu sabia disso por experiência própria, não precisava pesquisar isso no Google). Eu acho que também não funcionará no maemo, embora eu possa estar errado (e sim, eu uso o git no maemo).
WhyNotHugo

25

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?


15
O Git é incrivelmente rápido em algumas operações, principalmente porque a operação afeta apenas seu repositório local. Um check-in Git, por exemplo, não deve ser comparado justamente a um check-in SVN, porque um check-in SVN também é um empurrão da mudança para um repositório de preparação para o restante da sua equipe. Isso requer um impacto na rede, e comparar o comprometimento da rede do Git com uma transferência de rede não parece uma comparação inadequada. Se você confirmar, e depois perder o disco rígido, com o Git, você perderá a alteração. Tudo bem se é isso que você espera, mas não é esperado em SCMs não distribuídos.
Edwin Buck

1
@EdwinBuck Não tendo o que Waqar fez em conta, em testes, mesmo com horário de rede tidos em conta git tende a ser mais rápido: git-scm.com/about/small-and-fast
Sqeaky

O ponto "Criar um repositório é uma operação trivial" é extremamente importante, especialmente no Windows: comparado ao SVN, é muito mais fácil simular rapidamente um monte de repositórios distribuídos interconectados, todos conectados a um repositório central (- nu) com o Git than é fazer o análogo ao SVN (instalar o aplicativo do servidor Windows SVN, etc.). Também (estranhamente), acho o Git mais consistente entre os sistemas operacionais: a linha de comando é muito bem projetada e, portanto, suficiente na maioria das vezes (e praticamente idêntica entre os sistemas operacionais) versus vários aplicativos nativos de cliente / servidor SVN ...
Shivan Dragon

1
O artigo wiki a que você se refere está cheio de erros. Portanto, sua resposta está errada. Votado. Há uma página de discussão no wiki que se refere ao svnvsgit.com dizendo por que a comparação está errada.
bahrep

Incrivelmente rápido? Mudei o projeto ciforth de um cvs local para o github. Este é um projeto simples, mas possui um grande arquivo de origem principal de 10.000 linhas. Se eu tentar culpar esse arquivo, o github cai dentro de um tempo limite. Principalmente se alguém não se contenta em dizer rápido, e insiste em usar esse qualificador, não é uma opinião equilibrada, o que me deixa desconfiada com tudo o que você diz. Groetjes Albert
Albert van der Horst

12

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.


11

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

3
Apenas uma observação: em julho de 2011, o Google Code oferece suporte nativo ao Git.
Jeremy Salwen 1/1

9

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.


9

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.


8

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]


1
FYI: coloque o URL entre colchetes angulares ou substitua parênteses por% 28 e% 29.
PhiLho

1
A codificação de URL funcionará para a sintaxe [] ()?
Hank Gay

16
FUD incorreto. Git é fantástico no Windows. E o SVN é muito ruim em todos os lugares.
Charlie Flowers

6
Para todos aqueles que me votaram mal, volte e olhe os comentários dos desenvolvedores de cerca de 2008: é bem claro que Linus e sua turma não se preocupavam em oferecer suporte ao Windows. Tudo bem: eu também não quero fazer isso, e meu software não é tão complexo quanto o VCS, que espera o comportamento POSIXish do sistema de arquivos. Parece injusto, no entanto, caracterizar minha afirmação como FUD, se você olhar para o contexto.
Hank Gay

2
Talvez em 2008 o git fosse ruim no Windows, mas uso o msysgit desde 2009 e funciona perfeitamente. Isso inclui o gitk, o equivalente da área de trabalho offline do GitHub.
Dan Dascalescu

8

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.


Estou otimista de que o horizonte de irrelevância será muito menor do que alguns anos.
Greg Hewgill 02/10/08

Sim, possivelmente será apenas um ano. O Git tem uma comunidade de desenvolvimento dinâmica. Mas a subversão também. Em um ano ou dois, você terá que olhar para os dois novamente para responder a essa pergunta.
Mnementh

1
Agora é um ano ou dois depois. Como está? :)
Merlyn Morgan-Graham

3
O Git não possui uma extensão do modelo SCM distribuído para as outras fases do pipeline de desenvolvimento de software. Não temos um bom modelo para sistemas de criação de versão distribuída, testes automatizados distribuídos, controle de qualidade, controle de versão etc. Estamos apenas obtendo suporte experimental para backup distribuído, e isso após décadas de pesquisa. Como tal, o Git oferece mais ao desenvolvedor e menos ao processo de desenvolvimento de software. Todas as implementações do Git acabam abençoando um repositório por ser o central, o que simplifica as habilidades mais interessantes do Git em fac-símiles dos SVN.
Edwin Buck

1
@hibbelig O Git não tem um repositório central, cada repositório é efetivamente (devido ao seu design distribuído) igual. Isso significa que você refaz seu pipeline de produção para possivelmente manipular todos os repositórios da mesma forma ou abençoa artificialmente um repositório para ter um status "artificialmente elevado" (também conhecido como repositório central ). Se você faz o primeiro, ninguém sabe muito sobre a construção de pipelines paralelos onde um release pode vir da mesa de qualquer desenvolvedor; se você fizer o último, a promessa do processamento distribuído é enganada pela convenção centralizada.
Edwin Buck

6

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

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


1
No entanto, isso está mudando rapidamente. SVN perde quota de mercado, enquanto os ganhos GIT: Por exemplo: wikivs.com/wiki/Git_vs_Subversion#Popularity ou programmers.stackexchange.com/questions/136079/...
Zelphir Kaltstahl

@Zelphir: Eu não ligaria para 7 anos rapidamente, mas sim, o GIT ganha participação de mercado e é especialmente melhor para mesclar arquivos.
Burkhard #

4

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.


8
Defina 'nativamente'. msysgit funciona muito bem
Milan Babuškov 6/10/08

4

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.


4

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?


Eu não chamaria qualquer desenvolvedor que copiasse uma pasta controlada por SVN em outro projeto para reutilizá-la e não esperava que problemas óbvios fossem "intermediários". Eu os chamaria de novatos. Sim, você está certo, isso se deve à subpasta .svn que informa ao SVN a qual repositório os arquivos pertencem. Se o usuário excluiu essa subpasta .svn, ele poderá importar a pasta para o novo projeto SVN. Eu ainda estou no SVN, mas minhas necessidades são poucas. O GIT é ótimo para projetos maiores.
precisa saber é

3
Os clientes svn mais recentes não precisam de uma .svnpasta em cada subdiretório. Isso "corrige" o erro de cópia antes que ele aconteça.
Edwin Buck

4

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ê.


3

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 ...


O suporte do Windows realmente precisa de um pouco de trabalho aqui, no entanto. Não tanto que não o tenha usado com prazer em toda a minha programação recente no Windows (da qual venho fazendo um bom bocado), ou qualquer coisa, mas ainda ...
SamB

Quase 100% do tempo com o sistema operacional, as pessoas "criaram [qualquer software] porque não gostavam de mais nada no mercado".
precisa saber é o seguinte

@ Hugo Com o código aberto, se eles gostassem de algo mais no mercado, eles contribuiriam para isso em vez de criar algo novo.
yingted 13/08/11

Esta não é uma resposta para a pergunta
Albert van der Horst

@AlbertvanderHorst Não, não, a pergunta foi respondida nos dias selvagens do oeste da SO, quando ninguém sabia melhor, e ofereceu uma alternativa. Indiscutível na minha pressa, parece que eu também escrevi errado o nome da Canonical. Que vergonha!
Omar Kooheji

3

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.


1
Sim, funciona lindamente. Eu o instalei através do MacPorts e o uso diariamente.
Greg Hewgill 02/10/08

Faz. É ótimo em qualquer sistema baseado em POSIX (Unix, Linux, Solaris, BSD, etc). Na verdade, é apenas no Windows que está o problema.
Oli

e o git-gui e o gitk provavelmente funcionam da mesma maneira no OS-X e no Linux e Windows. Ao contrário do tortoiseSVN, qual AFAIK é apenas para janelas?
David Schmitt

@ David Schmitt: bem, tortoisesvn.tigris.org chama isso de "Extensão de Shell do Windows para Subversion", então suponho que sim ;-).
SamB 30/03/10

@ Robert: como foi sua experiência com o git no OS X?
David Schmitt


2

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.


1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.