Qual é a melhor maneira de começar a usar o controle de versão em um projeto de código-fonte aberto?


10

Foi sugerido que eu pegasse meu código-fonte aberto do projeto devido ao seu tamanho e falta de habilidades, então verifiquei o Google Code e comecei a fazer um projeto, e agora ele está me perguntando se eu quero que o projeto tenha Git, Mercurial ou Subversion hospedagem de código.

Eu nem sei o que é hospedagem de código, e uma pesquisa me confundiu mais com os debates entre todas essas coisas, e isso é ainda pior, pois o Google Code está me perguntando que tipo de licença eu quero.

Acho que não estou entendendo direito o que realmente significa código aberto. Alguém pode fazer uma citação rápida de um leigo sobre o que é tudo isso? Muito apreciado.

Editar Houve três ótimas respostas nessas três versões de hospedagem de código, mas acho que não consegui comunicar a verdadeira questão: Basicamente, eu não tenho idéia de como esse material de código aberto funciona, por que eu hospedaria o código em algum lugar como este ? E isso significa que eu preciso remover o site da minha hospedagem atual ou esse é um tipo totalmente diferente de hospedagem? O que acontece quando eu faço o meu site de código aberto, que direitos tenho, quais direitos eu dou. Como isso funciona, as pessoas simplesmente vêm e jogam código para mim de graça? Talvez essas sejam perguntas estúpidas, e se for esse o caso, acho que preciso de respostas estúpidas, seriamente não tenho ideia do que é código aberto, exceto pelo conceito de compartilhamento de código ...



foi uma apresentação de slides incrível, acho que me ajudou a entender o básico, obrigado por compartilhar, agora é o material mais detalhado que me deixa sem noção.

11
São realmente duas perguntas, e ambas provavelmente são duplicadas. stackoverflow.com/questions/2303136/… e stackoverflow.com/questions/3859/…
sylvanaar

2
"Falta de habilidades" parece uma terrível razão para criar algo de código aberto. Se você tem uma ideia magnífica, mas não possui habilidades técnicas, então talvez. Eu não iria para o código aberto até encontrar um parceiro tecnicamente qualificado, preparado para se comprometer a produzir um primeiro corte do código e que gostaria de ir para o código aberto.
Tripleee 9/09/11

Tripleee você seria capaz de sugerir uma rede ou algo dessa natureza em que eu pudesse encontrar alguém com quem fazer parceria?
Nathan

Respostas:


7

por que eu hospedaria o código em algum lugar como este?

Um ponto chave do desenvolvimento de software de código aberto é compartilhar o código-fonte. Existem várias maneiras de fazer isso, como colocar arquivos tar / zip em um servidor web ou ftp. Serviços como o código do google (ou sourceforge.net, gitorious.org, bitbucket.org e muitos outros) eliminam a necessidade de executar seus próprios servidores para esse fim.

E isso significa que eu preciso remover o site da minha hospedagem atual ou esse é um tipo totalmente diferente de hospedagem?

Esses serviços não são hosts da web de uso geral, mas executam serviços muito especializados. Eles não devem ser a página inicial de um produto, mas mais um painel de desenvolvedor.

Com o código do Google você obtém

  • um wiki
  • um bugtracker
  • espaço regular para download de arquivos
  • um servidor de controle de versão

É claro que você pode configurar esses softwares em um servidor da Web comum (o controle de versão pode ser complicado, mas isso depende muito de detalhes), mas o principal benefício do uso de um host de desenvolvimento é que você não precisa tomar cuidado desses sistemas por conta própria. A principal desvantagem é que você não tem controle sobre qual software é usado no servidor, é necessário conviver com o que está disponível nesse host. Você também precisa considerar o que acontece se o serviço sair do negócio (ok, o Google nunca falha) e se você pode levar os dados do host atual para outro ou para o seu próprio servidor (pense em backups).

O que acontece quando eu faço o meu site de código aberto, que direitos tenho,

Essa é uma pergunta difícil, pois depende da lei do país em que você vive.

que direitos eu dou.

Isso depende da licença que você concede ao produto. Pode ir de código aberto proprietário (pense no PGP), onde o usuário basicamente não pode fazer nada com o código; no outro extremo da escala, o domínio é público, onde todos podem fazer o que quiserem.

Como isso funciona, as pessoas simplesmente vêm e jogam código para mim de graça?

É muito improvável que isso aconteça, pois seu produto precisa de popularidade suficiente para atrair outros desenvolvedores.

[...] e agora está me perguntando se eu quero que o projeto tenha hospedagem de código Git, Mercurial ou Subversion.

Estes são três sistemas de controle de versão diferentes, onde o Subversion é centralizado, enquanto o Git e o Mercurial são distribuídos.

