Melhor Hospedagem de Controle de Versão Maio de 2020

Divulgação: Seu suporte ajuda a manter o site funcionando! Ganhamos uma taxa de indicação por alguns dos serviços que recomendamos nesta página.


Contents

Encontre hospedagem com esses recursos no Controle de versão

  • Mercurial
  • SVN

Controle de versão e hospedagem

alojamento de controle de versão

Codificadores gostam de codificar.

Pode ser fácil adquirir o hábito de simplesmente abrir um editor e distribuir o máximo de código possível.

Isso é particularmente verdade se você estiver trabalhando em um projeto pessoal ou se for o único desenvolvedor.

Pode ser ainda mais tentador se você é um programador rápido ou tem um chefe que deseja soluções e correções imediatamente.

Mas se você está lançando um novo código em produção sem um sistema de controle de versão adequado, não está realmente desenvolvendo software, está fazendo o “Cowboy Coding”.

como o controle de versão funciona

Como funciona o controle de versão

O controle de versão, também chamado de controle de revisão, controle de versão ou origem, é um método para rastrear as revisões feitas em documentos, código ou outros arquivos.

Os sistemas de controle de versão (VCS) ou software de controle de versão podem ser aplicativos autônomos incorporados a aplicativos de edição de documentos (como Word ou Google Docs).

Eles também podem ser incorporados a sistemas de gerenciamento de conteúdo (como WordPress ou MediaWiki) ou a um ambiente de desenvolvimento integrado (IDE) como o Visual Studio da Microsoft.

O que o controle de versão faz?

O software de controle de versão permite que desenvolvedores, editores e outros membros da equipe visualizem versões anteriores de arquivos, além de restaurar versões anteriores.

O controle de versão mantém uma cópia principal da base de código. Muitos sistemas de controle de versão permitem que várias cópias paralelas de toda a base de código existam simultaneamente.

Cada desenvolvedor de software possui sua própria cópia da base de código: eles podem fazer revisões sem influenciar o código-fonte principal.

Essas revisões são trazidas no momento apropriado e mescladas no código-fonte principal.

Como essa fusão acontece depende do sistema de controle de versão (VCS) em uso.

razões para usar o controle de versão

Razões para usar o controle de versão

Ainda não está convencido de que você precisa de um sistema de controle de versão?

Aqui estão as razões pelas quais vale a pena usar o controle de versão:

  • Liberdade para cometer erros
  • Liberdade para tentar algo novo
  • Um histórico completo das revisões feitas em sua base de código
  • Menos perguntas não respondidas
  • Trilha de papel do que foi feito e por que
  • Backups
  • Facilitar a colaboração mais fácil entre os membros da equipe.

Liberdade de cometer erros

Você já usou o botão UNDO (CTRL-Z) enquanto trabalhava? Claro que você faz. É um dos recursos mais importantes dos computadores modernos.

O que o botão UNDO oferece é a liberdade de cometer erros. Essa é uma das vantagens que você obtém do controle de versão – na verdade, pode ser a vantagem mais importante.

Liberdade para experimentar algo novo

Com o controle de versão, você pode tentar algo – uma nova solução, um novo recurso, uma correção de bug.

Se não funcionar, você pode simplesmente reverter seu código para um ponto anterior ou descartar as revisões propostas.

Essas revisões não serão mescladas no código-fonte principal. (É como economizar pontos em um videogame.)

Isso é útil por dois motivos:

  1. Você cometerá erros inevitavelmente; assim, você também poderá corrigi-los facilmente.
  2. Depois que você sabe que tem uma maneira de reverter os erros, fica muito mais fácil se aventurar em um território desconhecido e correr riscos com novas soluções ou idéias não testadas..

Histórico completo das revisões feitas na sua base de códigos

Você já trabalhou em um projeto por um longo período e, em seguida, alguém que o utiliza diz: “O botão de saída não usou para acionar um aviso de salvamento antes de fechar o aplicativo?”

Se um sistema existir por um período de tempo suficientemente longo, é inevitável que alguns recursos sejam alterados e removidos.

