git 使用 GitHub 进行项目管理

Project management to go with GitHub

提问by Jon Skeet

(EDIT: This question is now outdated for my particular issue, as Google Code supports git now and I've converted Protocol Buffers to Mercurial anyway. However, it's still of general interest, IMO.)

（编辑：对于我的特定问题，这个问题现在已经过时了，因为 Google 代码现在支持 git，无论如何我已经将协议缓冲区转换为 Mercurial。但是，IMO 仍然普遍感兴趣。）

My C# Protocol Buffers Portuses github for its source control, and I'm beginning to really enjoy using git. However, as far as I can tell, github doesn't provide any project management tools: defect and feature tracking, discussions, feature requests, docs etc. Given my affiliations, Google Codewould be a natural choice, but it would seem odd to create a project there but host the source on github.

我的C# Protocol Buffers Port使用 github 进行源代码控制，我开始真正喜欢使用 git。但是，据我所知，github 不提供任何项目管理工具：缺陷和功能跟踪、讨论、功能请求、文档等。鉴于我的从属关系，Google Code将是一个自然的选择，但似乎很奇怪在那里创建一个项目，但在 github 上托管源代码。

This question about Fogbugz/Assemblaseems to mostly focus on the defect tracking. I was wondering what experiences others have had when it comes to a more "complete" project management solution. Does Fogbugz actually do everything I need? (Using a wiki for docs has its advantages, although I also want to be able to distribute documentation with the code.) Beyond the explicit features mentioned in the first paragraph, are there other project aspects I shouldbe considering which I may have missed?

这个关于 Fogbugz/Assembla 的问题似乎主要集中在缺陷跟踪上。我想知道其他人在更“完整”的项目管理解决方案方面有什么经验。Fogbugz 真的能做我需要的一切吗？（将 wiki 用于文档有其优势，尽管我也希望能够将文档与代码一起分发。）除了第一段中提到的明确功能之外，还有其他项目方面我应该考虑哪些我可能遗漏了？

This will definitely stay an open source project, and although I'd rather not pay I don't mind if a small fee is required. Currently I'm the only developer, but that may change and there may very well be lots of people filing bugs and feature requests. (In other words, I hope and expect it to be popular, but with me doing most of the work.)

这肯定会是一个开源项目，虽然我宁愿不付钱，但我不介意是否需要少量费用。目前我是唯一的开发人员，但这可能会改变，很可能会有很多人提交错误和功能请求。（换句话说，我希望并期望它很受欢迎，但大部分工作都是由我完成的。）

Previously I've contributedto various open source projects, but haven't done much in the way of running a very visible and active one. (MiscUtilis currently still "hosted" on my website, with occasional releases - the actual source control is on my local NAS.)

以前，我为各种开源项目做出了贡献，但在运行一个非常明显和活跃的项目方面做得并不多。（MiscUtil目前仍“托管”在我的网站上，偶尔会发布——实际的源代码控制在我的本地 NAS 上。）

Anyone care to share their experiences?

有人愿意分享他们的经验吗？

EDIT: Another option I'm now considering is a Google Code project (I really would like to be loyal to my employer) and an occasional merge from git to svn (at the very least, every time I do a release). This would allow non-git users to get hold of the source easily too.

编辑：我现在正在考虑的另一个选择是 Google Code 项目（我真的很想忠于我的雇主）和偶尔从 git 合并到 svn（至少，每次我发布时）。这也将允许非 git 用户轻松获取源代码。

采纳答案by Paul

If you're thinking that you'll really be the only developer, Fogbugz will help you keep your sanity. Fogbugz is a great product, It builds focused communications and can turn anything into a case (issue). It does all that as well as any system I've seen.

如果您认为自己真的是唯一的开发人员，Fogbugz 将帮助您保持理智。Fogbugz 是一个很棒的产品，它建立了有针对性的沟通，并且可以将任何事情变成一个案例（问题）。它和我见过的任何系统一样可以做到这一切。

