15

以下是 git 工作流程的示例：

假设您想利用与版本控制系统的错误跟踪器集成。在哪里/如何适合这些工作流程。您实际上会在跟踪器中看到什么？

我是 BugTracker.NET 的作者，它与许多其他错误跟踪器（Trac、Redmine、FogBugz）一样与 svn 集成。我们都或多或少地以相同的方式做这件事。但是对于 git，我很难想象与 git 的集成会是什么样子。

编辑：我看过一次github-fogbugz集成的尝试，但即使是作者也说“很明显 FogBugz 是为更传统的 CVS/SVN SCM 系统编写的。因此，提交列表显示与 git 并没有真正的结合”。

EDIT2：关于Redmine/git 工作流程的线程：似乎最典型的设置是 Redmine 与被认为是“中央”存储库的本地克隆一起工作，因此当它们进入该克隆时它会看到更改。触发器或计划作业自动推送到 Redmine 的克隆。

EDIT3：似乎即使使用 linux 和 Linus，最终也有一个主要的 git 存储库，可以被认为是仁慈的独裁者存储库：参见http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6 .git;a=总结

结语：谢谢大家。根据你们给我的指导，我的BugTracker.NET现在包括 git 集成。

4

7 回答 7

8

Trac 和 Redmine 都支持与 Git 的集成。它看起来或多或少与 Subversion 支持完全相同。错误跟踪器遵循一个 repo 作为仁慈的独裁者repo，它不必关心这个地方的所有其他克隆。

我认为值得一提的是任何错误跟踪器都需要正确支持 git 分支。在分支上工作是 Git 方法的重要组成部分，它需要在错误跟踪器中得到支持。Redmine 可以通过一个补丁来做到这一点，但我上次查看（大约一个月前），它不在主源代码树中（你只能跟随 master）。

其他有用的功能将是如何创建和合并分支的图形表示，类似于 gitk 的外观。我不知道有任何错误跟踪器可以进行这种可视化。

由 Corey Trager 编辑。我在这里复制/粘贴了@Squelch 的答案（我也赞成@Squelch）：

由于 Git 的分布式特性与 SVN 的集中式特性相比，每个用户或存储库的副本很可能拥有不同的分支。现有跟踪器通常具有存储库的本地副本，用作中央参考（“仁慈的独裁者”），可以将其视为所有用户的工作副本。

用户在其本地副本中具有与跟踪器不同的分支结构是非常可行的。他们可能会选择保留一些私有内容，仅从远程提取他们感兴趣的分支，或者将新分支推送到远程（跟踪器）。用户甚至可以在他们自己之间共享远程可能永远看不到的分支。

错误跟踪器实际上只能引用它有权访问的存储库。通常这是跟踪器本地的，但也可以从远程存储库中提取到跟踪器，并且更难管理。如果它正在访问一个远程，它只能跟踪它所知道的分支，并且除了计划任务之外实际上没有启动此任务的方法。这也假设用户也在提供他们的本地副本。

正如您已经注意到的，计划任务或事件挂钩可用于使用提交日志更新跟踪器以获取详细信息。然后可以将这些详细信息与跟踪器问题相匹配，以便根据需要和上面提到的查看。

简而言之，跟踪器通常会看到它当前有权访问的分支上所做的任何更改。使用钩子可以立即看到这些更改，包括创建新分支。在用户推送这些更改之前，它不会查看或跟踪对用户（离线）存储库所做的更改。

@Squelch 结束

于 2009-09-28T07:54:35.670 回答
8

好问题。
要回答这个问题，您需要查看这两个工具（BugTracker.NET，很明显；）和Git，最初是在 2005 年为 Linux 开发的）实际上试图解决什么问题。

  • BugTracker.NET：基于 Web 的跟踪器，用于错误（或几乎任何您想要跟踪的“项目”，因为您可以定义自定义字段、状态和工作流程）
  • Git：本质上，它是一个补丁集成器，用于将来自很多人（并非所有人都知道或具有特定角色）的大量补丁应用到大量文件中。快点。

因此，您可以在这里看到中央引用和分布式代码聚合工具之间的不协调。

这两个模型之间最小的共同点仍然是“仁慈的独裁者工作流程”，这是最分布式的工作流程，仍然有一个中央存储库供您监控。

但是如果您遵循该路径（监控一个充当“官方参考”的存储库，同时在该存储库下方具有松散的分布式合并工作流程），那么您需要重新定义什么是用户及其角色。
尤其是在将 Git 与基于角色的集中式错误跟踪工具集成时。

如果您在 18 分 35 分左右观看Linus 在 Google 上对 Git 的介绍，您将了解到使用 Git 意味着没有识别所有用户并附加到一个角色的段落。

以下是一些说明这一事实的快速引用/要点：

  • “ 因为你有一个中央存储库，这意味着从事该项目的每个人都需要写入中央存储库。
    这意味着，由于您不希望每个人都向中央存储库写入数据，因为大多数人都是白痴，所以您创建了这类表面上不是白痴的人。”

因此，并不是每个人最终都会推送到中央存储库，而且那里的大部分实际工作（小修复、验证、测试......）无论如何都将由有限数量的人完成。

“仁慈的独裁者工作流程”意味着您与“信任网络”一起工作：一组选定的人。同样，并非所有开发人员都是直接可见的。

  • 从同一个演示文稿中，您还意识到“所有存储库”可以成为代码生命周期的一部分（与分支“集成”、“测试”、“待发布”或标签“release1.0 '，...）：

“商业公司的一件事：分布式模型也有助于发布过程。
您可以拥有一个拥有自己的树的验证团队。他们从人们那里提取并验证它，他们验证了它，他们可以将它推送给发布团队，然后说：“嘿。我们现在已经验证了我们的版本，开发人员，他们可以继续玩他们的脑袋, 而不是必须创建标签, 分支, 任何你试图让彼此远离脚趾的事情。
同样, 你让彼此远离脚趾因为每个单独的组都可以拥有自己的树, 并跟踪它的工作和他们想要做什么……”。

这强化了前一点：如果你只监控一个 repo，你只能监控有限数量的人的提交。
它增加了一个转折点：
虽然您无法监控所有的 repo，但您可能不想只监控一个 repo：如果错误跟踪重叠多个阶段（即“持续集成”、“功能测试”、“用户验证”、 'pre-production', ...)，他们每个人都可能有自己的树，并且每个人都是填写错误报告的潜在来源。
在这方面，“Redmine 的 Git 分支支持”（修订版 2840）仍然以“集中式回购”的心态制作，开发，而不是做一个实际的“开发工作”，这是一个分支应该做的）。

这一切让你何去何从？

  • 要么强加一个严格的中央存储库模型（每个人都必须推送到一个存储库），根据我的经验，当一个工具试图强迫你以一种方式工作而不是让你使工具适应你想要的工作方式时，这永远不会好.

  • 或重新定义错误生命周期管理以考虑：

    • 潜在的多棵树，每棵树都是解决错误的潜在步骤。
    • 将被注册为处理错误但没有完整代码历史记录的用户：即被监控的代码可能与他们没有直接关联，因为可以在开发人员存储库的私有分支中完成解析，而被监控的代码来自一个“集成商”在专用存储库上进行多次合并。
    • 智能报告能够告诉在代码的“官方修订版”中检测/修复了哪些错误，限制自己指出这些更改的起源（它来自此类远程分支的合并，对于此类远程仓库）

简而言之，这不是一项微不足道的任务。

问题依然存在：

  • Git 发布工作流程，包括仓库间（推/拉）以及仓库内（合并/变基）：您要跟踪哪些？
  • Git 私有分支：并非所有代码的历史都是可见的，也不应该被跟踪。只有公共分支（被拉/推，但也通过一些合并或变基在自己的仓库中修改）应该被跟踪
  • Git 用户：根据他们在“信任网络”中的位置，他们具有跟踪器需要反映的不同角色。
于 2009-10-10T21:39:14.777 回答
5

为了回应 MichaelM 的回答，Redmine 具有良好的 Git 集成。它遵循诸如引用之类的关键字的提交消息。修复等和 #1234 形式的跟踪器编号。

确实还没有分支支持，但它在大约一个月前进入了主干，并且注定是 0.9 版。Redmine目前在SVN中维护，但Github上也有镜像

指向 Redmine 主干的链接指示 Git 存储库的跟踪器输出，不同之处在于分支的导航方式。

$ git log

如果需要，可用于解析提交消息、作者和修订，以便在任何跟踪器中使用。

编辑： 由于 Git 的分布式特性与 SVN 的集中式特性相反，每个用户或存储库的副本很可能拥有不同的分支。现有跟踪器通常具有存储库的本地副本，该副本用作中央参考（“仁慈的独裁者”），可被视为所有用户的工作副本。

用户在其本地副本中具有与跟踪器不同的分支结构是非常可行的。他们可能会选择保留一些私有内容，仅从远程提取他们感兴趣的分支，或者将新分支推送到远程（跟踪器）。用户甚至可以在他们自己之间共享远程可能永远看不到的分支。

错误跟踪器实际上只能引用它有权访问的存储库。通常这是跟踪器本地的，但也可以从远程存储库中提取到跟踪器，并且更难管理。如果它正在访问一个远程，它只能跟踪它所知道的分支，并且除了计划任务之外实际上没有启动此任务的方法。这也假设用户也在提供他们的本地副本。

正如您已经注意到的，计划任务或事件挂钩可用于使用提交日志更新跟踪器以获取详细信息。然后可以将这些详细信息与跟踪器问题相匹配，以便根据需要和上面提到的查看。

简而言之，跟踪器通常会看到它当前有权访问的分支上所做的任何更改。使用钩子可以立即看到这些更改，包括创建新分支。在用户推送这些更改之前，它不会查看或跟踪对用户（离线）存储库所做的更改。

于 2009-09-28T11:26:58.780 回答
1

当然，在 GitHub 上还有一个与 Fogbugz的开源集成。

于 2009-09-28T07:58:04.743 回答
1

看看 Launchpad 是如何做到的：在不同的地方跟踪 bug 的状态。

下面我将引用Mark Shuttleworth的话：

真正的分布式错误跟踪（错误列表随处可见的代码）非常令人兴奋，并且可能是长期解决方案。在此期间，您可以通过在几个不同的地方跟踪错误的状态来解决它。Canonical 一直在资助 Bugzilla、Trac 和其他错误跟踪器的工作，以使其更容易以编程方式与它们交谈，以便我们可以让 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 订阅任何错误跟踪器（支持的类型）的任何错误报告。

集中式视图不是最终的解决方案，但它现在对我们有用，并且相当多的其他项目——上游和发行版——也在使用它。

于 2012-09-13T18:24:33.817 回答
0

Redmine 已经与 Git 集成并且它是开源的。也许你可以看看他们的整合想法。

于 2009-09-27T22:27:45.017 回答
0

也许我有点天真，但是 git 中的错误跟踪真的会比 svn 中的不同吗？系统使用的存储库将基本上具有与 subversion 相同的结构（分支和标签），对吗？

我可以想象你想要一个很好的图形表示分支如何交互，但除此之外......

于 2009-09-28T07:41:01.170 回答