Associating git commits with Team Foundation work items

Question

Context

A GitHub Enterprise installation used for development. Every developer has his own public repo, and the organization has the authorative repo. Pull requests are used for code reviews, and we loosely follow nvie's git flow branching model.

A TFS installation used for issue tracking and deployment (the release branch). We mirror the release branch into a TFS repo.

Work Items

Now the hard part is: How do we associate git commits (that may originally be done on the public branches of the developers) with TF work items?

What I did

I've looked at the following projects for help:

• Git-TFS
• Git-TF (nodirt)
• Git-TF (microsoft)

I've read references to associating commits with work item in both Git-TF projects, but I am unsure what tool to use, and how to go about it exactly.

I would be fine if I had to run a script on the release branch commits to extract work item references from the commit message and associate them with changesets sent to TFS. However, a solution that allows the association in metadata (instead of commit messages) would be preferred.

What are my options to associate work items in TFS with git commits?

Answer 1

If you use # in your git commit message as in git commit -m'fixes #123' TFS will automatically add the commit as a linked item in workitem specified.

Answer 2

With git-tfs, you can associate workitems in a commit message using metadatas (and even force commit policy!).

They are automaticaly associated when the commit are done in the TFS server ( if you use the rcheckin command )

And there is even a git-note created on the git commit to have the title of the workitem and a link toward the workitem!

But to use rcheckin in a synchronisation process between git and TFS, you should before (abolutely) understand how it works!

When you rcheckin git commits in TFS, git-tfs, for each commit create the corresponding changeset in tfs and fetch the content of this changeset to recreate a git commit. So, even if it's (nearly) invisible for you in a normal worklow, you have the git commits after the rcheckin that are not the same than the original ones (there is a modification of the history!).

That could be a big problem if this git reporitory is supposted to be the central repository because every commiters will have to do a rebase. Otherwise, it shouldn't be a problem because it's completly transparent, except in special cases but easily solvable.

Not a perfect solution...