Por que o Git é melhor que o Subversion?

08-06-2019
|

Pergunta

eu tenho usado Subversão por alguns anos e depois de usar FonteSafe, eu simplesmente amo o Subversion.Combinado com TortoiseSVN, não consigo imaginar como poderia ser melhor.

No entanto, há um número crescente de desenvolvedores alegando que o Subversion tem problemas e que deveríamos migrar para a nova geração de sistemas de controle de versão distribuídos, como Git.

Como o Git melhora o Subversion?

Solução

Git não é melhor que o Subversion.Mas também não é pior.É diferente.

A principal diferença é que ele é descentralizado.Imagine que você é um desenvolvedor em trânsito, desenvolve em seu laptop e deseja ter controle de origem para poder voltar 3 horas.

Com o Subversion, você tem um problema:O Repositório SVN pode estar em um local que você não consegue alcançar (na sua empresa, e você não tem internet no momento), você não pode se comprometer.Se você quiser fazer uma cópia do seu código, você deve literalmente copiá-lo/colá-lo.

Com o Git, você não tem esse problema.Sua cópia local é um repositório e você pode se comprometer com ela e obter todos os benefícios do controle de origem.Ao recuperar a conectividade com o repositório principal, você pode confirmar com ele.

Isso parece bom à primeira vista, mas lembre-se da complexidade adicional dessa abordagem.

Git parece ser a coisa "nova, brilhante e legal".Não é de forma alguma ruim (afinal, há uma razão pela qual Linus o escreveu para o desenvolvimento do Kernel Linux), mas sinto que muitas pessoas embarcam no trem do "Controle de código-fonte distribuído" só porque é novo e foi escrito por Linus Torvalds, sem realmente saber por que/se é melhor.

O Subversion tem problemas, mas também o Git, Mercurial, CVS, TFS ou qualquer outro.

Editar: Portanto, esta resposta já tem um ano e ainda gera muitos votos positivos, então pensei em adicionar mais algumas explicações.No último ano desde que escrevi isto, o Git ganhou muito impulso e apoio, principalmente desde que sites como o GitHub realmente decolaram.Estou usando Git e Subversion hoje em dia e gostaria de compartilhar alguns insights pessoais.

Em primeiro lugar, o Git pode ser muito confuso no início quando se trabalha de forma descentralizada.O que é um controle remoto?e Como configurar corretamente o repositório inicial?são duas questões que surgem no início, especialmente em comparação com o simples "svnadmin create" do SVN, o "git init" do Git pode usar os parâmetros --bare e --shared que parece ser a maneira "correta" de configurar um sistema centralizado repositório.Existem razões para isso, mas acrescenta complexidade.A documentação do comando "checkout" é muito confusa para as pessoas que mudam - a maneira "correta" parece ser "git clone", enquanto "git checkout" parece mudar de ramificação.

Git REALMENTE brilha quando você está descentralizado.Tenho um servidor em casa e um laptop na estrada, e o SVN simplesmente não funciona bem aqui.Com o SVN, não posso ter controle de origem local se não estiver conectado ao repositório (sim, conheço o SVK ou maneiras de copiar o repositório).Com o Git, esse é o modo padrão de qualquer maneira.Porém, é um comando extra (git commit confirma localmente, enquanto git push origin master envia o branch master para o controle remoto chamado "origin").

Como dito acima:Git adiciona complexidade.Dois modos de criação de repositórios, checkout vs.clonar, confirmar vs.empurrar...Você precisa saber quais comandos funcionam localmente e quais funcionam com "o servidor" (presumo que a maioria das pessoas ainda goste de um "repositório mestre" central).

Além disso, as ferramentas ainda são insuficientes, pelo menos no Windows.Sim, existe um complemento do Visual Studio, mas ainda uso o git bash com o msysgit.

SVN tem a vantagem de ser MUITO mais simples de aprender:Aí está o seu repositório, todas as alterações feitas em relação a ele, se você souber como criar, confirmar e finalizar a compra e estiver pronto para começar e puder coletar coisas como ramificação, atualização, etc.mais tarde.

