¿Cuál es la mejor manera de comenzar a usar el control de versiones en un proyecto de código abierto?


10

Me sugirieron que tomara el código abierto de mi proyecto debido a su tamaño y mi falta de habilidades, así que revisé Google Code, comencé a hacer un proyecto y ahora me pregunta si quiero que el proyecto tenga Git, Mercurial o Subversion código de alojamiento.

Ni siquiera sé qué es el alojamiento de código, y una búsqueda simplemente me confundió más con los debates entre todas estas cosas, y esto empeora aún más, ya que Google Code me pregunta qué tipo de licencia quiero.

Creo que no entiendo lo que realmente significa el código abierto, ¿alguien puede hacer una hoja de trucos rápida sobre qué es todo esto? Muy apreciado.

Editar Ha habido muchas respuestas excelentes en estas tres versiones de alojamiento de código, pero creo que no pude comunicar la pregunta real: Básicamente, no tengo idea de cómo funciona este código abierto, ¿por qué alojaría el código en algún lugar como este? ? ¿Y eso significaría que tengo que quitar el sitio de mi alojamiento actual o es un tipo de alojamiento completamente diferente? Qué sucede cuando hago que mi sitio sea de código abierto, qué derechos tengo, qué derechos cedo. ¿Cómo funciona? ¿La gente viene y me lanza un código gratis? Quizás estas son preguntas estúpidas, y si ese es el caso, entonces supongo que necesito respuestas estúpidas, en serio no tengo idea de qué es el código abierto, excepto por el concepto de compartir código ...



fue una presentación de diapositivas increíble, creo que me ayudó a comprender los conceptos básicos, gracias por compartir, ahora son las cosas más detalladas las que no me dan idea.

1
Esto es realmente 2 preguntas, y ambas son probablemente duplicadas. stackoverflow.com/questions/2303136/… , y stackoverflow.com/questions/3859/…
sylvanaar

2
La "falta de habilidades" suena como una terrible razón para hacer algo de código abierto. Si tiene una idea magnífica, pero carece de habilidades técnicas, tal vez. No iría a código abierto hasta que encontrara un socio técnicamente calificado que esté preparado para comprometerse a producir un primer corte del código, y que quisiera hacerlo de código abierto.
tripleee

Tripleee, ¿podrías sugerir una red o algo por el estilo en el que posiblemente pueda encontrar a alguien con quien asociarme?
Nathan

Respuestas:


7

¿Por qué debería alojar el código en algún lugar como este?

Un punto clave del desarrollo de software de código abierto es compartir el código fuente. Hay varias formas de hacer esto, como colocar archivos tar / zip en un servidor web o ftp. Los servicios como el código de Google (o sourceforge.net, gitorious.org, bitbucket.org y muchos otros) eliminan la necesidad de ejecutar sus propios servidores para este propósito.

¿Y eso significaría que tengo que quitar el sitio de mi alojamiento actual o es un tipo de alojamiento completamente diferente?

Estos servicios no son servidores web de uso general, pero ejecutan servicios muy especializados. No están destinados a ser la página de inicio de un producto, sino más bien un panel de desarrollador.

Con el código de google obtienes

  • un wiki
  • un rastreador de errores
  • espacio de descarga de archivos regular
  • un servidor de control de versiones

Por supuesto, puede configurar este software en un servidor web normal (el control de versiones puede ser complicado, pero eso depende en gran medida de los detalles), pero el principal beneficio de usar un host de desarrollo es que no necesita tener cuidado de estos sistemas para los tuyos. El principal inconveniente es que no tienes control sobre qué software se usa en el servidor, tienes que vivir con lo que está disponible en ese host. También debe tener en cuenta qué sucede si el servicio deja de funcionar (está bien, Google nunca falla), y si puede llevar los datos del host actual a otro o a su propio servidor (piense en las copias de seguridad).

Qué sucede cuando hago que mi sitio sea de código abierto, qué derechos tengo,

Esta es una pregunta difícil, ya que depende de la ley del país donde vives.

¿Qué derechos le doy?

Esto depende de la licencia que otorgue al producto. Puede ir de código abierto patentado (piense en PGP) donde el usuario básicamente no puede hacer nada con el código, en el otro extremo de la escala está el dominio público, donde cada uno puede hacer lo que quiera.

¿Cómo funciona? ¿La gente viene y me lanza un código gratis?

Es muy poco probable que esto suceda, ya que su producto necesita suficiente popularidad para atraer a otros desarrolladores.

[...] y ahora me pregunta si quiero que el proyecto tenga alojamiento de código Git, Mercurial o Subversion.

Estos son tres sistemas de control de versiones diferentes, donde Subversion es centralizado, mientras que Git y Mercurial se distribuyen.

