GitHub와 함께 사용할 프로젝트 관리 [닫기]


95

(편집 :이 질문은 이제 Google 코드가 git을 지원하고 어쨌든 프로토콜 버퍼를 Mercurial로 변환했기 때문에 내 특정 문제에 대해 구식입니다. 그러나 여전히 일반적인 관심사 인 IMO입니다.)

내 C # 프로토콜 버퍼 포트 는 소스 제어를 위해 github를 사용하며 git 사용을 정말 즐기기 시작했습니다. 그러나 내가 말할 수있는 한, github는 결함 및 기능 추적, 토론, 기능 요청, 문서 등 프로젝트 관리 도구를 제공하지 않습니다. 내 제휴를 감안할 때 Google 코드 는 자연스러운 선택이지만 이상하게 보일 것입니다. 거기에 프로젝트를 생성하지만 github에서 소스를 호스팅하십시오.

Fogbugz / Assembla에 대한이 질문은 대부분 결함 추적에 초점을 맞추는 것 같습니다. 좀 더 "완전한"프로젝트 관리 솔루션과 관련하여 다른 사람들이 겪은 경험이 궁금합니다. Fogbugz는 실제로 필요한 모든 작업을 수행합니까? (나는 또한 코드와 문서를 배포 할 수 있도록하려면 있지만, 문서에 대한 위키는 장점을 가지고 사용.) 첫 번째 단락에서 언급 한 명시 적 기능을 넘어, 내가 거기에 다른 프로젝트 측면입니다 해야 내가 놓친 고려 될 수는?

이것은 확실히 오픈 소스 프로젝트로 남을 것이고, 비록 내가 지불하지 않더라도 약간의 비용이 필요하더라도 상관하지 않습니다. 현재 저는 유일한 개발자이지만 변경 될 수 있으며 버그 및 기능 요청을 제출하는 사람들이 많이있을 수 있습니다. (즉, 인기가 있기를 바라며 기대하지만 대부분의 작업은 나와 함께합니다.)

이전에는 다양한 오픈 소스 프로젝트에 기여 했지만 매우 눈에 잘 띄고 활동적인 프로젝트를 실행하는 데 많은 일을하지 않았습니다. ( MiscUtil 은 현재 내 웹 사이트에 "호스팅"되어 있으며 가끔 릴리스가 있습니다. 실제 소스 제어는 내 로컬 NAS에 있습니다.)

자신의 경험을 공유하고 싶은 사람이 있습니까?

편집 : 지금 고려중인 또 다른 옵션은 Google 코드 프로젝트 (내 고용주에게 충실하고 싶습니다)와 가끔씩 git에서 svn으로 병합하는 것입니다 (적어도 릴리스 할 때마다). 이를 통해 git 사용자가 아닌 사용자도 소스를 쉽게 파악할 수 있습니다.


C #에서 프로토콜 버퍼를 출시 할 예정입니까? 나는 그것을 시험해보고 싶었다.
— David Robbins

1
@David : 약간 "수동"이지만 이미 사용 가능한 상태입니다. 몇 가지 예비 지침 은 code.google.com/p/protobuf-csharp-port 를 참조하세요 .
— Jon Skeet

이 질문을 마지막으로 편집했을 때의 경우인지 확실하지 않지만 GitHub는 모든 태그에서 코드의 다운로드 가능한 아카이브를 자동으로 생성합니다. 커밋에서 코드 상태를 다운로드 할 수도 있습니다.
— Xiong Chiamiov 2009

11
Google 코드에서도 mercurial을 사용할 수 있습니다. mercurial은 매우 간단하며 git과 거의 동일한 기능을 가지고 있습니다
— dzen

GoogleCode는 Git에 대한 지원을 추가했습니다 : code.google.com/p/support/wiki/GitFAQ
— gavenkoa

답변:


45

당신이 정말로 유일한 개발자가 될 것이라고 생각한다면 Fogbugz는 당신의 정신을 유지하는 데 도움이 될 것입니다. Fogbugz는 훌륭한 제품이며 집중된 커뮤니케이션을 구축하고 모든 것을 사례 (문제)로 바꿀 수 있습니다. 내가 본 모든 시스템뿐만 아니라 모든 것을 수행합니다.

그러나 그 방향은 상업적입니다. 사용자와 기술 지원 간의 효율적인 커뮤니케이션, 일정의 신뢰성 향상, 진행중인 작업에 집중 및 우선 순위 지정, 내부 및 외부 토론 분리, 작업 처리를 추적하는 좋은보고. (내가 생각할 수있는 유일한 비판은 케이스 블로킹과 의존성 추적을하지 않는다는 것인데, 이는 깊이 묻혀있는 버그에 정말 유용합니다.)

