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

Answer 2

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.