O Git tem a vantagem de ser MUITO mais adequado se alguns desenvolvedores nem sempre estiverem conectados ao repositório mestre.Além disso, é muito mais rápido que o SVN.E pelo que ouvi, ramificar e mesclar o suporte é muito melhor (o que é de se esperar, pois esses são os principais motivos pelos quais foi escrito).

Isso também explica por que ele ganha tanto buzz na Internet, já que o Git é perfeitamente adequado para projetos Open Source:Basta bifurcá-lo, confirmar suas alterações em seu próprio Fork e, em seguida, pedir ao mantenedor do projeto original para extrair suas alterações.Com o Git, isso simplesmente funciona.Sério, experimente no Github, é mágico.

O que também vejo são pontes Git-SVN:O repositório central é um repositório Subversion, mas os desenvolvedores trabalham localmente com o Git e a ponte envia suas alterações para o SVN.

Mas mesmo com esta longa adição, ainda mantenho minha mensagem central:Git não é melhor ou pior, é apenas diferente.Se você precisa de "Controle de fonte off-line" e deseja gastar algum tempo extra aprendendo, é fantástico.Mas se você tem um controle de origem estritamente centralizado e/ou está lutando para introduzir o controle de origem porque seus colegas de trabalho não estão interessados, então a simplicidade e as excelentes ferramentas (pelo menos no Windows) do SVN brilham.

Outras dicas

Com o Git, você pode fazer praticamente qualquer coisa offline, porque cada um tem seu próprio repositório.

Fazer ramificações e mesclar entre ramificações é muito fácil.

Mesmo que você não tenha direitos de commit para um projeto, você ainda pode ter seu próprio repositório online e publicar "solicitações push" para seus patches.Todos que gostam dos seus patches podem incluí-los em seus projetos, incluindo os mantenedores oficiais.

É trivial bifurcar um projeto, modificá-lo e ainda continuar mesclando as correções de bugs do branch HEAD.

Git funciona para desenvolvedores de kernel Linux.Isso significa que é muito rápido (tem que ser) e pode ser dimensionado para milhares de colaboradores.O Git também usa menos espaço (até 30 vezes menos espaço para o repositório Mozilla).

Git é muito flexível, muito TIMTOWTDI (existe mais de uma maneira de fazer isso).Você pode usar qualquer fluxo de trabalho que desejar e o Git irá suportá-lo.

Finalmente, há GitHub, um ótimo site para hospedar seus repositórios Git.

Desvantagens do Git:

é muito mais difícil de aprender porque o Git tem mais conceitos e mais comandos.
revisões não têm números de versão como no subversion
muitos comandos do Git são enigmáticos e as mensagens de erro são muito hostis ao usuário
falta uma boa GUI (como o ótimo TortoiseSVN)

Outras respostas fizeram um bom trabalho ao explicar os principais recursos do Git (que são ótimos).Mas também há tantos pequeno maneiras pelas quais o Git se comporta melhor e ajuda a manter minha vida mais sã.Aqui estão algumas das pequenas coisas:

Git tem um comando 'limpo'.O SVN precisa desesperadamente desse comando, considerando a frequência com que ele despeja arquivos extras em seu disco.
Git tem o comando 'bisect'.É legal.
O SVN cria diretórios .svn em cada pasta (o Git cria apenas um diretório .git).Cada script que você escreve e cada grep que você faz precisarão ser escritos para ignorar esses diretórios .svn.Você também precisa de um comando inteiro ("svn export") apenas para obter uma cópia sã de seus arquivos.
No SVN, cada arquivo e pasta pode vir de uma revisão ou ramificação diferente.A princípio, parece bom ter essa liberdade.Mas o que isso realmente significa é que há um milhão de maneiras diferentes de seu checkout local ser completamente bagunçado.(por exemplo, se "svn switch" falhar no meio ou se você digitar um comando errado).E a pior parte é:se você alguma vez entrar em uma situação em que alguns de seus arquivos vêm de um lugar e alguns deles de outro, o "svn status" lhe dirá que tudo está normal.Você precisará fazer "svn info" em cada arquivo/diretório para descobrir como as coisas são estranhas.Se o "git status" lhe disser que as coisas estão normais, então você pode confiar que as coisas realmente estão normais.
Você deve informar o SVN sempre que mover ou excluir algo.Git simplesmente descobrirá.
Ignorar a semântica é mais fácil no Git.Se você ignorar um padrão (como *.pyc), ele será ignorado por todos subdiretórios.(Mas se você realmente quiser ignorar algo em apenas um diretório, você pode).Com o SVN, parece que não há uma maneira fácil de ignorar um padrão em todos os subdiretórios.
Outro item envolvendo ignorar arquivos.O Git torna possível ignorar configurações "privadas" (usando o arquivo .git/info/exclude), o que não afetará mais ninguém.

