How does bug tracker/version control integration work with typical git workflows?

Trac and Redmine both support integration with Git. It looks more or less exactly the same as the Subversion support. The bug tracker follows one repo as the benevolent dictator repo, it doesn't have to care about all the other clones around the place.

One thing I do think is worth mentioning is that any bug tracker needs to support git branches properly. Working on branches is such an important part of the Git methodology, it needs to be supported in the bug tracker. Redmine can do this through a patch, but last I looked (about a month ago), it wasn't in the main source tree (you could only follow master).

Other useful features would be a graphical representation of how branches are created and merged, similar to how gitk looks. I don't know of any bug tracker that does this kind of visualisation.

EDIT by Corey Trager. I copy/pasted @Squelch's answer here (I upvoted @Squelch too):

Due to the distributed nature of Git against the centralized nature of SVN, it is quite possible for every user or copy of the repository to have different branches. The exisitnig trackers typically have a local copy of the repository that is used as a central reference ("benevolent dictator") that can be regarded as the working copy for all users.

It is quite feasible for users to have a different branch structure in their local copy from that of the tracker. They might choose to keep some private, pull only the branches from the remote that they are interested in, or push a new branch to the remote (tracker). Users can even share branches between themselves that the remote may never see.

The bug tracker can really only reference repositories it has access to. Commonly this is local to the tracker, but it is also possible to pull from repositories remote to the tracker, and far harder to manage. If it is accessing a remote, it can only track branches that it has knowledge of, and there is not really a method of initiating this task apart from a scheduled task. This also assumes that users are serving their local copy too.

As you have already noted, a scheduled task, or an event hook can be used to update the tracker using the commit log for details. These details can then be matched to the tracker issues for viewing as required and noted above.

In short, the tracker will typically see whatever changes are made on the branches it currently has access to. With a hook these changes are seen immediately including the creation of a new branch. It will not see or track changes made to users (offline) repositories until they push those changes.

END OF @Squelch

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 for 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 adds 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 registered 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.

To echo MichaelM's answer, Redmine has good Git integration. It follows the commit messages for keywords like references. fixes etc and a tracker number of the form #1234.

It is true that branch support isn't quite yet there, but it entered the trunk about a month ago, and is destined for version 0.9. Redmine is currently maintained in SVN, but there is also a mirror on Github

The link to Redmine trunk is indicative of the tracker output for Git repositories with the differences being how the branches are navigated.

$ git log

Can be used to parse commit messages, authors and revisions for use in any tracker if required.

Edit:Due to the distributed nature of Git against the centralized nature of SVN, it is quite possible for every user or copy of the repository to have different branches. The exisitnig trackers typically have a local copy of the repository that is used as a central reference ("benevolent dictator") that can be regarded as the working copy for all users.

It is quite feasible for users to have a different branch structure in their local copy from that of the tracker. They might choose to keep some private, pull only the branches from the remote that they are interested in, or push a new branch to the remote (tracker). Users can even share branches between themselves that the remote may never see.

The bug tracker can really only reference repositories it has access to. Commonly this is local to the tracker, but it is also possible to pull from repositories remote to the tracker, and far harder to manage. If it is accessing a remote, it can only track branches that it has knowledge of, and there is not really a method of initiating this task apart from a scheduled task. This also assumes that users are serving their local copy too.

As you have already noted, a scheduled task, or an event hook can be used to update the tracker using the commit log for details. These details can then be matched to the tracker issues for viewing as required and noted above.

In short, the tracker will typically see whatever changes are made on the branches it currently has access to. With a hook these changes are seen immediately including the creation of a new branch. It will not see or track changes made to users (offline) repositories until they push those changes.