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

Question

Here's are examples of git workflows:

• https://github.com/bard/sameplace/wiki/typical-git-workflow
• http://www.nabble.com/Git-workflow-overview-td16340337.html
• http://osteele.com/archives/2008/05/my-git-workflow

Let's say you wanted to take advantage of bug tracker integration with your version control system. Where/how would that fit into these workflows. What would you actually see in the tracker?

I'm the author of BugTracker.NET which like many other bug trackers (Trac, Redmine, FogBugz) integrates with svn. We all do it more or less the same way. But with git, I have trouble imagining what integration with git would look like.

EDIT: I've taken a look at one attempt at github-fogbugz integration, but even the author of that says "It's fairly obvious that FogBugz was written for a more traditional CVS/SVN SCM system in mind. As such, the commit list display doesn't really jive with git".

EDIT2: A thread about Redmine/git workflow: It seems that the most typical setup is that Redmine works with a local clone of whatever is considered to be the "central" repository, so it sees changes when they make it to this clone. Triggers or scheduled jobs automate the pushing to Redmine's clone.

EDIT3: Seems even with linux and Linus, there ultimately IS a main git repository that could be considered the benevolent dictator repository: See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary

EPILOGUE: Thanks everybody. My BugTracker.NET now includes git integration, according to the guidance you folks gave me.

Answer 1

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