Hay guerras religiosas sobre cuál usar, pero el punto principal es usar uno. Consulte http://martinfowler.com/bliki/VersionControlTools.html para obtener más detalles.

Cuándo elegir Subversion:

  • Tiene archivos binarios, que no se pueden combinar fácilmente, y necesita el flujo de trabajo bloquear-> modificar-> confirmar-> desbloquear, que admite subversión¹
  • Debe verificar solo una parte de la estructura de directorios.

¹ Hay una extensión de bloqueo para mercurial, pero no tengo experiencia con ella y no puedo decir si es utilizable.

Cuando no necesita las características anteriores, es mejor usar Mercurial o Git. Ambos tienen las siguientes ventajas sobre Subversion:

  • rápido (y con rápido quiero decir rápido )
  • fácil ramificación y fusión (esto mejoró desde Subversion> = 1.5, pero no es lo mismo)
  • confirmar y publicar está desacoplado, por lo que puede trabajar sin molestias en una función y publicar el trabajo cuando haya terminado
  • rastrean el estado del directorio de productos como un todo
  • obtienes una copia completa del historial completo de la versión cuando clonas un repositorio remoto
  • números de revisión protegidos criptográficamente, lo que significa que incluso cuando alguien interrumpe el servidor, no puede poner el código en su lugar sin cambiar el historial de revisión

    • pero como nadie verifica estas revisiones, esta característica prácticamente no es efectiva

9

El alojamiento de código es exactamente eso: un lugar para alojar (o mantener) su código.

Git, Mercurial y Subversion son todas las herramientas de control de código fuente que usa para administrar su historial de código. Git y Mercurial son sistemas distribuidos, mientras que Subversion es una configuración basada en un servidor más tradicional.

Eche un vistazo a Wikipedia o algo así y vea cuál le atrae más. Personalmente usamos Mercurial y funciona muy bien para nosotros.


6

Joel Spolsky ha escrito un gran tutorial sobre Hg (Mercurial) y creo que la sección introductoria cubre Subversion, incluidas las razones por las que está actualizando a Mercurial. Lee eso, realmente me ayudó a entender mucho sobre Mercurial y DVCS en general.

Ah, y cuando esté listo para alojar, puede usar Google Code, BitBucket , Github (con la ayuda de esta excelente extensión ) u otros.


Mercurial es un excelente sistema, me ganó por subversión después de solo unos minutos de uso.
Jim en Texas

3

Uso git, que me resulta más fácil de administrar debido al control distribuido. Hg también es bueno para este propósito en particular, pero no puedo darle consejos al respecto, ya que nunca lo he usado. SVN es un sistema centralizado y, por lo tanto, menos práctico, pero podría ser un poco más simple.

El código abierto básicamente significa que le da a cualquiera la capacidad de usar su trabajo y construir sobre él. Puede establecer los límites de ese uso: GPL significa que el usuario debe hacer que su trabajo agregado sea de código abierto, LGPL significa que no lo hace, por ejemplo.


2

Subversion sería la opción más fácil porque es un VCS. Git y Mercurial son sistemas DVCS. Son más modernos y más potentes pero más difíciles de entender. El uso de un front-end como TortoiseSVN o TortoiseHG (para Mercurial, también conocido como HG) también ayuda mucho.

Si su software es un programa independiente, puede usar GPL o realmente abrirlo con una licencia BSD. Si su proyecto es una biblioteca con la que alguien más se vinculará, use LGPL o BSD nuevamente; pero no uses GPL.

[editar]

En cuanto a su motivación original para el software de código abierto: desafortunadamente, simplemente hacer que el software sea de código abierto no significa que obtendrá una afluencia de mano de obra gratuita con talento. Hay cientos de miles de proyectos de código abierto. Solo un pequeño porcentaje de ellos tiene miembros contribuyentes activos. Las razones que hacen que estos proyectos tengan éxito o no son tan variadas como las razones por las cuales las empresas tienen éxito y fracasan. Si desea convertirse en un buen programador y producir un buen software, tendrá que pasar mucho tiempo aprendiendo, escribiendo códigos y comunicándose con otras personas en sitios como StackOverflow.


1
¿Por qué dices que svn es el más fácil? Por favor justifique esta declaración.

1
@ Richard: Creo que quiere decir que es un poco más fácil de configurar y usar para uso básico, al menos estoy de acuerdo con esa aceptación. No estoy de acuerdo con la idea de que su biblioteca no debe usar GPL, es realmente una postura política.
Kheldar

Use GPL para una biblioteca si desea imponer ciertas restricciones sobre su uso. Use LGPL si desea imponer menos restricciones.
Keith Thompson el