Depois que você sabe que tem uma maneira de reverter os erros, fica muito mais fácil se aventurar em um território desconhecido e correr riscos com novas soluções ou idéias não testadas..

Geralmente, havia algum motivo para ter o recurso em primeiro lugar (mesmo com os recursos eventualmente removidos).

No entanto, também havia um motivo para a remoção de um determinado recurso (mesmo que alguém o tenha feito acidentalmente).

Menos perguntas não respondidas

Mais tarde, quando alguém aparecer e perguntar sobre algum recurso que costumava estar lá, você pode se lembrar muito bem do que aconteceu.

Ou, se você tiver controle de versão, poderá consultar as revisões anteriores e voltar com respostas definitivas sobre:

  • O que esse recurso costumava fazer
  • Quando foi removido
  • Por que foi removido.

Isso é particularmente útil se você precisar:

  • Reimplemente o recurso (às vezes você pode apenas reimplementar o código que foi removido!)
  • Defenda sua exclusão contínua de seus aplicativos prontos para produção.

Trilha de papel do que foi feito e por quê

Isso está intimamente relacionado ao histórico de versões, mas é mais sobre desenvolvedores e menos sobre recursos.

Sua trilha de papel não é (geralmente) literal, mas o controle de versão permite que você veja coisas como:

  • Quais revisões foram feitas
  • Quando foram feitas revisões
  • Quem fez as revisões.

Isso é útil ao tentar entender por que as coisas são do jeito que são. Você pode atribuir crédito ou culpa ou apenas descobrir quem perguntar sobre algum recurso ou implementação específica.

Backups

Geralmente, os repositórios controlados por versão são armazenados em vários locais.

Isso evita que seus projetos tenham uma única máquina como ponto único de falha catastrófico.

Facilitar uma colaboração mais fácil entre os membros da equipe

Se apenas uma pessoa estiver trabalhando em um projeto, você poderá se safar sem usar nenhum sistema de controle de versão (embora isso ainda seja uma péssima idéia).

No entanto, se várias pessoas estiverem trabalhando juntas em um projeto, o risco de as pessoas escreverem sobre as revisões umas das outras ou criarem códigos incompatíveis (também conhecidos como conflitos de mesclagem) é muito alto.

Como tal, um recurso indispensável dos sistemas de controle de versão (VCS) é a capacidade de verificar revisões mutuamente incompatíveis na base de códigos mestres para garantir que tudo funcione em conjunto.

desdobramento, desenvolvimento

Implantação e controle de versão

Como você move arquivos da máquina de desenvolvimento local para o ambiente de teste e, finalmente, os ambientes de produção?

Algumas pessoas apenas mantêm uma janela FTP aberta e soltam arquivos à medida que os alteram.

Isso não é sensato. É muito fácil deixar de fora um arquivo necessário e, se houver um problema inesperado no servidor, torna-se difícil reverter suas revisões..

Enviando revisões de uma só vez

Se você estiver usando certos tipos de controle de versão (especialmente o Git), poderá simplesmente enviar suas revisões de uma só vez para um servidor remoto. Não importa em que ambiente – desenvolvimento, teste ou produção – o servidor lida com.

Se alguma das suas revisões causar um problema em qualquer momento no futuro, você poderá reverter facilmente as revisões para que as coisas comecem a funcionar novamente.

Tipos de sistemas de controle de versão (VCS)

Existem basicamente dois tipos de sistemas de controle de versão:

  • Sistemas de controle de versão centralizados
  • Sistemas de controle de versão descentralizados.

Vamos dar uma olhada detalhada abaixo.

controle de versão centralizado

Sistemas centralizados de controle de versão

Os sistemas centralizados de controle de versão seguem um modelo cliente-servidor.

Nesses sistemas, um único conjunto de códigos-fonte mestre (“central”) fica em um servidor. Arquivos individuais que estão sendo trabalhados são verificados pelos desenvolvedores.

