Bug tracking with Git

[kamocat]

I'm planning on using TortoiseGit with my programmers this year. I would have used Git last year, but I decided that they would take a long time learning how to use the command line interface. (It's not very intuitive)
So this year I'm planning on doing it with TortoiseGit.

I've never used bug tracking, but the revision control seems like it's missing something without that. Here's what I need:


Graphical interface (no command line neccessary)
Distributed (internet access need not be immidiately available)
Free
Easy to install (doesn't need to be compiled for Windows)


Here's what I'd like in addition to that:

No dependent packages (that aren't inclided with the installer)
Integrates with TortoiseGit



I've searched a bit, and found that most options don't meet my first four requirements, and I'm pretty sure there's no existing software that meets all of them.

Really, I don't need anything that's terribly complex. Perhaps the best (and easiest) method is just to make text documents in the appropriate folders. I'm not sure it would really matter if the documents had a standard naming format - they could be called ReadMe.txt or Notes.txt or Features.txt - they would still document intended features, and current bugs with those features, and they would be associated with the commits by the nature of revision control itself.

What would you suggest?

[Greg McKaskle]

I'm certainly not going to try and talk you out of using a more task-oriented tool, but for small teams and somewhat short-lived projects, Excel or another spreadsheet program works pretty well for bug and feature tracking.

Do what you can to avoid conflicts, but it is pretty trivial to diff.

Make your initial set of column headers match the fields you care about, and perhaps use sheets for a major topic (programmer names, or features vs bugs). Another nice feature is the flexibility with which you can sort or chart.

Greg McKaskle

[keehun]

Our team uses GitHub. The Git part of everything is still the same, like command line tools, tortoisegit, whatever, but GitHub has things like Wikis and Ticketing system that make ti very useful.

Our team was fortunate enough to get some GitHub love and get their dedication and donation.

[kamocat]

A spreadsheet is a great idea!
I was finding most trackers overly complex to use and install.
Is xls just tab-delimited text? I was thinking an advantage of something text-based is that it would diff and merge very well.


I do like the tracker on GitHub (I just tried it out Yesterday). However, it requires internet access, which we do not have at the regional, and I cannot guarantee it at school or people's houses.

[Radical Pi]

Is xls just tab-delimited text? I was thinking an advantage of something text-based is that it would diff and merge very well.

I believe xls is a binary format. csv (also native to excel) is probably what you want.

[kamocat]

Here's the columns I'm using for the CSV file:
Category, Files, Reported by, Description

I've left out time/date because I didn't see that as useful in this case.

Anything I should add?

EDIT:
I just realized I don't need the "Branch" column. Like revision hash, it will be determined by where it is in the revision history.

[Greg McKaskle]

This totally depends on your style of working, but we tend to have a status field -- bug reports tend to come in waves, and the programmer can't keep up. Status helps communicate to the team what should have been fixed already --report again if it still happens for you, but these aren't supposed to be fixed, so update their description if necessary, but don't file another bug report. This may have been what you were using category for.

Also, some bugs are more severe than others, we we tend to have a severity or impact field. This better allows the programmer to determine the priority for fixes (if you are only able to fix a few ...).

These and any other fields are less important if you have good communication, and more important if the person isn't right in front of you.

Greg McKaskle

[kamocat]

"status" and "severity" make sense. We'll always have the option to not fill in the field if we find it isn't important.