0

Me parece que si bien la mayoría de las personas aquí están respondiendo el cómo , nadie realmente ha respondido el por qué en su pregunta.

Uno de los primeros proyectos de código abierto que experimenté fue el fabuloso proyecto Fractint , desarrollado por Stone Soup Group que se inspiró en la vieja historia popular de sopa de piedra .

Para mí, esto encapsula el espíritu de código abierto mejor que cualquier diatriba de Stallman o incluso el Manifiesto original de GNU . Es un testimonio de la fortaleza de esa comunidad que Fractint todavía se está desarrollando 23 años después de que se encendiera el fuego bajo esa olla de código en particular .


0

El código abierto significa que cualquiera puede leer, copiar, modificar y distribuir su código. Debe tener una comprensión firme de las implicaciones de esto antes de continuar. Tal vez debería leer un libro o al menos navegar por los artículos de Wikipedia sobre el tema y / o http://opensource.org/ hasta que sienta que comprende el concepto.

(El libro de O'Reilly Open Sources http://oreilly.com/openbook/opensources/book/index.html es útil pero quizás no sea exactamente lo que está buscando).

Qué sistema de control de código fuente usar es completamente de una importancia secundaria. Puede copiar / pegar su código en una página web y listo. Dicho esto, el control de versiones es importante y un buen vehículo para reducir el nivel de contribución de los desarrolladores. Cualquiera de las opciones que ofrece Google Code está bien; vaya con la que le guste, o tal vez posponga la pregunta hasta que pueda preguntar a sus colaboradores cuál les gustaría usar.


0

Hacer que su código o proyecto sea de código abierto significa que todos pueden tomarlo y modificarlo como desee. Esto depende del tipo de licencia que elija usar, pero en general, el código abierto significa que el código fuente está disponible para que cualquiera lo descargue, modifique y use según lo desee.

De todos modos, este código debe ser accesible por otras personas para obtenerlo.

Llevar su código a un repositorio público en línea como GitHub es la mejor manera de hacerlo. Primero, su código ahora es accesible al público. Luego, dado que dichos servicios también ofrecen Control de versiones, su código está organizado por proyectos. Puede realizar un seguimiento de los cambios que usted y otras personas realizan. Dado que también permite ramificar (separar) el proyecto en otros proyectos diferentes, puede realizar un seguimiento de todas las versiones diferentes que otras personas hicieron de su código.

Esto también garantiza que su código se almacene en un lugar seguro, no tiene que preocuparse de que se pierda por un disco duro defectuoso en su PC, por ejemplo. Y cuando quiera trabajar en eso, puede trabajar desde cualquier lugar porque su código está en línea, puede encontrarlo en cualquier lugar.

Si luego decide que es hora de mostrar su código al mundo, solo es cuestión de enviar el enlace a su repositorio de proyectos en línea. Es una tecnología a la que la gente se está acostumbrando, por lo que, como todo el mundo lo sabe, es más fácil entender cómo descargarlo, publicar mensajes, crear diferentes versiones, etc.

Es como un estándar común de hacer cosas, práctica común.

Algunos enlaces que pueden resultarle útiles para explicar el código abierto:


-6

Sobre el sistema de control de versiones, diría que debe seguir con la alternativa más utilizada y más reciente: es decir, "Git". Mercurial es menos popular y SVN es antiguo, lento y centralizado. Con GIT, se beneficiará de un sistema de control de versiones moderno y popular. Prácticamente no hay nada que perder.

Fuentes (en relación con la popularidad de DVCS):

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

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

11700000 resultados vs

1580000 resultados

Con respecto a la licencia: tal vez debería considerar las más comunes: GLP, MIT, LGPL, BSD y elegir la que mejor se adapte a su proyecto.


77
Mercurial no es propietario ... ¡es de código abierto exactamente como Git!
Christian Specht

44
Fanboy responde con argumentos parcialmente equivocados.
Oben Sonne

1
"más utilizado": proporcione una referencia a su fuente de información.
sylvanaar

Lo siento, gente ... Es solo mi percepción de las cosas: supongo que Git es más usado que Mercurial, y sé que SVN es viejo, lento y centralizado ... Me pregunto si sus comentarios son menos fanboy-comentarios que mi supuesto fanboy-respuesta. Vamos, git hub usa git, el kernel de linux usa git, cada proyecto en mi departamento usa git ...
Pedro Rolo

2
¿Quizás la abundancia de preguntas sobre Git también ilustra que es más difícil de usar? Algunas personas han utilizado datos similares al investigar qué marcos de desarrollo web eran los más 'populares' donde se planteó el mismo punto (comentando las inexactitudes).
Tim Post
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.