A cópia de trabalho é então “bloqueada”. Outros são avisados ​​de que não devem fazer revisões no arquivo ou mesmo impedidos de editar os arquivos (ou ambos).

Os desenvolvedores enviam as revisões feitas nesses arquivos de volta ao código-fonte central, que é a versão usada para implantações de código / software em ambientes de produção.

Um exemplo de fluxo de trabalho centralizado do VCS

Em um sistema centralizado de controle de versão, há um servidor (ou repositório) central que atua como a fonte da verdade.

Esse também é o conjunto de códigos que normalmente é mantido em um estado pronto para produção.

Isso significa que, a qualquer momento, o código poderá ser enviado para um ambiente de produção sem ramificações negativas.

O fluxo de trabalho

Quando você precisa trabalhar em algo, encontra os arquivos nos quais precisa trabalhar. Você então “faz check-out” desses arquivos, o que significa que:

  1. Você puxa uma cópia para a máquina local, onde pode trabalhar nela
  2. Os arquivos em si são bloqueados contra edição por outras pessoas em sua equipe

Quando você terminar de fazer as alterações, poderá enviá-las, incluindo uma nota sobre o que fez.

Ao contrário dos sistemas descentralizados nos quais você mescla suas alterações (falaremos mais sobre mesclagens daqui a pouco), você simplesmente envia suas alterações para o servidor central. Isso libera os bloqueios que você tem nesses arquivos.

controle de versão descentralizado

Sistemas de controle de versão descentralizados (ou distribuídos)

Os sistemas de controle de versão descentralizado / distribuído são aqueles em que os desenvolvedores de software envolvidos têm:

  • Uma cópia completa de toda a base de código (em oposição a uma cópia de trabalho de arquivos selecionados)
  • Um histórico de revisões feitas.

Origem da verdade, usuários e nós

Não há um usuário ou nó, que é mais importante que qualquer outro nó, embora normalmente exista um único repositório designado como origem. (Pense em um repositório como um arquivo, mas com informações históricas.)

A origem é semelhante ao código fonte “central” em um VCS centralizado.

Mudanças individuais são, quando prontas, fundidas na fonte da verdade (normalmente rotulada como a ramo mestre).

Devido ao método assíncrono e independente pelo qual o VCS descentralizado funciona, conflitos de mesclagem devem ser resolvidos pelos desenvolvedores antes que a mesclagem ocorra.

É assim que as diferenças irreconciliáveis ​​entre o trabalho de dois ou mais desenvolvedores são impedidas de quebrar a ramificação principal.

Um exemplo de fluxo de trabalho VCS descentralizado

Nesta seção, abordaremos o processo de uso de um sistema de controle de versão descentralizado.

A ramificação e fusão necessárias tornam o uso de tais sistemas um pouco mais complicado do que seus equivalentes centralizados.

Começando

Você pode começar de duas maneiras:

  • Você pode inicializar um novo repositório em sua máquina de desenvolvimento
  • Você pode clonar um repositório existente.

Independentemente da opção escolhida, você terá uma cópia completa do código fonte no seu computador.

Versões diferentes do código são chamadas ramificações, com a fonte da verdade e a versão enviada para uma produção chamada ramificação principal. Ao usar o VCS distribuído, é uma boa prática manter a filial principal em um estado pronto para implantação da produção o tempo todo.

Fazendo mudanças

Sempre que você deseja alterar um ou mais arquivos, você cria uma nova ramificação. Como o próprio nome indica, uma ramificação é uma ramificação do código principal.

O número de alterações que você inclui em uma ramificação pode variar.

Você pode fazer apenas uma pequena alteração ou manter meses de alterações em uma única ramificação.

Normalmente, você garantiria (no mínimo) que todas as alterações estejam relacionadas a um único recurso.

O processo de salvar uma alteração é chamado cometer.

Cada confirmação que você faz exige que você adicione notas sobre o que você fez – seu VCS deve observar automaticamente que você foi a pessoa que cometeu a alteração e quando.

Gerenciando confirmações

Com o tempo, você poderá ver um log de todas as confirmações feitas, quando foram feitas e por quem.