이 기능 세트 중 일부는 개방적이고 활발한 커뮤니케이션과 커뮤니티 구축의 필요성을 통해 활성 오픈 소스 프로젝트를 구축하는 데 도움이되지 않으며 프로젝트가 성장함에 따라 사용자가 개발자로 발전하도록합니다. 그래서 그것이 당신이 원하는 곳이라면, 이러한 경량 추적 시스템 중 하나의 덜 집중된 통신 채널을 정말로 원할 수 있습니다.

아직 프로젝트에서 Google 코드를 사용하지 않았지만 투명하고 열린 커뮤니케이션 측면에서 활성 오픈 소스 프로젝트에 대한 좋은 지원처럼 보입니다. 게다가 이미 알고 있습니다. 프로젝트 참여를 늘리고 싶다면 Google 코드가 갈 길처럼 보입니다.


7
감사합니다-모든 유용한 것들. Google 코드에는 추가적인 이점이 있습니다. 기능이 누락 된 경우이를 실현할 가능성이 더 높습니다. :) (Fogbugz 등은 기능 요청을 진지하게 받아들이지 만 Google 코드를 사용하면 시스템 자체가 20 % 시간에 ...)
— Jon Skeet

28

GitHub는 최근 자체 이슈 트래커 를 도입했습니다 . 그래도이 스레드에 언급 된 다른 옵션을 측정하는 방법을 결정하기 위해 경쟁 분석을 수행하지 않았습니다.


GitHub에는 현재 프로젝트 관리 기능이 내장되어 있습니다. 그래도 상당히 미니멀하지만 (37 신호), 버전 제어 및 프로젝트 관리에 사용하면 가격이 경쟁력이 있습니다. github.com/features/projects
— m33lky

14

문제 추적을 위해 Lighthouse 와 함께 GitHub를 사용 합니다. 다른 옵션에 비해 약간의 뼈대가 있지만 동시에 너무 걱정할 필요가없는 가벼운 도구를 원한다면 매우 잘 작동합니다. 원하는 경우 GitHub와 통합 할 수 있으며 오픈 소스 프로젝트에서도 무료입니다.


12

누군가이 질문을 할 때 평소처럼 이 질문 에서했던 것처럼 Redmine 을 언급 합니다. 질문에 이미 "최상의 답변"이 있다는 것을 알고 있지만 언급 할 가치가 있다고 생각합니다.


업데이트 : redmine.org
— dparkar

10

우리 는 GIT가 아닌 Mercurial * 인 bitbucket.org를 사용 하지만 분기별로 버그 / 문제 추적 기능이 있습니다.

커밋 메시지에서 issue-number와 같은 것을 상호 참조하기 위해 소스 코드를 관리하는 장소와 이러한 것들을 통합하는 것이 매우 유용 할 수 있다고 생각합니다. 또는 코드 개정 번호가 포함 된 문제에 대한 수정 된 메시지. Google 코드와 같은 별도의 BTS를 선택하면 이것을 잃게됩니다. 다른 답변에서 언급했듯이 Trac은 통합에 정말 능숙합니다.

편집 : 가장 널리 사용되는 오픈 소스 프로젝트의 경우 실제로 다음 위치에 있다고 말해야합니다.

  1. Bitbucket (소스 코드 관리)
  2. 런치 패드 (사용자 버그보고, 번역 관리)
  3. 자체 호스팅 Trac (위키, 프로젝트 및 개발자 문제 추적, 소스 코드 미러)
  4. Google 코드 (파일 다운로드)

이 말이 이상하게 들리 겠지만 우리는 각 서비스에서 가장 좋은 부분을 골라서 선택합니다. 놀랍게도 아무도 불평하지 않습니다.

* 어쨌든 제 생각에는 더 낫지 만 제발 날 불 태우지 마세요.


여기에 타 오르지 마십시오. 저는 Mercurial을 사용하지 않았으므로 언급 할 수 없습니다. 제가 실제로 소스 호스팅을 옮길 경우 이미 익숙한 Google 코드와 svn으로 바로 이동할 것입니다. 나는 github 저장소를 유지하고 싶다고 생각 합니다. 그러나 제 질문 편집을보십시오 ...
— Jon Skeet

3
제 생각에는 SVN이 Google 코드의 주요 약점입니다. 그러나 당신이 말했듯이 그것은 당신이 편안하게 느끼는 것에 관한 것입니다.
— Ali Afshar

또한 내 개인적인 용도를 반영하도록 편집되었습니다.
— 알리 아프 샤

나는 그것이 어리 석다는 것을 알고 있지만, "bitbucket"이라는 서버에 저장하고 싶은 데이터를 커밋하는 데 어려움을 겪을 것입니다.
— TED

1
bitbucket은 이제 Git도 지원합니다
— Radek

8

Trac 을 고려해 보셨습니까 ?

git-Trac 통합에 대한 "열정적 인"리뷰가있는 것 같습니다 .

이 도구에 대한 개인적인 경험은 없지만 통합을 확인하고 싶을 수 있습니다.