"Por que o Git é melhor que o X"descreve os vários prós e contras do Git em comparação com outros SCMs.

Brevemente:

Faixas Git conteúdo em vez de arquivos
Os galhos são leves e mesclar é fácil, e quero dizer Muito fácil.
É distribuído, basicamente todo repositório é um branch.É muito mais fácil desenvolver de forma simultânea e colaborativa do que com o Subversion, na minha opinião.Também faz desligada desenvolvimento possível.
Isto não impõe nenhum fluxo de trabalho, como visto em o site vinculado acima, há muitos fluxos de trabalho possíveis com o Git.Um fluxo de trabalho no estilo Subversion é facilmente imitado.
Os repositórios Git são muito menor em tamanho de arquivo do que os repositórios do Subversion.Existe apenas um diretório ".git", em oposição a dezenas de repositórios ".svn" (observe o Subversion 1.7 e superior agora usa um único diretório como Git.)
O encenação area é incrível, ela permite que você veja as alterações que você irá confirmar, confirmar alterações parciais e fazer várias outras coisas.
Esconder é inestimável quando você faz um desenvolvimento "caótico" ou simplesmente deseja consertar um bug enquanto ainda está trabalhando em outra coisa (em um branch diferente).
Você pode reescrever a história, o que é ótimo para preparar conjuntos de patches e corrigir seus erros (antes você publica os commits)
… e um muito mais.

Existem algumas desvantagens:

Ainda não existem muitas GUIs boas para isso.É novo e o Subversion já existe há muito mais tempo, então isso é natural, pois existem algumas interfaces em desenvolvimento.Alguns bons incluem TartarugaGit e GitHub para Mac.
~~Checkouts/clones parciais de repositórios não são possíveis no momento (li que está em desenvolvimento).No entanto, há suporte para submódulos.~~ Git 1.7+ suporta checkouts esparsos.
Pode ser mais difícil de aprender, embora eu não tenha achado que fosse esse o caso (há cerca de um ano).O Git melhorou recentemente sua interface e é bastante amigável.

No uso mais simplista, Subversion e Git são praticamente iguais.Não há muita diferença entre:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Onde o Git realmente brilha é na ramificação e no trabalho com outras pessoas.

Conversa técnica do Google:Linus Torvalds no git

http://www.youtube.com/watch?v=4XpnKHJAok8

A página de comparação do Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion

Bem, está distribuído.Os benchmarks indicam que é consideravelmente mais rápido (dada a sua natureza distribuída, operações como diffs e logs são todas locais, então é claro que é incrivelmente mais rápido neste caso) e as pastas de trabalho são menores (o que ainda me surpreende).

Quando você está trabalhando no subversion, ou em qualquer outro sistema de controle de revisão cliente/servidor, você essencialmente cria cópias de trabalho em sua máquina conferindo revisões.Isso representa um instantâneo da aparência do repositório.Você atualiza sua cópia de trabalho por meio de atualizações e atualiza o repositório por meio de commits.

Com um controle de versão distribuído, você não tem um instantâneo, mas sim toda a base de código.Quer fazer uma comparação com uma versão de 3 meses?Não tem problema, a versão de 3 meses ainda está no seu computador.Isso não significa apenas que as coisas são muito mais rápidas, mas se você estiver desconectado do servidor central, ainda poderá realizar muitas das operações com as quais está acostumado.Em outras palavras, você não tem apenas um instantâneo de uma determinada revisão, mas de toda a base de código.

Você pensaria que o Git ocuparia muito espaço no seu disco rígido, mas de alguns benchmarks que vi, na verdade ele ocupa menos.Não me pergunte como.Quero dizer, foi construído por Linus, ele sabe uma coisa ou duas sobre sistemas de arquivos, eu acho.