But its orientation is commercial -- efficient communication between users and tech support, improve reliability of schedules, focus & prioritize what's being worked on, separate internal & external discussions, some good reporting to track that things are getting handled. (About the only criticism I can think of is it doesn't do case blocking and dependency tracking, which is really useful for those bugs buried deep.)

但它的定位是商业性的——用户和技术支持之间的有效沟通，提高日程安排的可靠性，关注和优先处理正在处理的事情，分开内部和外部讨论，一些很好的报告来跟踪事情的处理情况。（关于我能想到的唯一批评是它没有进行案例阻塞和依赖跟踪，这对于那些深埋的错误非常有用。）

Little of this feature set will help you build an active open source project, with open lively communication and the need build a community and have users evolve into developers as the project grows. So if that's where you want to end up, you may really want the less focused communication channels of one of these lightweight tracking systems.

此功能集的一小部分将帮助您构建一个活跃的开源项目，通过开放活泼的交流和构建社区的需求，并随着项目的发展让用户发展成为开发人员。因此，如果这就是您想要结束的地方，您可能真的想要这些轻量级跟踪系统之一的不太集中的通信渠道。

I haven't used Google Code on a project yet, but in terms of transparent & open communication, it looks like a good support for an active open source project. Plus you already know it. If you want to grow the involvement in your project, Google code looks like the way to go.

我还没有在项目中使用过 Google Code，但就透明和开放的交流而言，它似乎对活跃的开源项目提供了很好的支持。另外你已经知道了。如果你想增加对项目的参与度，谷歌代码看起来是个不错的选择。

回答by Greg Campbell

GitHub recently introduced an issue trackerof their own; I haven't done a competitive analysis to determine how it measures up to other options mentioned on this thread, though.

GitHub 最近推出了他们自己的问题跟踪器；不过，我还没有进行竞争分析来确定它如何衡量该线程中提到的其他选项。

回答by Marc Charbonneau

I use GitHub along with Lighthousefor issue tracking. It's a little barebones compared to some of the other options, but at the same time it works very well if you just want a lightweight tool you don't have to worry too much about. It can integrate with GitHub if you want, and it's also free for open source projects.

我使用 GitHub 和Lighthouse进行问题跟踪。与其他一些选项相比，它有点准系统，但同时，如果您只想要一个轻量级的工具，而不必担心太多，它也能很好地工作。如果您愿意，它可以与 GitHub 集成，并且对于开源项目也是免费的。

回答by Keltia

As usual when someone ask this, I mention Redmineas I did in thisquestion. I know the question has already its "best answer" but I think it is worth mentioning.

像往常一样，当有人问这个问题时，我会在这个问题中提到Redmine。我知道这个问题已经有了“最佳答案”，但我认为值得一提。

回答by Ali Afshar

We use bitbucket.org, which is not GIT, it's Mercurial* , but it does have bug/issue tracking per branch etc.

我们使用bitbucket.org，它不是 GIT，它是 Mercurial* ，但它确实有每个分支的错误/问题跟踪等。

I think it can be very useful to integrate these things with the place you manage your source code for cross-referencing things like issue-number in a commit message. Or Fixed message for an issue containing the code revision number. You would lose this if you chose a separate BTS like Google code. As mentioned in other answer, Trac is really good at the integration thing.

我认为将这些内容与您管理源代码的位置集成在一起以交叉引用提交消息中的问题编号等内容非常有用。或包含代码修订号的问题的已修复消息。如果您选择像 Google 代码这样的单独 BTS，您将失去这一点。正如其他答案中提到的，Trac 非常擅长集成。

Edit: I should say that for my most widely used open source project, we do actually have it at:

编辑：我应该说，对于我使用最广泛的开源项目，我们确实在：

1. Bitbucket (source code management)
2. Launchpad (user bug reporting, translations management)
3. Self hosted Trac (wiki, project and developer issue tracking, source code mirror)
4. Google code (file downloads)

