Using Git in a TFS shop

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 - http://stackoverflow.com/questions/614245/git-and-team-foundation-server

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.

I use the term 'TFS shop' because we use TFS for source control, bug tracking, and build management among other things. This is not a red flag - we are talking about core software development functions where stability is vital. I find your suggestion naive, because it makes no mention of analyzing the risk and potential return on investment offered by replacing one source control system with another. Right now I think the risks outweigh the rewards.

Paul Batum 2009-11-16 10:19:12

I also have reservations regarding your aside on 'shops'. It is a simple fact that many software development shops specialize by targeting a specific platform or industry. In general, Java and .NET provide very similar facilities and it could be dangerous for a relatively small software shop (~ 40 staff) to dilute its skill set by targeting multiple development platforms. I never said it in my original post, but my employer IS a .NET shop, and I contend that it is not detrimental to use this terminology.

Paul Batum 2009-11-16 10:35:37

Sorry, it sounds like my advice a struck a nerve. That wasn't my intention. You expressed a desire to use _better_ tools in your workplace (assumed by your use of the word _"spoiled"_). There's no naivety in the suggestion because I recommended offering a _proposal_ for change which by definition should analyze risk and reward. If a proposal to switch technologies can't offer enough reward over the long haul for your shop, how can you justify a monkey-rigged Git<->TFS solution working for just yourself?

Ryan McGeary 2009-11-16 15:29:29

Its the difference between rewriting a core component in a system and developing a facade to make that component easier to work with. If you try to change the core component, you potentially have to change all the other components it is coupled to. Using a facade avoids those problems - its a low-cost means of easing pain.

Paul Batum 2009-11-17 00:24:07

Also, what are your thoughts on the existence of git-svn? In my opinion it would have been a real shame if the developers had decided that there was no point in writing git-svn because it would be better to just tell everyone to switch to git.

Paul Batum 2009-11-17 00:31:56

git-svn is a a great thing, but it should only be used as a temporary solution or for one-offs. It was also a smart and necessary marketing ploy to make it easy to switch to git from svn (the prominent VCS). If you write a git-tfs and make it widely available, that's one thing; otherwise it's a waste of time and resources for just one shop.

Ryan McGeary 2009-11-17 14:46:08

Agreed. If I end up writing some sort of git-tfs (which seems unlikely at this point), surely it would be on my own time. There is no way I could justify doing it on my employers time.

Paul Batum 2009-11-18 03:05:54

ansaurus

tags:

views:

answers:

Using Git in a TFS shop

related questions