Os principais pontos que gosto no DVCS são estes:

Você pode cometer coisas quebradas.Não importa porque outras pessoas não os verão até que você publique.O tempo de publicação é diferente do tempo de confirmação.
Por causa disso você pode comprometer com mais frequência.
Você pode mesclar funcionalidades completas.Esta funcionalidade terá seu próprio branch.Todos os commits deste branch estarão relacionados a esta funcionalidade.Você pode fazer isso com um CVCS, mas com DVCS é o padrão.
Você pode pesquisar seu histórico (descobrir quando uma função foi alterada)
Você pode desfazer um pull se alguém bagunçar o repositório principal, você não precisa corrigir os erros.Basta limpar a mesclagem.
Quando você precisar de um controle de origem em qualquer diretório, faça:git iniciar.e você pode confirmar, desfazer alterações, etc ...
É rápido (mesmo no Windows)

A principal razão para um projeto relativamente grande é a melhoria da comunicação criada pelo ponto 3.Outros são ótimos bônus.

O engraçado é:Eu hospedo projetos no Subversion Repos, mas os acesso por meio do comando Git Clone.

Por favor leia Desenvolva com Git em um projeto do Google Code

Embora o Código do Google fale nativamente a subversão, você pode usar o GIT facilmente durante o desenvolvimento.A busca de "Git SVN" sugere que essa prática é generalizada e também o incentivamos a experimentar.

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

eu posso trabalhar distribuído em várias máquinas, cometendo e puxando de e para elas
eu tenho um central backup/public repositório svn para outros verificarem
E eles são livres para usar o Git por conta própria

Todas as respostas aqui são as esperadas, centradas no programador. No entanto, o que acontece se sua empresa usar controle de revisão fora do código-fonte?Existem muitos documentos que não são código-fonte que se beneficiam do controle de versão e devem ficar próximos ao código e não em outro CMS.A maioria dos programadores não trabalha isoladamente – trabalhamos para empresas como parte de uma equipe.

Com isso em mente, compare a facilidade de uso, tanto nas ferramentas do cliente quanto no treinamento, entre o Subversion e o git.Não consigo ver um cenário em que qualquer sistema de controle de revisão distribuído será mais fácil de usar ou explicar para um não programador.Eu adoraria ser provado que estou errado, porque então seria capaz de avaliar o git e realmente ter esperança de que ele fosse aceito por pessoas que precisam de controle de versão e que não são programadores.

Mesmo assim, se a administração me perguntasse por que deveríamos passar de um sistema de controle de revisão centralizado para um sistema de controle de revisão distribuído, seria difícil dar uma resposta honesta, porque não precisamos disso.

Isenção de responsabilidade:Eu me interessei pelo Subversion desde o início (por volta da versão 0.29), então obviamente sou tendencioso, mas as empresas para as quais trabalhei desde então estão se beneficiando do meu entusiasmo porque encorajei e apoiei seu uso.Suspeito que seja assim que acontece com a maioria das empresas de software.Com tantos programadores aderindo ao movimento git, eu me pergunto quantas empresas perderão os benefícios de usar o controle de versão fora do código-fonte?Mesmo que você tenha sistemas separados para equipes diferentes, estará perdendo alguns benefícios, como a integração (unificada) do rastreamento de problemas, ao mesmo tempo que aumenta os requisitos de manutenção, hardware e treinamento.

O Subversion ainda é um sistema de controle de versão muito mais utilizado, o que significa que possui melhor suporte a ferramentas.Você encontrará plug-ins SVN maduros para quase todos Ambiente de desenvolvimento integrado, e existem boas extensões de explorador disponíveis (como TurtoiseSVN).Fora isso, terei que concordar com Michael:O Git não é melhor nem pior que o Subversion, é diferente.

Uma das coisas que me irrita no SubVersion é que ele coloca sua própria pasta em cada diretório de um projeto, enquanto o git coloca apenas uma no diretório raiz.Não é que grande coisa, mas pequenas coisas como essa se somam.

Claro, o SubVersion tem o Tortoise, o que [geralmente] é muito bom.

Blog WANdisco de David Richards sobre Subversion / GIT

