Question

Using Git at home has spoiled me - I now find using TFS at work to be a bit of a drag and want to explore the possibility of using Git locally and syncing somehow with TFS. I figure there are a few different ways this can be done and would like to hear from people that have attempted it.

I ve found a blog post that describes a relatively manual workflow, but I m hoping for something with better automation, and history support.

Jim Deville appears to be writing a series on how the IronRuby team keeps their github repository in sync with TFS but it is not yet complete and I must admit I had a little trouble following what Jim has written so far.

I briefly attempted to use a combination of SvnBridge and git-svn but I got stuck on an error quite quickly (perhaps this one?). I do intend to explore this further...

Update: It looks like some people have had some success with the SvnBridge git-svn combo. See here.

Finally, perhaps GitSharp will make it easier to develop a useful solution to this problem? Not because GitSharp has anything to do with TFS per se, but simply because it exposes git automation to .NET developers.

Related Question - Git and Team Foundation Server

Answer 1

Microsoft has finally released their own bridge solution: Git-TF. It uses Java, so it works in Windows, OSX, and Linux.

Edit: As of 2013-01-30, Microsoft is announcing even more integration between TFS and Git, to address precisely your situation. It will be made available via updates to the 2012 versions of TFS and Visual Studio.

Answer 2

There s the open source project Git-tfs (not to be confused with Git-tf):

https://github.com/spraints/git-tfs

Answer 3

Working with a superior version control system won t only have a positive effect on you; it will have a positive effect on your whole team. There might be resistance to start, but in the long run, the benefits that you see will likely be seen by the rest of the team.

Make a simple proposal to convert your "TFS shop" to something new. You will find three kinds of people aside from yourself:

those that are willing to try your proposal, because it gives them an opportunity to learn something new.
those that have already tried your proposal (and I mean actually tried), but disagree with you
those that reject your proposal because they don t want to learn something new

The first two are the kinds of people that you want to keep close, regardless of whether you agree with them or not. The last type of person is not only a negative influence on the team as a whole, but is also someone who you should distance yourself from.

Disclaimer: I know this doesn t answer the question directly, but I think it s a good approach to take whenever you think a technology change is warranted.

Aside: Whenever you find yourself calling your team a "TFS shop," "Java shop," "Windows shop," etc, an alarm should go off in your head. This is a huge red flag. Different technologies are good for different kinds of tasks and pigeonholing a team is detrimental.

Answer 4

I worked with Jim Deville on the "TFGit" tool that bridges TFS and Git (I started the project, actually). It is highly automated, preserving author, date information, and history. It s most substantial weakness is that while it lets git devs play with branches to their hearts content, it can only synchronize to one branch on the TFS side. Nevertheless it s a fairly painless tool to use and Jim and I use it regularly.

It s currently an internal tool for our company, and we haven t investigated making it public. If there s substantial interest in it, we can investigate doing that.

友情链接