As confirmações têm o recurso de bônus que permite reverter suas alterações um pouco de cada vez.

Isso pressupõe que você tenha criado várias confirmações e não apenas uma grande confirmação no final do seu projeto..

Você pode pensar em commits como divisões de branches.

Enquanto as ramificações mantêm alterações relacionadas a um determinado recurso, as confirmações são as alterações menores que, somadas, se tornam a atualização completa do recurso.

Empurrando Ramos

As filiais também são úteis para compartilhar seu trabalho.

Por exemplo, digamos que você esteja trabalhando com vários outros e que todos estejam contribuindo para um único repositório.

Bem, se você deseja compartilhar seu trabalho (talvez deseje revisar o código que escreveu), basta pressionar o ramo em que você está trabalhando, em vez de todo o repositório.

Envio do seu trabalho

Ao ler para enviar seu trabalho, você pode iniciar o processo de mesclagem, onde alguém (normalmente não você) mescla sua ramificação de recursos na ramificação principal.

O processo geral é o seguinte:

  1. Você envia sua ramificação para o repositório central e solicita que ela seja inserida na ramificação principal
  2. Outra pessoa revisa sua ramificação e, se tudo estiver bem, eles finalizam a mesclagem.

Observe que os sistemas de controle de versão somente permitirão que o revisor seja mesclado se as alterações propostas não conflitarem com nada que já foi mesclado na ramificação principal.

Se não for esse o caso, você precisará resolver os conflitos de mesclagem e atualizar sua solicitação.

sistemas de controle de versão de comparação

Comparando e contrastando sistemas de controle de versão distribuídos (descentralizados) vs. centralizados

Quais são as principais diferenças entre um sistema de controle de versão descentralizado / distribuído e um sistema de controle de versão centralizado?

A diferença mais óbvia entre VCS centralizado e descentralizado é em termos de acesso e conveniência.

Desvantagens de um sistema centralizado

Você pode pensar em um sistema centralizado como o acesso a uma pasta compartilhada do Dropbox por meio de um navegador da web..

Por outro lado, acessar um sistema distribuído equivale a sincronizar uma pasta Dropbox da comunidade compartilhada com o seu próprio computador.

Com um sistema centralizado, antes que seus usuários possam começar a editar, eles precisam:

  • Acesse os arquivos de origem centrais
  • Faça o download da cópia de trabalho necessária
  • Confira a cópia de trabalho para que eles estejam bloqueados e não possam ser editados por outras pessoas.

Arquivos em um sistema distribuído

Com um sistema distribuído, os arquivos já estão exatamente onde você precisa deles.

Isso ocorre porque uma das primeiras etapas para configurar um sistema distribuído é clonar todos os arquivos, bem como o histórico da versão, na estação de trabalho de desenvolvimento local.

A clonagem de um repositório é análoga à cópia de um arquivo – lembre-se, no entanto, que os repositórios possuem informações históricas adicionais.

Quando você estiver pronto para começar a trabalhar, tudo o que você precisa fazer é abrir os arquivos que você “puxou” para o seu computador.

Ter todos os arquivos que você precisa localmente é uma enorme vantagem em termos de velocidade e eficiência.

O único momento em que você precisa se comunicar com o servidor é extrair um arquivo dele ou enviá-lo novamente..

Vantagens e desvantagens decisivas de um sistema distribuído

Esse método assíncrono também permite que os usuários façam várias revisões localmente antes de decidir a próxima etapa:

  • Enviando suas revisões para todos os outros que trabalham no projeto (enviando para o ramo de origem e solicitando as revisões)
  • Enviando suas revisões para selecionar os membros da equipe para revisão antes de torná-los visíveis para toda a equipe.

No entanto, uma grande desvantagem de um VCS distribuído é a quantidade de espaço que um repositório local pode exigir.

Dependendo do tamanho do seu projeto, os repositórios individuais que você clonou no computador podem acabar ocupando muito espaço.

Esse problema é amplificado se você precisar clonar vários repositórios para um único (ou até vários) projetos.

