Gestión de proyectos para ir con GitHub [cerrado]


95

(EDITAR: esta pregunta ahora está desactualizada para mi problema particular, ya que Google Code es compatible con git ahora y he convertido Protocol Buffers a Mercurial de todos modos. Sin embargo, sigue siendo de interés general, en mi opinión).

Mi puerto de búferes de protocolo C # usa github para su control de código fuente, y estoy empezando a disfrutar mucho usando git. Sin embargo, hasta donde yo sé, github no proporciona ninguna herramienta de gestión de proyectos: seguimiento de características y defectos, discusiones, solicitudes de características, documentos, etc. Dadas mis afiliaciones, Google Code sería una elección natural, pero parecería extraño cree un proyecto allí pero aloje la fuente en github.

Esta pregunta sobre Fogbugz / Assembla parece centrarse principalmente en el seguimiento de defectos. Me preguntaba qué experiencias han tenido otros cuando se trata de una solución de gestión de proyectos más "completa". ¿Fogbugz realmente hace todo lo que necesito? (Usar un wiki para documentos tiene sus ventajas, aunque también quiero poder distribuir documentación con el código). Más allá de las características explícitas mencionadas en el primer párrafo, ¿hay otros aspectos del proyecto que debería considerar y que me haya perdido?

Esto definitivamente seguirá siendo un proyecto de código abierto, y aunque prefiero no pagar, no me importa si se requiere una pequeña tarifa. Actualmente soy el único desarrollador, pero eso puede cambiar y es muy posible que haya muchas personas que presenten errores y soliciten funciones. (En otras palabras, espero y espero que sea popular, pero yo hago la mayor parte del trabajo).

Anteriormente he contribuido a varios proyectos de código abierto, pero no he hecho mucho en la forma de ejecutar uno muy visible y activo. ( MiscUtil todavía está "alojado" en mi sitio web, con lanzamientos ocasionales; el control de fuente real está en mi NAS local).

¿Alguien quiere compartir sus experiencias?

EDITAR: Otra opción que estoy considerando ahora es un proyecto de Google Code (realmente me gustaría ser leal a mi empleador) y una fusión ocasional de git a svn (al menos, cada vez que hago un lanzamiento). Esto también permitiría a los usuarios que no son de git hacerse con la fuente fácilmente.


¿Está cerca de lanzar Protocol Buffers en C #? Me moría de ganas de probarlo.
David Robbins

1
@David: Ya está en un estado utilizable, aunque es un poco "manual". Consulte code.google.com/p/protobuf-csharp-port para obtener algunas instrucciones preliminares.
Jon Skeet

No estoy seguro de si este fue el caso la última vez que editó esta pregunta, pero GitHub crea automáticamente archivos descargables de su código en cualquier etiqueta. También puede descargar el estado del código en cualquier confirmación.
Xiong Chiamiov

11
También puede usar mercurial en el código de Google, mercurial es bastante simple y tiene casi la misma función que git
dzen

Se agregó compatibilidad con GoogleCode
gavenkoa

Respuestas:


45

Si estás pensando que realmente serás el único desarrollador , Fogbugz te ayudará a mantener la cordura. Fogbugz es un gran producto, crea comunicaciones enfocadas y puede convertir cualquier cosa en un caso (problema). Hace todo eso tan bien como cualquier sistema que haya visto.

Pero su orientación es comercial: comunicación eficiente entre usuarios y soporte técnico, mejorar la confiabilidad de los horarios, enfocar y priorizar en lo que se está trabajando, discusiones internas y externas separadas, algunos buenos informes para rastrear que las cosas se están manejando. (La única crítica en la que puedo pensar es que no bloquea casos ni rastrea dependencias, lo cual es realmente útil para esos errores enterrados profundamente).

Poco de este conjunto de características lo ayudará a construir un proyecto de código abierto activo, con una comunicación abierta y viva y la necesidad de construir una comunidad y hacer que los usuarios se conviertan en desarrolladores a medida que el proyecto crece. Entonces, si ahí es donde desea terminar, es posible que realmente desee los canales de comunicación menos enfocados de uno de estos sistemas de seguimiento livianos.