1. Bitbucket（源代码管理）
2. Launchpad（用户错误报告、翻译管理）
3. 自托管 Trac（wiki、项目和开发人员问题跟踪、源代码镜像）
4. 谷歌代码（文件下载）

And I know this sounds insane, but we pick and choose the best bits out of each service. And surprisingly no one complains.

我知道这听起来很疯狂，但我们从每项服务中挑选最好的部分。令人惊讶的是，没有人抱怨。

*which is better in my opinion anyway, but please don't flame me.

*无论如何，这在我看来更好，但请不要喷我。

回答by VonC

Have you considered Trac?

你考虑过Trac吗？

There seems to be an "enthusiastic" review of a git-Trac integration.

似乎有对git-Trac 集成的“热情”评论。

I have no personal experience with these tools but you may want to check out the integration.

我没有使用这些工具的个人经验，但您可能想查看集成。

回答by Dustin

I use github and google code in some places. Google code's issue tracker is decent enough, but I can't deal with subversion.

我在某些地方使用 github 和 google 代码。谷歌代码的问题跟踪器足够好，但我无法处理颠覆。

Take a look at my java memcached clientfor an example of this -- particularly the source tab at the top.

看看我的java memcached 客户端的一个例子——特别是顶部的源选项卡。

回答by jasonjwwilliams

At work we use FogBugz and it's by far the best tool of its type in my opinion. I would use it for the non-profit projects I work on, except it's so expensive beyond 2 users.

在工作中，我们使用 FogBugz，在我看来，它是迄今为止同类产品中最好的工具。我会将它用于我从事的非营利项目，除非它在超过 2 个用户的情况下非常昂贵。

For the non-profit projects, we use Lighthousefor issue tracking. It's alright for what it costs, and frankly I can't really find any suitable alternatives within its price range. Trac's issue tracking is little better than Bugzilla's...I know a lot of folks love Trac but I find it very inflexible. Trac's deficiencies led us to Lighthouse.

对于非盈利项目，我们使用Lighthouse进行问题跟踪。它的成本是可以的，坦率地说，我在它的价格范围内真的找不到任何合适的替代品。Trac 的问题跟踪比 Bugzilla 好一点……我知道很多人喜欢 Trac，但我发现它非常不灵活。Trac 的不足使我们找到了 Lighthouse。

My non-profit projects are looking possibly at moving to Bitbucket. In addition to the issue tracking, it would let us consolidate our repositories over there from beanstalkapp.com, as well as, adding a wiki.

我的非营利项目正在考虑迁移到Bitbucket。除了问题跟踪之外，它还可以让我们从 beanstalkapp.com 那里整合我们的存储库，并添加一个 wiki。

That all being said, if FogBugz-on-Demand had pricing even remotely similar to Lighthouse.app for small user counts, I'd move us over there in a heartbeat. When you use FB at work and then Lighthouse.app at night...using Lighthouse feels like your arm has been chopped off.

话虽如此，如果 FogBugz-on-Demand 的定价甚至与 Lighthouse.app 的小用户数量相似，我会立即将我们转移到那里。当您在工作时使用 FB，然后在晚上使用 Lighthouse.app 时……使用 Lighthouse 感觉就像您的手臂被砍断了一样。

回答by Antti Tarvainen

Minglesupports git via mingle_gitplugin. Mingle has a free community licensefor open source projects.

Mingle通过mingle_git插件支持git 。Mingle 拥有开源项目的免费社区许可证。

回答by kevinrutherford

I too use github with Lighthouse. And if your commit message contains something like

我也将 github 与 Lighthouse 一起使用。如果您的提交消息包含类似的内容

[#32 state:resolved]

[#32 状态：已解决]

Lighthouse will resolve ticket #32 against the commit, which I find quick and useful. Other than that, Lighthouse is a bit, er, light on features.

Lighthouse 将针对提交解决票证 #32，我认为这快速且有用。除此之外，Lighthouse 有点，呃，功能上的不足。