Great Question.
For answering it, you need to look at what both of those tools (BugTracker.NET, which you know well, obviously ;) and Git, made initially by Linux in 2005) are actually trying to solve.
- BugTracker.NET: web-based tracker, for bug (or pretty much any other "item" you want to track, since you can define your custom fields, status and workflow)
- Git: at its core, it is a patch integrator, made to apply lots of patches from lots of people (not all of them known or with specific roles) to a large number of files. Quickly.
So you can see the dissonance here, between a central referential and a distributed code aggregation tool.
The lowest common denominator between those two model remain the "Benevolent dictator workflow", which is the most distributed workflow out there which still have a central repository for you to monitor.
But should you follow that path (monitor one repository acting as the "official referential", while having a loose distributed merge workflow below that one repo), you then need to re-define what is a user and its role.
Especially when it comes to integrate Git with your centralized role-based bug tracking tool.
If you watch Linus's presentation of Git at Google, around 18'35, you will get to the passage where you realize using Git means not having all the users identified and attached to a role.
Here is a couple of quick quotes/points that illustrate that fact:
- > “ Because you have a central repository means everybody who is working on that project needs to write to the central repository.
Which means that, since you don't want everybody to write to the central repository, because most people are morons, you create this class of people who are ostensibly not morons. ”
So, not everyone will end up pushing to the central repository, and most of the actual work there (small fixes, validations, testing, ...) will be done by a limited number of people anyway.
That "Benevolent dictator workflow" means you works with a "network of trust": a selected group of people. Again, not all the developers are directly visible.
- From the same presentation, what you also realize is that a "all repository" can be part of the lifecycle of the code (as opposed to branches 'integration', 'testing', 'to be released', or labels '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. And they pull from people and they verify it, and they verified it, they can push it to the release team, and say "Hey. We have now verified our version, and the development people, they can go on, playing with their head, instead of having to create tags, branches, whatever you do to try to keep off each other toes.
Again, you keep off each other toes by just every single group can have its own tree, and track its work and what they want done. ”.
That reinforce the previous point: if you monitor only one repo, you could only monitory commits from a limited number of people.
And it add a twist:
While you cannot monitor all the repos out there, you may not want to monitor only one repo: if the bug tracking overlap several phases (namely 'contrinous integration', 'functional testing', 'user validation', 'pre-production', ...), each of them potentially having their own tree, and each of them being a potential source for filling a bug report.
In that respect, the "Git branch support by Redmine" (Revision 2840) is still made with a "centralized repo" mindset, where you use a branch for a development lifecycle modelisation (where you do tasks about and around development, instead of doing an actual "development effort" which is what a branch should be all about).
Where does all that leave you?
either imposing a strict central repository model (everybody must push to one repo), which, in my experience, is never good when a tool try to force you to work one way instead of letting you adapt the tool to the way you want to work.
or redefining the bug lifecycle management to take into account:
- potentially multiple trees, each one a potential step in a bug resolution.
- users that will be register as working on a bug, but with no complete code history: i.e. the code monitored might not be directly associated with them, since the resolution can be done in private branches on developer's repositories, while the monitored code is made from multiple merges by one 'integrator' on dedicated repositories.
- intelligent reporting able to tell what bugs are detected/fixed in an "official revision" of the code, limiting themselves to point out the origin of those changes (it comes from the merges of such remote branches, for such remote repo)
In short, this is not a trivial task.
The issues remain:
- Git publication workflow, which is inter-repo (push/pull) as well as intra-repo (merge/rebase): which ones do you want to track?
- Git private branching: not all the history of the code will ever be visible, and should not be tracked. Only public branches (which are pulled/pushed, but also modified within their own repo by some merge or rebase) should be tracked
- Git users: according to their place within the "network of trust", they have different roles that the tracker needs to reflect.