O surgimento do GIT trouxe consigo uma raça de fundamentalistas do DVCS – os ‘Gitterons’ – que pensam que qualquer coisa que não seja o GIT é uma porcaria.Os Gitterons parecem pensar que a engenharia de software acontece em sua própria ilha e muitas vezes esquecem que a maioria das organizações não emprega exclusivamente engenheiros de software seniores.Tudo bem, mas não é como o resto do mercado pensa, e estou feliz em provar isso:O GIT, à última vista, tinha menos de três por cento do mercado, enquanto o Subversion tem cerca de cinco milhões de usuários e cerca de metade do mercado geral.

O problema que vimos foi que os Gitterons estavam disparando tiros (baratos) contra o Subversion.Tweets como “O Subversion é tão [lento/péssimo/restritivo/não cheira bem/me olha de um jeito engraçado] e agora eu tenho GIT e [tudo funciona na minha vida/minha esposa engravidou/eu consegui uma namorada depois 30 anos de tentativas/Ganhei seis vezes na mesa de blackjack].Você entendeu.

O Git também torna a ramificação e a fusão muito fáceis.O Subversion 1.5 acabou de adicionar o rastreamento de mesclagem, mas o Git ainda é melhor.Com o Git a ramificação é muito rápida e barata.Isso torna mais viável a criação de uma ramificação para cada novo recurso.Ah, e os repositórios Git são muito eficientes com espaço de armazenamento em comparação com o Subversion.

É tudo uma questão de facilidade de uso/etapas necessárias para fazer algo.

Se estou desenvolvendo um único projeto no meu PC/laptop, o git é melhor, porque é muito mais fácil de configurar e usar.Você não precisa de um servidor e não precisa ficar digitando URLs do repositório ao fazer mesclagens.

Se fossem apenas 2 pessoas, eu diria que o git também é mais fácil, porque vocês podem simplesmente empurrar e puxar um do outro.

Depois que você superar isso, eu optaria pelo subversão, porque nesse ponto você precisará configurar um servidor ou local 'dedicado'.

Você pode fazer isso tão bem com o git quanto com o SVN, mas os benefícios do git são superados pela necessidade de executar etapas adicionais para sincronizar com um servidor central.No SVN você apenas confirma.No git você tem que git commit e depois git push.A etapa adicional fica irritante simplesmente porque você acaba fazendo muito isso.

O SVN também tem o benefício de melhores ferramentas GUI, no entanto, o ecossistema git parece estar se atualizando rapidamente, então eu não me preocuparia com isso a longo prazo.

Fácil tem uma página legal comparando o uso real de Git e SVN o que lhe dará uma ideia do que o Git pode fazer (ou fazer com mais facilidade) em comparação com o SVN.(Tecnicamente, isso é baseado no Easy Git, que é um wrapper leve sobre o Git.)

Git e DVCS em geral são ótimos para desenvolvedores que fazem muita codificação independentemente um do outro porque cada um tem seu próprio branch.Porém, se você precisar de uma alteração de outra pessoa, ela deverá se comprometer com seu repositório local e, em seguida, deverá enviar esse conjunto de alterações para você ou você deverá retirá-lo dela.

Meu próprio raciocínio também me faz pensar que o DVCS torna as coisas mais difíceis para o controle de qualidade e o gerenciamento de versões se você fizer coisas como versões centralizadas.Alguém tem que ser responsável por fazer esse push/pull do repositório de todos os outros, resolver quaisquer conflitos que teriam sido resolvidos no momento do commit inicial antes, depois fazer a compilação e, em seguida, fazer com que todos os outros desenvolvedores sincronizem novamente seus repositórios.

Tudo isto pode ser resolvido com processos humanos, é claro;O DVCS acabou de quebrar algo que foi corrigido pelo controle de versão centralizado para fornecer algumas novas conveniências.

Eu gosto do Git porque ele realmente ajuda a comunicação de desenvolvedor para desenvolvedor em uma equipe de médio a grande porte.Como um sistema de controle de versão distribuído, por meio de seu sistema push/pull, ajuda os desenvolvedores a criar um ecossistema de código-fonte que ajuda a gerenciar um grande grupo de desenvolvedores trabalhando em um único projeto.