Por que essas desvantagens?

Quando você considera o grande número de arquivos de texto, arquivos de imagem, vídeos e tamanhos de registro de alterações, isso pode ser problemático, especialmente para aqueles que estão em estações de trabalho com orçamento.

Para usuários com essas limitações, um VCS centralizado pode ser uma opção melhor, pois os usuários precisam apenas baixar os arquivos de que precisam, não todo o conjunto de códigos-fonte e o histórico de revisões que os acompanha.

controle de versão de opções descentralizadas

Opções do sistema de controle de versão distribuído

Ao escolher um sistema de controle de versão (VCS), quais são as opções disponíveis para você?

Qual deles você deve escolher?

Nas seções a seguir, abordaremos vários sistemas populares de controle de versão distribuído, bem como vários sistemas populares de controle de versão centralizado.

Felizmente, isso ajuda você a escolher uma opção que atenda às suas necessidades. Caso contrário, esta lista deve ajudá-lo a iniciar rapidamente sua pesquisa pela opção que funciona!

Vamos começar com algumas das opções distribuídas mais populares disponíveis.

Bazar

Bazaar é o sistema de controle de versão patrocinado pela Canonical, escrito em Python.

Como projeto de código aberto de plataforma cruzada, os usuários do macOS, Linux e Windows podem usar este produto.

Para usuários familiarizados com o CVS (Concurrent Version System) ou o Subversion (SVN), os comandos do Bazaar parecerão similares.

O Bazaar, diferente de outros VCS distribuídos, permite usá-lo com ou sem um repositório ou servidor central onde o conjunto de códigos-fonte principal vive.

Ele também se integra bem a outros VCS – você pode confirmar alterações no SVN e ler arquivos rastreados pelo Git ou Mercurial.

Você também pode exportar o histórico do Bazaar para muitos outros sistemas.

Fóssil

O Fossil é um sistema de controle de versão distribuído em várias plataformas que também inclui recursos para:

  • Rastreamento de bugs
  • Wikis
  • Blogging.

O Fossil é fornecido com uma interface da web integrada que exibe histórico detalhado de alterações e informações de status do projeto.

O objetivo dessa interface é reduzir a complexidade inerentemente envolvido com o rastreamento do projeto e para melhorar a consciência situacional na base de código.

Semelhanças com Bazaar

Como o Bazaar, o Fossil não exige que você use um servidor central, mas, se o fizer, a colaboração entre os membros da sua equipe será mais fácil..

Fossil utiliza bancos de dados SQLite para armazenar seu conteúdo.

Git

Git é um sistema de controle de versão criado pelo “pai do Linux”, Linus Torvalds.

Embora o Git seja destacado no mundo do desenvolvimento de software, ele pode ser usado para rastrear alterações em qualquer tipo de conjunto de arquivos.

Acima de tudo, Git prioriza o desempenho.

Isso é importante quando os sistemas de controle de versão distribuído requerem:

  • O puxar inicial de todos os arquivos do projeto (não apenas os que estão sendo trabalhados)
  • Integridade de dados
  • Suporte para fluxos de trabalho não lineares.

Git em diferentes plataformas

Embora o Git seja desenvolvido usando Linux, é uma solução multiplataforma.

Normalmente, cada projeto é gerenciado em um repositório individual. (Lembre-se de que um repositório é essencialmente uma pasta, mas com um log de alterações).

Às vezes, arquivos para projetos grandes são divididos em vários repositórios.

O Git é normalmente usado em conjunto com algum tipo de serviço de hospedagem baseado na Web.

Este é o método pelo qual vários colaboradores podem compartilhar seu trabalho, bem como obter o código fonte original e as alterações feitas por seus pares..

GitHub

Um dos serviços de hospedagem baseados na Web mais comuns usados ​​para o Git é o GitHub (na verdade, o GitHub é o maior host de código-fonte do mundo).

