以下是git工作流程的示例：
假设您希望利用bug跟踪器与版本控制系统集成。在哪里/如何适合这些工作流程。你会在追踪器中看到什么？
我是BugTracker.NET的作者，它与许多其他bug跟踪器（Trac，Redmine，FogBugz）一样与svn集成。我们都或多或少地以同样的方式做到这一点。但是使用git，我很难想象与git的集成是什么样的。
编辑：我已经看过github-fogbugz整合的一次尝试，但即使是作者也说“很明显，FogBugz是为更传统的CVS / SVN SCM系统而写的。这样，提交列表显示并不真正与git“。EDIT2：关于Redmine/git workflow的帖子： 似乎最典型的设置是Redmine使用被认为是“中央”存储库的本地克隆，因此当它们进入此克隆时会看到更改。触发器或预定作业自动推送到Redmine的克隆。
EDIT3：即使是Linux和Linus，最终还是有一个主要的git存储库，可以被认为是仁慈的独裁者存储库：见http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
EPILOGUE：谢谢大家。根据你们给我的指导，我的BugTracker.NET现在包括git整合。
答案 0 :(得分：8)
Trac和Redmine都支持与Git集成。它看起来或多或少与Subversion支持完全相同。错误跟踪器跟随一个回购作为仁慈的独裁者回购，它不必关心该地区周围的所有其他克隆。
我认为值得一提的是，任何bug跟踪器都需要正确支持git分支。在分支机构上工作是Git方法的重要组成部分，需要在bug跟踪器中得到支持。 Redmine可以通过补丁实现这一点，但最后我看了（大约一个月前），它不在主源树中（你只能跟随主人）。
其他有用的功能是如何创建和合并分支的图形表示，类似于gitk的外观。我不知道有任何bug跟踪器可以进行这种可视化。
Corey Trager的编辑。我在这里复制/粘贴了@Squelch的答案（我也赞成@Squelch）：
由于Git针对SVN的集中性质的分布式特性，存储库的每个用户或副本很可能具有不同的分支。 exisitnig跟踪器通常具有存储库的本地副本，该副本用作中央引用（“仁慈的独裁者”），可以被视为所有用户的工作副本。
用户在本地副本中具有与跟踪器不同的分支结构是完全可行的。他们可能会选择保留一些私有，只从他们感兴趣的遥控器中拉出分支，或者将新分支推送到远程（跟踪器）。用户甚至可以在他们之间共享远程可能永远不会看到的分支。
错误跟踪器实际上只能引用它有权访问的存储库。通常这是跟踪器本地的，但也可以从远程存储库拉到跟踪器，并且更难管理。如果它正在访问远程，它只能跟踪它知道的分支，并且除了计划任务之外，实际上没有启动此任务的方法。这也假设用户也在提供本地副本。
正如您已经注意到的，可以使用计划任务或事件挂钩来使用提交日志更新跟踪器以获取详细信息。然后，可以根据需要将这些详细信息与跟踪器问题进行匹配，并在上面进行说明。
简而言之，跟踪器通常会看到对当前有权访问的分支所做的任何更改。使用钩子，可以立即看到这些更改，包括创建新分支。在推送这些更改之前，它不会查看或跟踪对用户（离线）存储库所做的更改。
结束@Squelch
答案 1 :(得分：8)
答案 2 :(得分：5)
为了回应MichaelM的回答，Redmine有很好的Git集成。它遵循引用等关键字的提交消息。修复了＃1234表格的跟踪号码等。
分支支持确实不存在，但它进入了主干about a month ago，并且注定要使用0.9版本。 Redmine目前在SVN中维护，但也有mirror on Github
指向Redmine主干的链接表示Git存储库的跟踪器输出，不同之处在于分支的导航方式。
$ git log
可用于解析提交消息，作者和修订，以便在需要时在任何跟踪器中使用。
修改 由于Git针对SVN的集中性质的分布式特性，存储库的每个用户或副本很可能具有不同的分支。 exisitnig跟踪器通常具有存储库的本地副本，该副本用作中央引用（“仁慈的独裁者”），可以将其视为所有用户的工作副本。
用户在本地副本中具有与跟踪器不同的分支结构是完全可行的。他们可能会选择保留一些私有，只从他们感兴趣的遥控器中拉出分支，或者将新分支推送到远程（跟踪器）。用户甚至可以在他们之间共享远程可能永远不会看到的分支。
错误跟踪器实际上只能引用它有权访问的存储库。通常这是跟踪器本地的，但也可以从远程存储库拉到跟踪器，并且更难管理。如果它正在访问远程，它只能跟踪它知道的分支，并且除了计划任务之外，实际上没有启动此任务的方法。这也假设用户也在提供本地副本。
正如您已经注意到的，可以使用计划任务或事件挂钩来使用提交日志更新跟踪器以获取详细信息。然后，可以根据需要将这些详细信息与跟踪器问题进行匹配，并在上面进行说明。
简而言之，跟踪器通常会看到对当前有权访问的分支所做的任何更改。使用钩子，可以立即看到这些更改，包括创建新分支。在推送这些更改之前，它不会查看或跟踪对用户（离线）存储库所做的更改。
答案 3 :(得分：1)
当然，在GitHub上还有一个open source integration和Fogbugz。
答案 4 :(得分：1)
了解Launchpad如何做到这一点：跟踪不同地方的错误状态。
下面我会引用Mark Shuttleworth：
真正分布式错误跟踪（错误列表遵循代码 无处不在）非常令人兴奋，可能是长期解决方案。在 在此期间，您只需跟踪状态即可解决问题 在几个不同的地方的错误。 Canonical一直在资助工作 Bugzilla，Trac和其他bug跟踪器让它更容易交谈 它们以编程方式，以便我们可以让Ubuntu开发人员保持最新状态 自动。
我们在Launchpad中有一个“分布式错误状态的集中视图”， 这有助于我们跟踪上游问题的状态 Debian，或其他发行版。例如，看看这些错误：
https://bugs.launchpad.net/moblin-applets/+bug/209870
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/214041
https://bugs.launchpad.net/ubuntu/+source/tuxmath/+bug/220319
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/123920
https://bugs.launchpad.net/ubuntu/+source/warsow/+bug/131582在每种情况下，您都可以看到错误如何与其他报告相关联 错误跟踪器，然后状态自动更新。作为一个小 结果，您可以订阅任何错误跟踪器的任何错误报告 （通过LP支持的类型）。
集中视图不是最终解决方案，但它适用于我们 现在和其他一些项目 - 上游和分发 - 也正在使用它。
答案 5 :(得分：0)
Redmine已经与Git集成了它的开源。也许你可以看看他们对想法的整合。
答案 6 :(得分：0)
也许我有点幼稚，但是跟踪错误跟git在sit中真的不同吗？系统使用的存储库基本上具有与subversion相同的结构（分支和标签），对吧？
我可以想象你想要一个很好的图形表示分支如何交互，但除此之外...