Por exemplo, digamos que você confia em 5 desenvolvedores e extrai apenas códigos de seus repositórios.Cada um desses desenvolvedores tem sua própria rede confiável de onde extraem códigos.Assim, o desenvolvimento é baseado na confiança dos desenvolvedores, onde a responsabilidade do código é compartilhada entre a comunidade de desenvolvimento.

É claro que existem outros benefícios mencionados em outras respostas aqui.

Algumas respostas aludiram a isso, mas quero deixar explícitos dois pontos:

1) A capacidade de fazer commits seletivos (por exemplo, git add --patch).Se o seu diretório de trabalho contém diversas alterações que não fazem parte da mesma alteração lógica, o Git torna muito fácil fazer um commit que inclua apenas uma parte das alterações.Com o Subversion, é difícil.

2) A capacidade de se comprometer sem tornar a mudança pública.No Subversion, qualquer commit é imediatamente público e, portanto, irrevogável.Isso limita muito a capacidade do desenvolvedor de "comprometer-se antecipadamente, comprometer-se com frequência".

Git é mais do que apenas um VCS;também é uma ferramenta para desenvolver patches.O Subversion é apenas um VCS.

Eu acho que o Subversion está bem ..até você começar a mesclar..ou fazendo algo complicado..ou fazer qualquer coisa que o Subversion considere complicado (como fazer consultas para descobrir quais ramificações mexeram com um arquivo específico, onde uma alteração na verdade de onde vem, detectando copiar e colar, etc.)...

Discordo da resposta vencedora, dizendo que benefício principal do GIT é um trabalho offline - certamente é útil, mas é mais como um extra para o meu caso de uso.O SVK também pode funcionar offline, mas não tenho dúvidas em qual investir meu tempo de aprendizado).

Só que é incrivelmente poderoso e rápido e, bem - depois de se acostumar com os conceitos - muito útil (sim, nesse sentido:amigo do usuário).

Para obter mais detalhes sobre uma história de fusão, consulte isto:Usando git-svn (ou similar) *apenas* para ajudar com uma mesclagem de svn?

Graças ao fato de não precisar se comunicar constantemente com um servidor central, praticamente todos os comandos são executados em menos de um segundo (obviamente, git push/pull/fetch são mais lentos simplesmente porque precisam inicializar conexões SSH).Ramificar é muito mais fácil (um comando simples para ramificar, um comando simples para mesclar)

Eu adoro poder gerenciar ramificações locais do meu código-fonte no Git sem atrapalhar o repositório central.Em muitos casos, verificarei o código do servidor Subversion e executarei um repositório Git local apenas para poder fazer isso.Também é ótimo que a inicialização de um repositório Git não polua o sistema de arquivos com um monte de pastas .svn irritantes em todos os lugares.

E no que diz respeito ao suporte de ferramentas do Windows, o TortoiseGit lida muito bem com o básico, mas ainda prefiro a linha de comando, a menos que queira ver o log.Eu realmente gosto da maneira como o Tortoise{Git|SVN} ajuda na leitura de logs de commit.

Esta é a pergunta errada a ser feita.É muito fácil focar nos defeitos do git e formular um argumento sobre por que a subversão é ostensivamente melhor, pelo menos para alguns casos de uso.O fato de o git ter sido originalmente projetado como um conjunto de construção de controle de versão de baixo nível e ter uma interface barroca orientada para o desenvolvedor Linux torna mais fácil para as guerras santas ganharem força e legitimidade percebida.Os proponentes do Git batem o tambor com milhões de vantagens de fluxo de trabalho, que os caras do svn consideram desnecessárias.Em breve todo o debate será enquadrado como centralizado versus distribuído, o que atende aos interesses da comunidade de ferramentas SVN empresariais.Estas empresas, que normalmente publicam os artigos mais convincentes sobre a superioridade do subversion nas empresas, dependem da insegurança percebida do git e da prontidão empresarial do svn para o sucesso a longo prazo dos seus produtos.

Mas aqui está o problema: Subversion é um beco sem saída arquitetônico.