Todavía no he usado Google Code en un proyecto, pero en términos de comunicación transparente y abierta, parece un buen soporte para un proyecto de código abierto activo. Además ya lo sabes. Si desea aumentar la participación en su proyecto, el código de Google parece el camino a seguir.


7
Gracias por eso, todas las cosas útiles. Hay un beneficio adicional para Google Code: si falta una función, es más probable que pueda hacer que suceda :) (Estoy seguro de que Fogbugz et al se toman en serio las solicitudes de funciones, pero con Google Code puedo trabajar en sistema en sí en 20% de tiempo ...)
Jon Skeet

28

GitHub introdujo recientemente un rastreador de problemas propio; Sin embargo, no he hecho un análisis competitivo para determinar cómo se compara con otras opciones mencionadas en este hilo.


GitHub tiene actualmente la gestión de proyectos incorporada. Sin embargo, es bastante minimalista (a la 37signals), pero sus precios son competitivos si los usa para el control de versiones y la gestión de proyectos. github.com/features/projects
m33lky

14

Utilizo GitHub junto con Lighthouse para el seguimiento de problemas. Es un poco básico en comparación con algunas de las otras opciones, pero al mismo tiempo funciona muy bien si solo desea una herramienta liviana de la que no tenga que preocuparse demasiado. Puede integrarse con GitHub si lo desea, y también es gratuito para proyectos de código abierto.


12

Como es habitual cuando alguien pregunta esto, menciono a Redmine como lo hice en esta pregunta. Sé que la pregunta ya tiene su "mejor respuesta", pero creo que vale la pena mencionarla.


Actualización: redmine.org
dparkar

10

Usamos bitbucket.org , que no es GIT, es Mercurial *, pero tiene seguimiento de errores / problemas por rama, etc.

Creo que puede ser muy útil integrar estas cosas con el lugar donde administras tu código fuente para hacer referencias cruzadas como el número de problema en un mensaje de confirmación. O Mensaje fijo para un problema que contiene el número de revisión del código. Perdería esto si elige un BTS separado como el código de Google. Como se mencionó en otra respuesta, Trac es realmente bueno en lo de integración.

Editar: Debo decir que para mi proyecto de código abierto más utilizado, en realidad lo tenemos en:

  1. Bitbucket (gestión de código fuente)
  2. Launchpad (informes de errores del usuario, gestión de traducciones)
  3. Trac autohospedado (wiki, seguimiento de problemas de proyectos y desarrolladores, duplicación de código fuente)
  4. Código de Google (descargas de archivos)

Y sé que esto suena loco, pero elegimos las mejores partes de cada servicio. Y sorprendentemente nadie se queja.

* que es mejor en mi opinión de todos modos, pero por favor no me llames.


No hay llamas aquí: no he usado Mercurial, así que no puedo comentar. Creo que si realmente fuera a mover el alojamiento de origen, simplemente iría directamente a Google Code y svn, con lo que ya me siento cómodo. Yo creo que quiero mantener el repositorio GitHub - pero ver a mi pregunta de edición ...
Jon Skeet

3
En mi opinión, SVN es la principal debilidad del código de Google. Pero como dices, se trata de con qué te sientes cómodo.
Ali Afshar

También editado para reflejar mi propio uso personal.
Ali Afshar

Sé que es una tontería, pero tendría problemas para enviar los datos que realmente quiera guardar en un servidor llamado "bitbucket".
TED

1
bitbucket ahora también hace Git
Radek

8

¿Ha considerado Trac ?

Parece haber una revisión "entusiasta" de una integración de git-Trac .

No tengo experiencia personal con estas herramientas, pero es posible que desee verificar la integración.


