Eu trabalho em um departamento onde ninguém nunca usou o controle de origem antes, inclusive eu.

Eu estou tentando empurrar o conceito. Passei um pouco pesquisando o SVN. Eu aprendi alguns conceitos básicos. Eu posso criar / atualizar / checkout / confirmar com a linha de comando e do Tortoise. Estou começando a aprender a marcar e ramificar, mas ainda confuso sobre conflitos entre galhos e tronco etc. Ainda estou aprendendo, mas não tenho uma pessoa física que possa me mostrar qualquer coisa. É tudo de livros / tutoriais e tentativa e erro.

Pelo que li online, parece que gité a melhor coisa a saber, mas também é mais complicado. Eu não quero me sobrecarregar. Devo continuar a dominar o svn antes de passar para o git ou seria mais sábio pular para o git agora?

Existem prós e contras de ambas as abordagens?

Não

O Git é tão radicalmente diferente do SVN que não o ajudará. Se você estiver procurando por comandos "update" e "commit" e se perguntando por que tudo é diferente.

Comece com Git de baixo para cima e vá de lá.

Contrastar um sistema centralizado de versão padrão padrão de atualização / confirmação com o Git é como comparar um barramento com o transporte em massa. Um ônibus o levará (e a todos os demais) do ponto A ao ponto B usando exatamente a mesma rota. O transporte de massa leva você do ponto A ao ponto B usando qualquer rota que você desejar.

O próprio distribuído tem desvantagens das quais você deve estar ciente. É preciso mais trabalho para manter todos na mesma página. Ele oferece um enorme aumento de flexibilidade.

Hash de revisão vs. Números

Alguém mencionou o Git usando hashes SHA1 enquanto Hg usa números.

Primeiro, você raramente (se alguma vez) precisa lidar diretamente com os hashes nos commits / pull diários. Você precisa puxar o log e puxar hashes se estiver fazendo diffs ou alguns dos itens de rebasing mais complicados.

Com o Git, todos têm os mesmos hashes. Repositórios diferentes não têm números de confirmação diferentes e todos estão na mesma página. Com Hg, isso é menos. Na prática, se você precisar acessar os hashes de confirmação e trabalhar com eles (para comparar ou percorrer a linha do tempo do código), é mais fácil sincronizar com outras pessoas quando você tiver hashes em vez de números.

Não, por favor, nem se incomode.

Sério, comece com um DVCS. O fato de o SVN ser popular não o torna padrão. Linus Torvalds diria que isso pode apodrecer seu cérebro .

Leia este ótimo artigo / introdução de Joel Spolsky chamado Reeducação do Subversion .

Você também pode estar interessado em ler esta outra pergunta: Sou um nerd do Subversion, por que devo considerar ou não o Mercurial, o Git ou qualquer outro DVCS?

Escolhendo entre DVCSs

Pessoalmente, uso tanto o mercurial quanto o git, e acho que é importante conhecer os dois. Uma leitura recomendada sobre isso é Git vs. Mercurial: relaxe (veja o exemplo do git-addremove). Duas citações desse artigo que eu acho resumem.

Em relação ao git:

A filosofia de design do Git é inconfundivelmente a do Unix: diferentemente do Subversion, CVS ou Mercurial, o git não é um binário monolítico, mas uma infinidade de ferramentas individuais, que variam de comandos de porcelana de alto nível, como git-pull, git-merge e git-checkout para comandos de “encanamento” de baixo nível, como git-apply, git-hash-object e git-merge-file. Portanto, como o MacGyver, você pode fazer praticamente qualquer coisa que precisar com o Git - isso inclui mecanismos totalmente incríveis do Wiki, rastreadores de problemas, sistemas de arquivos, ferramentas sysadmin - tudo sem conserto de fusíveis.

Em relação ao mercurial:

Os desenvolvedores que gostam de manter seu sistema limpo provavelmente apreciarão o fato de que o hg instala um binário em contraste com os 144 que compõem o git, e os desenvolvedores que pensam que a capacidade do git de editar seus commits anteriores é idiota, desnecessário e perigoso. simplicidade que a hg fornece ao omitir esse recurso específico.

Muitos projetos podem ser encontrados no github e o git é mais poderoso, mas também pode ser um pouco intimidador para os novatos, especialmente os usuários do Windows. Há também bitbucket (o equivalente do github para mercurial).

Minha recomendação: comece com mercurial e, assim que se sentir confortável, pegue o git; não é sobre as ferramentas, é sobre as pessoas com quem você trabalha .

O que considero o uso real e prático do subversion não é para trabalhar com outras pessoas, mas talvez para implementar um atualizador para seus aplicativos de produção, eis o porquê:

• Atualmente, o svn está quase instalado na maioria dos provedores de hospedagem
• Possui um bom suporte ao subprojeto (endereçável no git e hg agora, no entanto). svn upe seu projeto e suas dependências são atualizados.

Citando Thorbjørn sobre esse outro segmento :

DVCSes são para Subversion, o que Bittorrent é para ftp

Edit : Se existe um VCS que você deve conhecer antes do Git, esse pode ser o Mercurial (interface CLI muito mais amigável e boa para se apresentar aos conceitos distribuídos). Este conselho se aplica especialmente àqueles provenientes do Subversion, pois a CLI também é semelhante em algum grau. O Controle de Versão Distribuído pode ser mais fácil de aprender do que o Controle de Versão Centralizado, pois você se preocupa com a instância do repositório e não com as partes do cliente e do servidor separadamente .

Você deve aprender o que pretende usar. O Git é popular, assim como o Mercurial também teve alguma popularidade. Git / Mercurial são sistemas de controle de fonte distribuídos.

A coisa mais importante ao introduzir um novo conceito para uma equipe (e é lamentável que o controle de versão seja considerado um novo tópico para muitas equipes), ajuda a delinear suas metas e critérios de avaliação. Você não precisa ser formal, mas faça as seguintes perguntas:

• Qual é o objetivo do controle de versão em nossa equipe. Sim, todos os sistemas de controle de versão que valem qualquer coisa permitirão que você volte ao histórico e veja o que mudou em qualquer arquivo. No entanto, você vai usá-lo para basear novos lançamentos? (acene com a cabeça, você quer isso). Esta é a declaração de visão de 2-3 linhas para o que você deseja realizar.
• Sua equipe está acostumada a ter seu próprio ambiente de trabalho local apenas para mesclar cuidadosamente as coisas mais tarde? Nesse caso, a rota DVCS pode fazer mais sentido.
• Por outro lado, sua equipe está acostumada a trabalhar em uma unidade compartilhada e tudo está em constante integração? Nesse caso, o VCS mais tradicional pode fazer mais sentido.

Ao avaliar suas alternativas, você deve considerar as coisas importantes que todos os VCS precisam fazer:

• Código de linha de base (ramificações, rótulos etc.). Basicamente, como você obtém o código fonte exato usado em uma versão do seu projeto.
• Receba as alterações locais no servidor central. É necessário que haja uma cópia autorizada do código - se você usa DVCS ou VC padrão. Cada ferramenta trata esse processo de maneira diferente.
• Obtenha alterações no servidor central em sua cópia local.
• Como lidar com mudanças experimentais. Os VCS permitem que você seja mais ousado com as alterações propostas sem quebrar o código-fonte principal do projeto. Os sistemas DVCS e VCS padrão abordam isso de maneira muito diferente - um deles funcionará melhor para sua equipe.
• Como você instala e configura os servidores?
• Você precisa de autenticação? Em caso afirmativo, como você garante que apenas as pessoas com permissão para fazer alterações possam realmente?

No final, faça uma avaliação rápida para determinar se os sistemas VC ou DVCS padrão serão melhores para sua equipe. Você terá que escolher a ferramenta que fornece a menor quantidade de dor ou ela provavelmente não será adotada. Depois disso, avalie suas alternativas que melhor atendem às suas necessidades.

No final, aprenda o que você pretende usar.

Eu acho que muitas pessoas acham o git mais complicado que o svn porque é diferente. Depois de usar o subversion (ou CVS, etc.) por um tempo, pode ser difícil alternar mentalmente os modos para um modelo DVCS. Com base nisso, eu diria que pode ser necessário pesquisar VCS tradicionais como subversão em conjunto com a pesquisa de um DVCS como git.

Embora o git seja o meu VCS preferido, eu diria que provavelmente é melhor aprender também a subversão. Por um lado, ainda existem muitos repositórios de subversão e cvs com os quais você talvez precise interagir um dia, e também terá uma melhor compreensão das vantagens e desvantagens precisas do DVCS sobre o VCS tradicional.

Seria contraproducente aprender svn e depois git

Aqui estão algumas razões:

• Gits radicalmente diferentes do svn. Git é distrubted e svn é cliente / servidor.
• Diferentes significados estão associados às mesmas palavras. Por exemplo, 'git checkout ...' tem um significado diferente de 'svn checkout ...'
• Ramificar é diferente. O Git tem esse conceito de ramificações 'topic', que são ramificações locais baratas e as quais o svn não suporta.
• O Git tem um lugar extra, chamado índice, que fica entre a árvore de trabalho e seu repositório. SVN não tem índice. Usando git, suas alterações passam da sua árvore de trabalho para o índice e para o repositório.