Existem guerras religiosas sobre qual delas usar, mas o ponto principal é usar uma. Consulte http://martinfowler.com/bliki/VersionControlTools.html para obter mais detalhes.

Quando escolher o Subversion:

  • Você possui arquivos binários, que não podem ser facilmente mesclados, e precisa do fluxo de trabalho de bloqueio-> modificação-> confirmação-> desbloqueio, que o subversion suporta¹
  • Você precisa verificar apenas uma parte da estrutura de diretórios.

Is Existe uma extensão de bloqueio para mercurial, mas não tenho experiência com ele e não posso dizer se é utilizável.

Quando você não precisa dos recursos anteriores, é melhor usar o Mercurial ou o Git. Ambos têm as seguintes vantagens sobre o Subversion:

  • rápido (e com rápido eu realmente quero dizer rápido )
  • fácil ramificação e fusão (isso melhorou desde o Subversion> = 1.5, mas não é o mesmo)
  • confirmar e publicar está dissociado, para que você possa trabalhar sem perturbações em um recurso e publicar o trabalho quando estiver pronto
  • eles rastreiam o estado do diretório do produto como um todo
  • você obtém uma cópia completa de todo o histórico da versão ao clonar um repositório remoto
  • números de revisão criptograficamente protegidos, o que significa que, mesmo quando alguém quebra no servidor, ele não pode colocar o código no lugar sem alterar o histórico de revisões

    • mas como ninguém verifica essas revisões, esse recurso praticamente não é eficaz

9

A hospedagem de código é exatamente isso - um lugar para hospedar (ou manter) seu código.

Git, Mercurial e Subversion são todas as ferramentas de controle de origem que você usa para gerenciar seu histórico de códigos. Git e Mercurial são sistemas distribuídos, enquanto o Subversion é uma configuração mais tradicional baseada em servidor.

Dê uma olhada na Wikipedia ou algo parecido e veja o que mais lhe agrada. Pessoalmente, usamos o Mercurial e funciona muito bem para nós.


6

Joel Spolsky escreveu um ótimo tutorial sobre Hg (Mercurial) e acredito que a seção introdutória cobre o Subversion, incluindo as razões pelas quais você está atualizando para o Mercurial. Faça uma leitura, isso realmente me ajudou a entender muito sobre o Mercurial e o DVCS em geral.

Ah, e quando estiver pronto para hospedar, você pode usar o Google Code, BitBucket , Github (com a ajuda dessa excelente extensão ) ou outros.


O Mercurial é um excelente sistema, que me conquistou da subversão após apenas alguns minutos de uso.
Jim No Texas

3

Eu uso o git, que acho mais fácil de gerenciar devido ao controle distribuído. Hg também é bom para esse fim específico, mas não posso lhe dar conselhos, nunca o usei. O SVN é um sistema centralizado e, portanto, menos prático, mas pode ser um pouco mais simples.

Código aberto basicamente significa que você oferece a qualquer pessoa a capacidade de usar seu trabalho e desenvolvê-lo. Você pode definir os limites desse uso: GPL significa que o usuário precisa fazer seu trabalho adicional de código aberto, LGPL significa que não, por exemplo.


2

Subversion seria a opção mais fácil, porque é um VCS. Git e Mercurial são sistemas DVCS. Eles são mais modernos e mais poderosos, mas são mais difíceis de entender. Usar um front-end como o TortoiseSVN ou TortoiseHG (para Mercurial aka HG) também ajuda muito.

Se o seu software é um programa independente, você pode usar o GPL ou realmente abri-lo com uma licença BSD. Se o seu projeto for uma biblioteca à qual outra pessoa vinculará, use LGPL ou novamente o BSD; mas não use a GPL.

[editar]

Quanto à sua motivação original para o código-fonte aberto do software: Infelizmente, apenas criar software de código aberto não significa que você terá um fluxo de trabalho livre talentoso. Existem centenas de milhares de projetos de código aberto. Apenas uma pequena porcentagem deles tem membros contribuintes ativos. Os motivos pelos quais esses projetos são bem-sucedidos ou não são tão variados quanto os motivos pelos quais as empresas têm sucesso e fracassam. Se você deseja se tornar um bom programador e produzir um bom software, precisará gastar muito tempo aprendendo, escrevendo código e se comunicando com outras pessoas em sites como o StackOverflow.


11
Por que você diz que o svn é o mais fácil? Justifique esta afirmação.

11
@ Richard: Eu acho que ele quer dizer que é um pouco mais fácil de configurar e usar para uso básico, pelo menos eu concordo com essa aceitação. Discordo da ideia de que sua biblioteca não deve usar a GPL, é realmente uma posição política.
Kheldar

Use a GPL para uma biblioteca se desejar impor certas restrições ao seu uso. Use LGPL se quiser impor menos restrições.
Keith Thompson

0

Parece-me que, embora a maioria das pessoas aqui esteja respondendo como , ninguém realmente respondeu o porquê em sua pergunta.