내가 언급 한 Fogbugz / Assembla 질문은 Trac이 FogBugz보다 약간 뒤처 졌다는 것을 암시하는 것 같습니다. 또한 호스팅 된 프로젝트 토론의 아이디어가 마음에 듭니다 (필요한 경우 Google 그룹스를 확실히 사용할 수 있음).
— Jon Skeet

1

나는 어떤 곳에서 github와 google 코드를 사용합니다. Google 코드의 문제 추적기는 괜찮은 수준이지만 전복을 다룰 수는 없습니다.

이에 대한 예를 보려면 Java memcached 클라이언트 , 특히 상단의 소스 탭을 살펴보십시오.


멋있는. 정말 좋은 솔루션 인 것 같습니다. 나는 그것을 사용하고 싶은 사람들이 더 쉽게 할 수 있도록 Subversion에 복제 할 수 있습니다. 가능한 한 포괄적이기를 원합니다.
— Jon Skeet

2
나는 github의 다운로드 물건이 Subversion을 원하는 사람에게 충분하다고 생각합니다. svn repo에서 최신 버전을 다운로드하는 것보다 더 고급 작업을 수행하는 사람은 이미 git을 사용하고있을 것입니다. :)
— Dustin

1

직장에서 우리는 FogBugz를 사용하며 제 의견으로는 동급 최고의 도구입니다. 2 명의 사용자 이상으로 너무 비싸다는 점을 제외하고는 제가 작업하는 비영리 프로젝트에 사용할 것입니다.

비영리 프로젝트의 경우 문제 추적을 위해 Lighthouse 를 사용 합니다. 비용은 괜찮으며 솔직히 가격 범위 내에서 적합한 대안을 찾을 수 없습니다. Trac의 이슈 트래킹은 Bugzilla의 것보다 조금 낫습니다. 많은 사람들이 Trac을 좋아한다는 것을 알고 있지만 유연성이 매우 떨어집니다. Trac의 결점은 우리를 Lighthouse로 이끌었습니다.

내 비영리 프로젝트에서 Bitbucket으로 이동하려고 합니다. 이슈 트래킹 외에도 beanstalkapp.com의 저장소를 통합하고 위키를 추가 할 수 있습니다.

즉, FogBugz-on-Demand가 적은 사용자 수에 대해 Lighthouse.app과 원격으로 비슷한 가격을 책정했다면, 저는 우리를 심장 박동으로 이동시킬 것입니다. 직장에서 FB를 사용하고 밤에 Lighthouse.app을 사용하면 ... Lighthouse를 사용하면 팔이 잘린 것처럼 느껴집니다.



1

저도 Lighthouse와 함께 github를 사용합니다. 그리고 커밋 메시지에 다음과 같은 내용이 포함되어 있으면

[# 32 상태 : 해결됨]

Lighthouse는 커밋에 대해 티켓 # 32를 해결하므로 빠르고 유용합니다. 그 외에 Lighthouse는 기능에 약간의 빛이 있습니다.


0

JavaForge 는 당신이 찾는 모든 것을 가지고 있기 때문에 대안으로 제안하고 싶습니다 .

  • Mercurial 및 Git (또는 혼합)으로 무료 호스팅을 제공합니다 .
  • 이슈 트래커는 GitHub보다 광년 앞서 있습니다. 매우 강력하고 사용자 정의가 가능하며 요구 사항, 기능 요청, 버그, 작업 등을 추적 할 수 있습니다.
  • WebDAV 액세스 (공유 폴더처럼 쉽게 공유)와 함께 문서 관리를 제공합니다.
  • 문서, 요구 사항 등을위한 공동 작성을위한 내장 위키가 있습니다.
  • 토론을위한 포럼이 있습니다.

이 사이트는 글로벌 기업들에 의해 경쟁 테스트를 거친 상용 제품인 codeBeamer 에 의해 구동된다는 점에 유의하십시오 .

(면책 조항 : 당사는 민첩한 ALM 솔루션의 상업적 공급 업체입니다.)



0

BusyFlow 와 같은 도구를 사용해 볼 수도 있습니다 . 여기에서 GitHub 커밋을 추적하고 댓글을 달 수 있습니다 (댓글은 GitHub와 동기화 됨). 다른 프로젝트 관리 측면의 경우 BusyFlow는 Google 캘린더, Trello, Basecamp, Pivotal Tracker 등과 통합됩니다. 따라서 작업, 파일 및 캘린더 이벤트와 함께 GitHub 항목을 볼 수 있습니다.

(면책 조항 : 저는 BusyFlow의 공동 설립자입니다.)


-1

CodePlex를 고려해 보셨습니까?


1
나는 그렇지 않았지만 결국 나는 Google 코드 와 github를 사용하여 github에 대해 개발하고 적절한 경우 svn으로 푸시했습니다.
— Jon Skeet
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.