Considerando que você pode pegar o git e construir um substituto centralizado do subversion com bastante facilidade, apesar de estar disponível há mais do que o dobro do tempo, o svn nunca foi capaz de fazer com que o rastreamento de mesclagem básico funcionasse tão bem quanto no git.Uma razão básica para isso é a decisão de design de tornar as ramificações iguais aos diretórios.Não sei por que eles seguiram esse caminho originalmente, isso certamente torna as verificações parciais muito simples.Infelizmente, também torna impossível rastrear o histórico adequadamente.Agora, obviamente, você deve usar convenções de layout de repositório do Subversion para separar ramificações de diretórios regulares, e o svn usa algumas heurísticas para fazer as coisas funcionarem para os casos de uso diário.Mas tudo isso é apenas encobrir uma decisão de design de baixo nível muito pobre e limitante.Ser capaz de fazer uma comparação em termos de repositório (em vez de uma comparação em termos de diretório) é uma funcionalidade básica e crítica para um sistema de controle de versão e simplifica bastante os componentes internos, tornando possível construir recursos mais inteligentes e úteis sobre ele.Você pode ver a quantidade de esforço que foi feito para estender o subversion e, ainda assim, quão distante ele está da safra atual de VCSes modernos em termos de operações fundamentais, como resolução de mesclagem.

Agora, aqui está meu conselho sincero e agnóstico para quem ainda acredita que o Subversion é bom o suficiente para o futuro próximo:

O Subversion nunca alcançará as novas gerações de VCSes que aprenderam com os erros do RCS e CVS;é uma impossibilidade técnica, a menos que eles reformulem o modelo do repositório desde o início, mas então não seria realmente svn, seria?Independentemente do quanto você acha que não conhece as capacidades de um VCS moderno, sua ignorância não o protegerá das armadilhas do Subversion, muitas das quais são situações impossíveis ou facilmente resolvidas em outros sistemas.

É extremamente raro que a inferioridade técnica de uma solução seja tão clara como é com o svn, certamente eu nunca daria tal opinião sobre win-vs-linux ou emacs-vs-vi, mas neste caso é tão claro, e o controle de origem é uma ferramenta tão fundamental no arsenal do desenvolvedor, que sinto que deve ser afirmado de forma inequívoca.Independentemente da necessidade de usar o svn por razões organizacionais, eu imploro a todos os usuários do svn que não deixem sua mente lógica construir uma falsa crença de que VCSes mais modernos são úteis apenas para grandes projetos de código aberto.Independentemente da natureza do seu trabalho de desenvolvimento, se você for um programador, será um programador mais eficaz se aprender a usar VCSes melhor projetados, sejam eles Git, Mercurial, Darcs ou muitos outros.

O Subversion é muito fácil de usar.Nunca encontrei nos últimos anos um problema ou que algo não funcionasse como esperado.Além disso, existem muitas ferramentas GUI excelentes e o suporte para integração SVN é grande.

Com o Git você obtém um VCS mais flexível.Você pode usá-lo da mesma forma que o SVN com um repositório remoto onde você confirma todas as alterações.Mas você também pode usá-lo principalmente off-line e apenas enviar as alterações de tempos em tempos para o repositório remoto.Mas o Git é mais complexo e tem uma curva de aprendizado mais acentuada.Dei comigo pela primeira vez cometendo ramificações erradas, criando ramificações indiretamente ou recebendo mensagens de erro com poucas informações sobre o erro e onde devo pesquisar no Google para obter melhores informações.Algumas coisas fáceis como a substituição de marcadores ($Id$) não funcionam, mas o GIT tem uma filtragem muito flexível e um mecanismo de gancho para mesclar scripts próprios e assim você obtém tudo o que precisa e muito mais, mas precisa de mais tempo e leitura da documentação ;)

Se você trabalha principalmente offline com seu repositório local, não terá backup se algo for perdido em sua máquina local.Com o SVN você trabalha principalmente com um repositório remoto que também é o mesmo que seu backup em outro servidor ...O Git pode funcionar da mesma forma, mas esse não era o objetivo principal do Linus ter algo como o SVN2.Ele foi projetado para desenvolvedores de kernel Linux e para as necessidades de um sistema de controle de versão distribuído.