Além de oferecer suporte a todos os recursos de controle de versão e gerenciamento de código fonte do Git, o GitHub oferece:

  • Ferramentas de controle de acesso
  • Ferramentas de rastreamento de bugs
  • Gerenciamento de solicitações de recursos
  • Ferramentas de gerenciamento de tarefas / produtividade
  • Wikis.

Você pode até gerar e hospedar páginas da web simples usando o GitHub.

Embora o GitHub ofereça repositórios públicos e privados, a utilização de um repositório privado incorre em taxas (enquanto um repositório público é gratuito).

Isso está de acordo com a dedicação do GitHub ao código-fonte aberto.

Bitbucket

Bitbucket é a contribuição da Atlassian para o mundo da hospedagem baseada na Web para usuários do Git (e Mercurial).

Além de suas contas gratuitas, o Bitbucket oferece mais planos comerciais ricos em recursos.

Para alguns usuários, o Bitbucket é uma opção melhor que o GitHub, pois o Bitbucket não muda nada se você usar um repositório privado.

As contas gratuitas recebem um número ilimitado de repositórios particulares, embora o número de colaboradores seja limitado.

Bitbucket é normalmente visto como a opção para desenvolvedores profissionais trabalhando com código fonte proprietário.

Seu uso principal é para revisão de código e código, embora o Bitbucket ofereça alguns extras, como:

  • Documentação
  • Wiki
  • Recursos estáticos do site.

GitLab

O GitLab é um gerenciador de repositórios criados pelo Git que oferece uma opção auto-hospedada ou um serviço baseado na Web. O GitLab oferece recursos e ferramentas relacionados ao Wiki, bem como funcionalidade de rastreamento de problemas.

Planos auto-hospedados e totalmente hospedados no Gitlab

O GitLab fornece quatro planos diferentes de soluções auto-hospedadas:

  • Core: para equipes pequenas ou projetos pessoais (o Core é totalmente gratuito)
  • Iniciador: para projetos pessoais ou pequenas equipes que desejam suporte profissional.
  • Premium: para equipes que precisam de alta disponibilidade, alto desempenho ou suporte 24/7.
  • Ultimate: para grandes empresas, é necessária uma funcionalidade adicional de segurança e conformidade.

Se você não estiver interessado em se hospedar, poderá optar pelo versão totalmente hospedada do Git. Para cada plano auto-hospedado, há um plano hospedado correspondente:

  • Principal → Grátis
  • Iniciante → Bronze
  • Premium → Prata
  • Ultimate → Ouro

Paridade de recursos entre planos do Gitlab

O GitLab garante a paridade de recursos entre seus planos auto-hospedados e totalmente hospedados (ou seja, os recursos oferecidos aos que estão no plano Starter são os mesmos do plano Bronze).

Precisa de um repositório privado?

Para aqueles que precisam de um repositório privado (ou vários repositórios particulares), considere fortemente o GitLab.

Nessas situações, o GitLab é mais barato que o GitHub e mais rápido que o Bitbucket (embora, obviamente, sua milhagem possa variar dependendo das variáveis ​​específicas da sua situação).

Mercurial

O Mercurial é um sistema de controle de versão distribuído entre plataformas que é:

  • Alto desempenho
  • Facilmente escalável
  • Capaz de lidar com texto simples e arquivos binários
  • Avançado em seus recursos de ramificação e fusão.

Apesar da complexidade que esses recursos podem apresentar, os engenheiros ainda se esforçam para enviar um produto conceitualmente simples com uma interface da Web integrada e fácil de usar.

Embora a linha de comando seja o método principal pelo qual um usuário interage com o Mercurial, existem muitas extensões da interface gráfica do usuário (GUI) disponíveis e muitos ambientes de desenvolvimento integrado (IDE) oferecem suporte integrado à integração do Mercurial.

opções centralizadas de controle de versão

Opções do sistema de controle de versão centralizado

Os seguintes sistemas de controle de versão são algumas das opções centralizadas mais populares disponíveis.

Sistema de Versões Concorrentes (CVS)

Concurrent Versions System (CVS) é um software de controle de versão gratuito.

As origens do CVS estão com uma série de scripts de shell enviados em meados de 1986.