Meu conselho é apenas aprender git.

Existem algumas coisas amplamente iguais no GIT e SVN e outras não.

Criar / atualizar / checkout / confirmar

De maneira geral, você deve buscá-lo facilmente.

como marcar e ramificar, mas ainda assim confuso sobre conflitos entre ramos e tronco, etc.

Diferente entre os dois.

Não estou dizendo que você deve ou não mudar agora (acho que essa é a sua decisão), só queria apontar isso como algo a ser levado em consideração. Se você tem certeza de que deseja experimentar o Git, pode optar por mudar agora para se salvar aprendendo algo no SVN que é diferente no Git.

Uau; 12 respostas e todo mundo ainda está implorando a pergunta ...

Não, o Subversion não é um pré-requisito para o Git.

Não existe um mapeamento limpo entre o Subversion e o Git - se você planeja aprender os dois, precisará sofrer com o fato de que eles usam os mesmos termos para ações diferentes. (E termos diferentes para as mesmas ações.)

• svn commité uma coisa diferente de git commit.
• ramos no svn e git são muito diferentes
• um repositório svn é mais como um git remote (mas não realmente)
• um repositório git é mais como uma cópia de trabalho svn (mas não realmente)

Essas são duas ferramentas divididas por um idioma comum.

Sua pergunta e a maioria das outras respostas pressupõem que o git é algum tipo de svn ++; Um "svn melhor". Não é. Os dois são ferramentas diferentes que funcionam no mesmo espaço, como um carro e uma motocicleta.

Sugiro que você escolha um, domine e comece a usá-lo em sua equipe. Aprender o controle de versão será difícil para as pessoas que não o usaram antes. Seu VCS será uma parte importante da sua infraestrutura, e aprender a confiar nela envolve a construção de novos hábitos de trabalho. Isso demora um pouco.

(De qualquer forma, verifique se seus administradores de sistema fazem backup do repositório principal - perder seu controle de origem seria catastrófico.)

Provavelmente não - existem diferenças suficientes entre servidor e distribuição que você provavelmente só confundiria mais.

Desde o início, siga as boas práticas com o DVCS de sua escolha, como se fosse do zero, e você provavelmente ficará muito mais feliz.

Vá para o Mercurial (se você não quiser ficar impressionado).

O Git é apenas marginalmente mais complicado que o Subversion, porque há uma distinção no Git entre confirmar e enviar para o repositório central.

Vale a pena aprender Git enquanto você tem a chance de ter sua mente destruída pelo Subversion.

Eu não acho que é necessário entender o Subversion para entender o Git.

A maior diferença com o Git e o Mercurial do Subversion, pelo menos para mim, é que você tem um repositório local com o qual trabalha, faz check-in e check-out até o código estar funcionando, check-out no repositório central, corrige quaisquer conflitos e verifique novamente e envie para o servidor.

Eu realmente gosto do git no ambiente Unix (Linux, MacOS X). No Windows, é um pouco hacky. Eu consideraria Mercurial se eu tivesse o Windows na equação.

Você gostou das suas aulas de história, tente SCCS, RCS, CVS, Subversion e use algo útil como Git ou Mercurial.

Git e Mercurial são equipotentes, o grande bônus do Git é o github . Mas se você não deseja terceirizar seu controle de versão, o github não está mais na equação.

Os sistemas de controle de versão compartilham algo em comum com as linguagens de programação, pois a primeira que você aprende levará mais tempo. Depois disso, escolher um novo é apenas uma questão de aprender como os principais conceitos são expressos pelo novo sistema.

Você pode aprender Git agora e investir tempo aprendendo Suvbersion mais tarde, se precisar.

Não. Faça o download do Git, crie uma conta no github e mexa por alguns dias criando repositórios, etc. O Git é bastante trivial para se atualizar. Aprenda 5 ou 6 comandos bash e você pode executar todas as tarefas essenciais. Geralmente, prefiro a "prova de idiota" de uma GUI, mas o Git Bash é o mais fácil possível. Além disso, o Git Gui é bastante decente se você preferir essa rota. Realmente não vejo o benefício que você veria ao aprender SVN. Passei um tempo atrás, onde estava avaliando alguns sistemas diferentes de controle de versão para um novo projeto de código aberto. Eu experimentei SVN, Bazaar, Git e alguns outros e aprendi o básico de cada um. YMMV, mas Git foi de longe o mais fácil. Não há nada errado em aprender SVN também, mas isso realmente não ajudará você a aprender Git.