La pregunta de Fogbugz / Assembla a la que hice referencia parecía implicar que Trac estaba un poco por detrás de FogBugz. También me gusta la idea de las discusiones del proyecto alojadas (aunque ciertamente podría usar Grupos de Google para eso si fuera necesario).
Jon Skeet

1

Utilizo github y google code en algunos lugares. El rastreador de problemas del código de Google es lo suficientemente decente, pero no puedo lidiar con la subversión.

Eche un vistazo a mi cliente java memcached para ver un ejemplo de esto, particularmente la pestaña de origen en la parte superior.


Frio. Parece una muy buena solución. Todavía puedo clonar a la subversión para que sea más fácil para aquellos que quieran usar eso; quiero ser lo más inclusivo posible.
Jon Skeet

2
Me imagino que las descargas de github son suficientes para cualquiera que quiera subversión. Cualquiera que haga cosas más avanzadas que descargar la última versión de su repositorio svn probablemente ya esté usando git. :)
Dustin

1

En el trabajo usamos FogBugz y, en mi opinión, es, con mucho, la mejor herramienta de este tipo. Lo usaría para los proyectos sin fines de lucro en los que trabajo, excepto que es tan caro para más de 2 usuarios.

Para los proyectos sin fines de lucro, utilizamos Lighthouse para el seguimiento de problemas. Está bien por lo que cuesta y, francamente, no puedo encontrar ninguna alternativa adecuada dentro de su rango de precios. El seguimiento de problemas de Trac es un poco mejor que el de Bugzilla ... Sé que a mucha gente le encanta Trac, pero lo encuentro muy inflexible. Las deficiencias de Trac nos llevaron a Lighthouse.

Mis proyectos sin fines de lucro buscan posiblemente mudarse a Bitbucket . Además del seguimiento de problemas, nos permitiría consolidar nuestros repositorios desde beanstalkapp.com, así como agregar una wiki.

Dicho todo esto, si FogBugz-on-Demand tuviera un precio incluso remotamente similar a Lighthouse.app para pequeños recuentos de usuarios, nos llevaría allí en un santiamén. Cuando usa FB en el trabajo y luego Lighthouse.app por la noche ... usar Lighthouse se siente como si le hubieran cortado el brazo.



1

Yo también uso github con Lighthouse. Y si su mensaje de confirmación contiene algo como

[# 32 estado: resuelto]

Lighthouse resolverá el ticket # 32 contra el compromiso, lo que encuentro rápido y útil. Aparte de eso, Lighthouse es un poco, eh, ligero en funciones.


0

Sugeriría JavaForge como alternativa, ya que tiene todo lo que busca:

  • Ofrece alojamiento gratuito con Mercurial y Git (o mixto).
  • Su rastreador de problemas está a años luz de GitHub. Es extremadamente potente y personalizable, puede rastrear requisitos, solicitudes de funciones, errores, tareas, etc.
  • Proporciona Gestión de documentos, también con acceso WebDAV (compartir tan fácil como con carpetas compartidas).
  • Tiene una wiki incorporada para la autoría colaborativa de documentación, requisitos, etc.
  • Tiene foros de discusión.

Tenga en cuenta que el sitio funciona con codeBeamer , nuestro producto comercial probado en batalla por compañías globales.

(Descargo de responsabilidad: somos un proveedor comercial de soluciones ALM ágiles).



0

También puede intentar usar una herramienta como BusyFlow . Allí puede realizar un seguimiento de las confirmaciones de GitHub y comentarlas (los comentarios se sincronizan con GitHub). Para otras facetas de gestión de proyectos, BusyFlow se integra con Google Calendar, Trello, Basecamp, Pivotal Tracker, etc. Para que pueda ver sus elementos de GitHub junto con tareas, archivos y eventos del calendario.

(Descargo de responsabilidad: soy cofundador de BusyFlow).


-1

¿Ha considerado CodePlex?


1
No lo había hecho, pero al final me decidí por Google Code y github, desarrollando contra github y presionando a svn cuando era apropiado.
Jon Skeet
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.