O CVS não é mais mantido (a última vez que os desenvolvedores lançaram um novo lançamento foi em 2008), mas você ainda encontrará algumas pessoas usando o CVS.

Ao usar o CVS, observe que a terminologia usada é ligeiramente diferente daquela usada por outros sistemas de controle de versão.

Por exemplo, um conjunto de arquivos relacionados é chamado de módulo, enquanto a série de módulos que um servidor CVS gerencia é chamada de repositório.

O CVS chama os arquivos que recebem check-out pelos desenvolvedores como cópia de trabalho, sandbox ou área de trabalho.

Revisões da cópia de trabalho são enviadas ao repositório por meio de confirmações, enquanto a atualização é o processo de aquisição das alterações agora presentes no repositório..

Subversão (SVN)

O Subversion (SVN) do Apache é um sistema de controle de versão / revisão de código aberto.

Mencionamos que o CVS (Concurrent Versions System) ainda tem alguns usuários, mas o CVS não é atualizado desde 2008.

Como tal, o Subversion foi projetado para agir como e é freqüentemente usado como uma alternativa / sucessora (principalmente) compatível ao CVS.

O que faz o Subversion valer a pena?

Enquanto sistemas distribuídos como o Git parecem chamar a atenção do mundo dos sistemas de controle de versão, o Subversion é comumente usado, especialmente na comunidade de código aberto.

O Subversion foi desenvolvido originalmente em 2000 como uma alternativa ao CVS, mas com correções de erros e recursos adicionais não encontrados no CVS.

Uma das maiores vantagens do Subversion é o seu built-in, permissões refinadas sistema.

Você pode limitar o acesso a arquivos e diretórios por usuário.

Além disso, o Subversion é uma boa opção para quem deseja arquivos binários e outros ativos armazenados nos mesmos repositórios que o código-fonte (ainda mais se você tiver um grande número desses arquivos binários).

Mercado-alvo fácil de usar e

Por fim, não desconsidere o fato de existir uma curva de aprendizado em sistemas de controle de versão.

O Subversion pode ser Mais fácil para que as pessoas (especialmente usuários não técnicos) aprendam e entendam do que outros sistemas de controle de versão.

Finalmente, o Subversion é uma boa opção para empresas que operam em indústrias fortemente regulamentadas.

Embora você possa certamente hackear qualquer sistema de controle de versão para manter as trilhas de auditoria, é necessário garantir que sua empresa esteja em conformidade com os regulamentos apropriados.

O SVN, como um sistema de nível corporativo, vem com o conjunto de recursos necessários para facilitar esse processo para você.

Team Foundation Server (TFS)

O Team Foundation Server (TFS) é a contribuição da Microsoft para o mundo dos sistemas de controle de versão.

O TFS também inclui recursos para:

  • Comunicando
  • Gerenciamento de requisitos
  • Gerenciamento de Projetos
  • Recursos de gerenciamento de teste e liberação.

Essencialmente, o TFS contém tudo o que você precisa para gerenciar todos os aspectos do ciclo de vida de desenvolvimento de software.

Com o que o TFS é usado?

O TFS pode ser usado com muitos diferentes ambientes de desenvolvimento integrado (IDEs).

Foi construído especialmente para uso com Estúdio visual ou Eclipse.

Você pode auto-hospedar o TFS ou assinar a versão hospedada chamada Visual Studio Team Services.

Além disso, o TFS é um dos poucos produtos que possuem extensibilidade incorporada.

Você certamente pode invadir outros sistemas para executar da maneira que deseja, se for contrário à maneira como o produto foi projetado, mas o TFS facilita esse processo..

Sumário

Existem muitos sistemas de controle de versão diferentes e, embora todos implementem o controle de versão de maneira ligeiramente diferente, o importante é que você adote um.

A diferença entre Git, CVS e SVN não é tão grande quanto a diferença entre não ter versus ter um sistema de controle de versão.

Não arrisque a perda catastrófica do seu código-fonte – adote um sistema de controle de versão hoje!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map