A principal diferença é que (como já foi dito em outras respostas) o CVS é um sistema de controle de versão centralizado (antigo), enquanto o Git é distribuído.
Mas mesmo se você usar o controle de versão para desenvolvedor único, em uma única máquina (conta única), existem algumas diferenças entre o Git e o CVS:
Configurando o Repositório . O Git armazena o repositório no .gitdiretório no diretório superior do seu projeto; O CVS exige a configuração do CVSROOT, um local central para armazenar informações de controle de versão para diferentes projetos (módulos). A conseqüência desse design para o usuário é que importar fontes existentes para o controle de versão é tão simples quanto "git init && git add. && git commit" no Git, enquanto é mais complicado no CVS.
Operações atômicas . Como o CVS no início era um conjunto de scripts em torno do sistema de controle de versão RCS por arquivo, as confirmações (e outras operações) não são atômicas no CVS; se uma operação no repositório for interrompida no meio, o repositório poderá ser deixado em um estado inconsistente. No Git, todas as operações são atômicas: ou são bem-sucedidas como um todo ou fracassam sem nenhuma alteração.
Conjuntos de alterações . As alterações no CVS são por arquivo, enquanto as alterações (confirmações) no Git sempre se referem a todo o projeto. Esta é uma mudança de paradigma muito importante . Uma das conseqüências disso é que no Git é muito fácil reverter (criar uma mudança que desfaz) ou desfazer a mudança inteira ; Outra conseqüência é que no CVS é fácil fazer check-out parcial, enquanto atualmente é quase impossível no Git. O fato de as alterações serem por arquivo, agrupadas, levou à invenção do formato GNU Changelog para mensagens de confirmação no CVS; Os usuários do Git usam (e algumas ferramentas do Git esperam) convenções diferentes, com uma única linha descrevendo (resumindo) as alterações, seguida pela linha vazia, seguida por uma descrição mais detalhada das alterações.
Revisões de nomes / números de versão . Há outro problema relacionado ao fato de que, no CVS, as alterações são por arquivos: os números de versão (como você pode ver algumas vezes na expansão de palavras-chave , veja abaixo), como 1,4, refletem quantas vezes um arquivo foi alterado. No Git, cada versão de um projeto como um todo (cada confirmação) tem seu nome exclusivo fornecido pelo ID do SHA-1; geralmente os primeiros 7 a 8 caracteres são suficientes para identificar uma confirmação (você não pode usar um esquema de numeração simples para versões no sistema de controle de versão distribuído - que requer autoridade de numeração central). No CVS, para ter o número da versão ou o nome simbólico referente ao estado do projeto como um todo, você usa tags ; o mesmo se aplica ao Git se você quiser usar nomes como 'v1.5.6-rc2' para alguma versão de um projeto ... mas as tags no Git são muito mais fáceis de usar.
Ramificação fácil . Ramos na CVS são, na minha opinião, excessivamente complicados e difíceis de lidar. Você precisa marcar as ramificações para ter um nome para uma ramificação inteira do repositório (e até isso pode falhar em alguns casos, se bem me lembro, devido ao tratamento por arquivo). Acrescente a isso o fato de que o CVS não possui rastreamento de mesclagem , portanto, é necessário lembrar ou marcar manualmente mesclagens e pontos de ramificação e fornecer manualmente as informações corretas para "cvs update -j" mesclar ramificações, e isso facilita a ramificação ser desnecessário, difícil de usar. No Git, criar e mesclar ramificações é muito fácil; O Git se lembra de todas as informações necessárias (por isso, mesclar um ramo é tão fácil quanto "git merge branchname ") ... era necessário, porque o desenvolvimento distribuído naturalmente leva a vários ramos.
Isso significa que você é capaz de usar ramificações de tópicos , ou seja, desenvolver um recurso separado em várias etapas em um ramo separado.
Renomeie (e copie) o rastreamento . As renomeações de arquivos não são suportadas no CVS e a renomeação manual pode quebrar o histórico em dois ou levar ao histórico inválido, onde você não pode recuperar corretamente o estado de um projeto antes de renomear. O Git usa a detecção heurística de renomeação, com base na similaridade de conteúdo e nome do arquivo (esta solução funciona bem na prática). Você também pode solicitar a detecção de cópia de arquivos. Isso significa que:
- ao examinar a confirmação especificada, você obteria informações de que algum arquivo foi renomeado,
- mesclar corretamente leva em consideração os renomeados (por exemplo, se o arquivo foi renomeado apenas em uma ramificação)
- "git blame", o (melhor) equivalente a "cvs annotate", uma ferramenta para mostrar o histórico em linha do conteúdo de um arquivo, pode seguir o movimento do código também entre renomeações
Arquivos binários . O CVS possui apenas um suporte muito limitado a arquivos binários (por exemplo, imagens), exigindo que os usuários marquem arquivos binários explicitamente ao adicionar (ou posteriormente usando "cvs admin" ou via wrappers para fazer isso automaticamente com base no nome do arquivo), para evitar erros de exibição. arquivo binário via conversão de fim de linha e expansão de palavras-chave. O Git detecta automaticamente o arquivo binário com base no conteúdo da mesma maneira que o CNU diff e outras ferramentas; você pode substituir essa detecção usando o mecanismo gitattributes. Além disso, os arquivos binários são seguros contra manipulação irrecuperável graças ao padrão em 'safecrlf' (e ao fato de que você precisa solicitar a conversão de fim de linha, embora isso possa estar ativado por padrão, dependendo da distribuição), e a palavra-chave (limitada) a expansão é uma estrita opção de inclusão no Git.
Expansão de palavras-chave . O Git oferece um conjunto muito, muito limitado de palavras-chave em comparação com o CVS (por padrão). Isso se deve a dois fatos: as alterações no Git são por repositório e não por arquivo, e o Git evita a modificação de arquivos que não foram alterados ao alternar para outra ramificação ou retroceder para outro ponto do histórico. Se você deseja incorporar o número de revisão usando o Git, faça isso usando seu sistema de construção, por exemplo, seguindo o exemplo do script GIT-VERSION-GEN nas fontes do kernel do Linux e nas fontes do Git.
Alterações confirmadas . Como no VCS distribuído, como o ato de publicar Git, é separado da criação de uma confirmação, é possível alterar (editar, reescrever) parte não publicada do histórico sem incomodar outros usuários. Em particular, se você perceber erro de digitação (ou outro erro) na mensagem de confirmação ou um bug na confirmação, você pode simplesmente usar "git commit --amend". Isso não é possível (pelo menos não sem invasão pesada) no CVS.
Mais ferramentas . O Git oferece muito mais ferramentas que o CVS. Um dos mais importantes é o " git bisect ", que pode ser usado para encontrar uma confirmação (revisão) que introduziu um bug; se seus commits são pequenos e independentes, deve ser bastante fácil descobrir onde está o erro.
Se você trabalha em colaboração com pelo menos outro desenvolvedor, também encontrará as seguintes diferenças entre o Git e o CVS:
Confirmar antes da mesclagem O Git usa confirmação antes da mesclagem em vez de, como o CVS, mesclar antes da confirmação (ou atualizar-depois-confirmar ). Se enquanto você estava editando arquivos, se preparando para criar uma nova confirmação (nova revisão), alguém criou uma nova confirmação na mesma ramificação e agora está no repositório, o CVS o força a atualizar primeiro seu diretório de trabalho e resolver conflitos antes de permitir a confirmação. Este não é o caso do Git. Você primeiro confirma, salvando seu estado no controle de versão e depois mescla outras alterações do desenvolvedor. Você também pode solicitar ao outro desenvolvedor que faça a mesclagem e resolva conflitos.
Se você preferir ter um histórico linear e evitar mesclagens, sempre poderá usar o fluxo de trabalho de confirmação de mesclagem e confirmação via "git rebase" (e "git pull --rebase"), que é semelhante ao CVS em que você reproduz suas alterações no topo do estado atualizado. Mas você sempre se compromete primeiro.
Não há necessidade de repositório central Com o Git, não há necessidade de ter um único local central onde você confirma suas alterações. Cada desenvolvedor pode ter seu próprio repositório (ou repositórios melhores: privado no qual ele / ela desenvolve e público nu onde publica a parte que está pronta), e eles podem obter / buscar uns dos outros repositórios, em moda simétrica. Por outro lado, é comum que projetos maiores tenham um repositório central socialmente definido / nomeado, do qual todos se retirem (recebam alterações).
Finalmente, o Git oferece muito mais possibilidades quando é necessária a colaboração com um grande número de desenvolvedores. Abaixo, existem diferenças entre o CVS no Git para diferentes estágios de interesse e posição em um projeto (sob controle de versão usando CVS ou Git):
espreitador . Se você estiver interessado apenas em obter as alterações mais recentes de um projeto ( sem propagação de suas alterações ) ou em fazer desenvolvimento privado (sem contribuir com os projetos originais); ou você usa projetos estrangeiros como base do seu próprio projeto (as alterações são locais e não faz sentido publicá-las).
O Git suporta aqui o acesso somente leitura não autenticado e anônimo via git://protocolo eficiente personalizado , ou se você estiver atrás do bloqueio de firewall DEFAULT_GIT_PORT(9418), poderá usar HTTP simples.
Para a solução mais comum do CVS (como eu a entendo), o acesso somente leitura é a conta de convidado do protocolo 'pserver' CVS_AUTH_PORT(2401), geralmente chamado de "anônimo" e com senha vazia. As credenciais são armazenadas por padrão no $HOME/.cvspassarquivo, portanto, você deve fornecer apenas uma vez; ainda assim, isso é um pouco de barreira (você precisa saber o nome da conta de convidado ou prestar atenção às mensagens do servidor CVS) e aborrecimento.
desenvolvedor de franjas (colaborador em folha) . Uma maneira de propagar suas alterações no OSS é enviar patches por email . Essa é a solução mais comum se você é (mais ou menos) desenvolvedor acidental, enviando uma única alteração ou uma única correção de bug. Entre. o envio de patches pode ser feito por meio de um painel de revisão (sistema de revisão de patches) ou meios semelhantes, não apenas por e-mail.
O Git oferece aqui ferramentas que ajudam nesse mecanismo de propagação (publicação), tanto para remetente (cliente) quanto para mantenedor (servidor). Para as pessoas que desejam enviar suas alterações por e-mail, existe a ferramenta " git rebase " (ou "git pull --rebase") para reproduzir suas próprias alterações na versão atual do upstream, para que suas alterações estejam no topo da versão atual (são novas) ) e " git format-patch " para criar email com mensagem de confirmação (e autoria), altere na forma de formato diff unificado (estendido) (mais diffstat para facilitar a revisão). O mantenedor pode transformar esse email diretamente em confirmação, preservando todas as informações (incluindo a mensagem de confirmação) usando " git am ".
O CVS não oferece essas ferramentas: você pode usar "cvs diff" / "cvs rdiff" para gerar alterações e usar o patch GNU para aplicar alterações, mas, tanto quanto eu sei, não há como automatizar a aplicação da mensagem de confirmação. O CVS foi criado para ser usado na moda do cliente <-> servidor ...
tenente . Se você é mantenedor de parte separada de um projeto (subsistema), ou se o desenvolvimento do seu projeto segue o fluxo de trabalho "rede de confiança" usado no desenvolvimento do kernel Linux ... ou apenas se você possui seu próprio repositório público e as alterações que você Se você deseja publicar são muito grandes para enviar por e-mail como uma série de patches , você pode enviar uma solicitação pull ao mantenedor (principal) do projeto.
Esta é uma solução específica para sistemas de controle de versão distribuídos ; portanto, é claro que o CVS não suporta esse tipo de colaboração. Existe até uma ferramenta chamada "git request-pull" que ajuda a preparar o email a ser enviado ao mantenedor com a solicitação de retirada do seu repositório. Graças ao "git bundle", você pode usar esse mecanismo mesmo sem ter repositório público, enviando um pacote de alterações por email ou sneakernet. Alguns sites de hospedagem do Git, como o GitHub, têm suporte para notificar que alguém está trabalhando (publicou algum trabalho) em seu projeto (desde que ele use o mesmo site de hospedagem do Git), e para gerenciar um tipo de solicitação pull.
desenvolvedor principal , ou seja, alguém que publica diretamente suas alterações (no repositório principal / canônico). Essa categoria é mais ampla para sistemas de controle de versão distribuídos, pois ter vários desenvolvedores com acesso de gravação ao repositório central não é apenas o fluxo de trabalho possível (você pode ter um único mantenedor que envia alterações para o repositório canônico, um conjunto de tenentes / mantenedores de subsistemas dos quais ele / ela pulls e uma ampla gama de desenvolvedores que enviam correções por correio para a lista de discussão do mantenedor / projeto ou para um dos tenentes / subdominadores).
Com o Git, você tem a opção de usar o protocolo SSH ( git encapsulado no SSH) para publicar alterações, com ferramentas como "git shell" (para ajudar na segurança, limitar o acesso às contas do shell) ou Gitosis (para gerenciar o acesso sem a necessidade de contas shell separadas) ) e HTTPS com WebDAV, com autenticação HTTP comum.
Com o CVS, é possível escolher entre o protocolo pserver personalizado não criptografado (texto sem formatação) ou usar o shell remoto (onde você realmente deve usar o SSH ) para publicar suas alterações, o que para o sistema de controle de versão centralizado significa confirmar suas alterações (criar confirmações). Bem, você também pode encapsular o protocolo 'pserver' usando SSH, e existem outras ferramentas para automatizar isso ... mas eu não acho que isso seja tão fácil quanto, por exemplo, Gitosis.
Em geral, os sistemas de controle de versão distribuídos, como o Git, oferecem uma seleção muito mais ampla de possíveis fluxos de trabalho. Com sistemas centralizados de controle de versão, como o CVS, é necessário distinguir entre pessoas com acesso de confirmação ao repositório e aquelas sem ... e o CVS não oferece nenhuma ferramenta para ajudar na aceitação de contribuições (via patches) de pessoas sem confirmar acesso.