Um dos primeiros projetos de código aberto que experimentei foi o fabuloso projeto Fractint , desenvolvido pelo Grupo de Sopa de Pedra, que foi inspirado na velha história folclórica da sopa de pedra .

Para mim, isso resume o espírito de código aberto melhor do que qualquer discurso de Stallman ou mesmo o Manifesto GNU original . É uma prova da força dessa comunidade que o Fractint ainda está sendo desenvolvido 23 anos depois que o fogo foi aceso sob esse pote de código específico .


0

Código aberto significa que qualquer pessoa pode ler, copiar, modificar e distribuir seu código. Você deve ter um entendimento firme das implicações disso antes de prosseguir. Talvez você deva ler um livro ou, pelo menos, navegar nos artigos da Wikipedia sobre o tópico e / ou http://opensource.org/ até sentir que entende o conceito.

(O livro O'Reilly Open Sources http://oreilly.com/openbook/opensources/book/index.html é útil, mas talvez não seja exatamente o que você está procurando.)

Qual sistema de controle de código fonte usar é completamente de importância secundária. Você pode copiar / colar seu código em uma página da web e pronto. Dito isto, o controle de versão é importante e um bom veículo para reduzir a fasquia para os desenvolvedores contribuírem. Qualquer uma das opções oferecidas pelo Google Code está correta; escolha a que você mais gosta ou adie a pergunta até que você possa perguntar a seus colaboradores qual deles eles gostariam de usar.


0

Tornar seu código ou projeto de código aberto significa que todos podem pegá-lo e modificá-lo da maneira que desejar. Isso depende do tipo de licença que você escolher usar, mas em geral código aberto significa que o código-fonte está disponível para qualquer pessoa fazer o download, modificá-lo e usá-lo como bem entender.

De qualquer forma, esse código precisa ser acessível por outras pessoas para obtê-lo.

Levar seu código para um repositório online público, como o GitHub, é a melhor maneira de fazê-lo. Primeiro, seu código agora está acessível ao público. Então, como esses serviços também oferecem controle de versão, seu código é um projeto organizado. Você pode acompanhar as alterações que você e outras pessoas fazem. Como também permite ramificar (separar) o projeto em outros projetos diferentes, você pode acompanhar todas as versões diferentes que outras pessoas criaram do seu código.

Isso também garante que seu código seja armazenado em um local seguro; você não precisa se preocupar com a perda por um disco rígido com defeito no seu PC, por exemplo. E quando você quer trabalhar nisso, pode trabalhar em qualquer lugar, porque o seu código está online, você pode encontrá-lo em qualquer lugar.

Se você decidir que é hora de exibir seu código para o mundo, basta enviar o link para o repositório de projetos online. É uma tecnologia com a qual as pessoas estão se acostumando; portanto, como todo mundo sabe, é mais fácil entender como fazer o download, postar mensagens, criar versões diferentes etc.

É como um padrão comum de fazer coisas, prática comum.

Alguns links que você pode achar úteis para explicar melhor o código aberto:


-6

Sobre o sistema de controle de versão, eu diria que você deve seguir a alternativa mais usada e mais recente: Ou seja: "Git". O Mercurial é menos popular e o SVN é antigo, lento e centralizado. Com o GIT, você se beneficiará de um sistema de controle de versão moderno e popular. Praticamente não há nada a perder.

Fontes (sobre a popularidade do DVCS):

/programming/tagged/git ~ 10k perguntas /programming/tagged/mercurial ~ 3k perguntas

http://www.googlefight.com/index.php?lang=pt_BR&word1=git&word2=mercurial

11700000 resultados vs

1580000 resultados

Em relação à licença: talvez você deva procurar as mais comuns: GLP, MIT, LGPL, BSD e escolher a que melhor se adequa ao seu projeto.


7
O Mercurial não é proprietário ... é de código aberto exatamente como o Git!
Christian Specht

4
Fanboy responde com argumentos parcialmente errados.
Oben Sonne

11
"mais utilizado" - forneça uma referência à sua fonte dessas informações.
Sylvanaar

Desculpe pessoal .. É apenas a minha percepção das coisas: acho que o Git é mais usado que o Mercurial, e sei que o SVN é antigo, lento e centralizado ... Gostaria de saber se seus comentários são menos comentários de fanboys do que os meus chamados resposta fanboy. Vamos, usos hub git git, o Linux usa kernel do git, todo projeto em minhas usos departamento git ...
Pedro Rolo

2
Talvez a abundância de perguntas sobre o Git também ilustre que é mais difícil de usar? Algumas pessoas usaram dados semelhantes ao investigar quais estruturas de desenvolvimento da Web eram as mais populares onde o mesmo ponto foi levantado (comentando as imprecisões).
Tim Post
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.