O Git é melhor que o SVN?Os desenvolvedores que precisam apenas de algum histórico de versão e um mecanismo de backup têm uma vida boa e fácil com o SVN.Os desenvolvedores que trabalham frequentemente com filiais, testando mais versões ao mesmo tempo ou trabalhando principalmente offline podem se beneficiar dos recursos do Git.Existem alguns recursos muito úteis, como stashing, não encontrados no SVN, que podem tornar a vida mais fácil.Mas, por outro lado, nem todas as pessoas precisarão de todos os recursos.Portanto, não consigo ver a morte do SVN.

O Git precisa de uma documentação melhor e o relatório de erros deve ser mais útil.Além disso, as GUIs úteis existentes raramente são usadas.Desta vez encontrei apenas 1 GUI para Linux com suporte para a maioria dos recursos do Git (git-cola).A integração do Eclipse está funcionando, mas não foi lançada oficialmente e não existe um site oficial de atualização (apenas algum site de atualização externo com compilações periódicas do tronco http://www.jgit.org/updates) Portanto, a maneira mais preferida de usar o Git hoje em dia é a linha de comando.

Eric Sink da SourceGear escreveu uma série de artigos sobre diferenças entre sistemas de controle de versão distribuídos e não distribuídos.Ele compara os prós e os contras dos sistemas de controle de versão mais populares.Leitura muito interessante.
Os artigos podem ser encontrados em seu blog, www.ericsink.com:

Para pessoas que procuram uma boa GUI Git, Syntevo SmartGit pode ser uma boa solução.É proprietário, mas gratuito para uso não comercial, roda em Windows/Mac/Linux e até suporta SVN usando algum tipo de ponte git-svn, eu acho.

http://subversion.wandisco.com/component/content/article/1/40.html

Acho que é bastante seguro dizer que entre os desenvolvedores, o SVN vs.A discussão sobre o Git já existe há algum tempo, com cada um tendo sua própria opinião sobre o que é melhor.Isso foi levantado até mesmo nas perguntas durante nosso Webinar sobre Subversion em 2010 e além.

Hyrum Wright, nosso Diretor de Código Aberto e Presidente da Subversion Corporation fala sobre as diferenças entre o Subversion e o Git, junto com outros Sistemas Distribuídos de Controle de Versão (DVCS).

Ele também fala sobre as próximas mudanças no Subversion, como o Working Copy Next Generation (WC-NG), que ele acredita que fará com que vários usuários do Git convertam de volta para o Subversion.

Assista ao vídeo dele e deixe-nos saber o que você pensa comentando neste blog ou postando em nossos fóruns.O registro é simples e leva apenas alguns minutos!

Git no Windows é bastante bem suportado agora.

Confira GitExtensions = http://code.google.com/p/gitextensions/

e o manual para uma melhor experiência com o Windows Git.

Tenho morado na terra do Git ultimamente e gosto dele para projetos pessoais, mas ainda não seria capaz de mudar os projetos de trabalho do Subversion para ele, dada a mudança de pensamento exigida da equipe, sem nenhum benefício urgente.Além disso, o maior projecto que executamos internamente é extremamente dependente de svn: externos que, pelo que vi até agora, não funciona tão bem e perfeitamente no Git.

Primeiro, o controle de versão concorrente parece um problema fácil de resolver.Não é de todo.De qualquer forma...

SVN é bastante não intuitivo.Git é ainda pior.[especulação sarcástica] Isso pode ocorrer porque os desenvolvedores, que gostam de problemas difíceis como controle de versão simultâneo, não têm muito interesse em criar uma boa UI.[/especulação sarcástica]

Os apoiadores do SVN acham que não precisam de um sistema distribuído de controle de versão. Eu pensei isso também. Mas agora que usamos exclusivamente Git, acredito.Agora o controle de versão funciona para mim E para a equipe/projeto, em vez de apenas trabalhar para o projeto.Quando preciso de um galho, eu ramifico.Às vezes é uma ramificação que possui uma ramificação correspondente no servidor e às vezes não.Sem mencionar todas as outras vantagens que terei que estudar (graças em parte à misteriosa e absurda falta de UI que é um sistema moderno de controle de versão).

Por que acho que o Subversion é melhor que o Git (pelo menos para os projetos em que trabalho), principalmente devido à sua usabilidade e fluxo de trabalho mais simples:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow