很好的问题。
要回答它，你需要看看这两个工具（BugTracker.NET，显然你很熟悉它;) 和 Git，最初是为 Linux 开发的）实际上试图解决什么问题。
- BugTracker.NET：基于 Web 的跟踪器，用于跟踪错误（或几乎任何其他您想要跟踪的“项目”，因为您可以定义自定义字段、状态和工作流程）
- Git：本质上是一个补丁集成器，旨在快速应用来自许多人（其中并非所有人都知道或具有特定角色）的大量补丁到大量文件中。
因此，您可以看到这里的不协调之处，在于中央参考和分布式代码聚合工具之间。
这两种模型之间的最低公共分母仍然是“仁慈的独裁者工作流”，这是目前最分散的工作流，但仍有一个中央存储库供您监视。
但是，如果你遵循这条路径（监控一个仓库作为“官方参考”，同时在该仓库下具有松散的分布式合并工作流），那么你需要重新定义用户及其角色。特别是当涉及将Git与你的集中式基于角色的缺陷跟踪工具集成时。
如果你观看
Linus在Google上关于Git的演讲，大约在18'35处，你会发现使用Git意味着不需要将
所有用户标识和附加到角色。
以下是一些快速引用/要点，说明了这个事实：
“因为你有一个中央仓库，意味着每个在该项目上工作的人都需要写入中央仓库。这意味着，由于你不希望每个人都写入中央仓库，因为大多数人都是白痴，所以你创建了这个看似不是白痴的人类。”
因此，并不是每个人最终都会推送到中央仓库，而且大部分实际工作（小修复、验证、测试等）都将由有限数量的人完成。
"That 'Benevolent dictator workflow' means that you work with a 'network of trust': a selected group of people. Not all developers are directly visible.
From the same presentation, you also realize that an 'all repository' can be part of the code's lifecycle (as opposed to branches such as 'integration', 'testing', 'to be released', or labels such as 'release1.0'):
'One of the things for commercial companies: the distributed model also helps with the release process. You can have a verification team that has its own tree. They pull from people and verify it. Once they have verified their version, they can push it to the release team and say "Hey. We have now verified our version." The development team can continue working without having to create tags, branches, or any other measures to avoid stepping on each other's toes. Each group can have its own tree and track its work and what they want done.'"
那就强调了之前的观点：如果你只监控一个仓库，你只能监控有限数量人的提交。
并且它增加了一个曲折：
虽然你不能监控所有的仓库，但你可能不想只监控一个仓库：如果错误跟踪涵盖了几个阶段（即“连续集成”，“功能测试”，“用户验证”，“预生产”等），每个阶段都有可能拥有自己的代码树，并且每个阶段都可能是填写错误报告的潜在来源。
在这方面，“Redmine的Git分支支持”（
修订版2840）仍然采用“集中式仓库”的思路，其中使用分支进行开发生命周期建模（你在做与开发相关的任务，而不是实际的“开发工作”，这才是分支应该关注的）。
那么，这一切对你意味着什么？
简而言之，这不是一项简单的任务。
问题仍然存在：
Git发布工作流程，既可以是跨库的(push/pull)，也可以是同一库内的合并/变基(merge/rebase)：您想要跟踪哪些内容？
Git私有分支：不应跟踪代码的所有历史记录，只应跟踪公共分支（这些分支被拉取/推送，但也通过某些合并或变基在其自己的存储库中进行修改）。
Git用户：根据他们在“信任网络”中的位置，他们具有不同的角色，跟踪器需要反映这些角色。
