Using git-tfs in anger


31 August 2016, by

A while ago I wrote about how no-one should ever user TFS, ever. While I was unfortunately forced to use it I experimented with git-tfs to see if it would ease my pain, and this is what I found.
Why git-tfs
It seems to be the main git-to-tfs-bridge right now. There’s another option, git-tf, but that one hasn’t been updated since 2013. git-tfs appears to be an active project.

The Good

  • Local version control: local commits and local branches. Proper branches (not TFS folder-branches) which are lightning-fast to switch between, and you can cherry-pick between.
  • Rebase temporary dev branches back onto master instead of clumsily re-applying old shelvesets.
  • If more than one person is using it, push and pull git branches between yourselves, and keep developing even when the central TFS server (inevitably) goes down.
  • Separate source control from Visual Studio: generally a good idea in my opinion, and particularly useful if VS is already running slowly.
  • Reliable version control: TFS get-latest is a bit buggy, but git-TFS seemd to work reliably. Perhaps it abstracts away for you the tedium of always telling TFS explicitly to get the latest version of all files, not just some.

The Bad

  • You can only checkout one directory at a time so you need separate checkouts for different root-level projects in the same repo. This is pretty minor though.
  • Visual Studio gets a bit confused and integration isn’t as good. Keep it happy by using msys git (git for windows) not cygwin git if you can.
  • Changing between TFS and git-tfs, or just using visual studio with a git-tfs checkout, leads to corrupt TFS workspaces.
  • Doing things differently from the rest of the team means you lose out on their TFS knowledge and support, for what it’s worth.
  • You won’t be able to add projects to the solution properly.
  • Visual Studio will constantly try to remove the tfs element from the .sln file, which will break TFS integration for everyone else if you commit it.
  • If you need to keep local changes, e.g. for local environment config, then it’s a pain to stash the changes all the time (you need a clean checkout to rebase).
  • It’s just really slow – mainly because my team’s TFS server was slow; but git-tfs was even slower.

Verdict

For me, unfortunately the advantages don’t outweigh the disadvantages, and I probably wouldn’t use it again. it’s a bit of a pain to set it up and to use different tools to the rest of the team. On my next TFS project (and I’ll do everything in my power to make sure there won’t be one) I’ll just embrace the shelveset workflow instead.

What I might try is just to git init a local repo in my TFS checkout and get local branching that way, adding the .git folder etc to the local ignore list, although it might lead to some manual effort keeping branches in sync with the remote.

Setting up

If you do decide to use it, this is what I did to set it up:

    1. Install git, and configure it:
$ git config --global core.autocrlf true # see https://help.github.com/articles/dealing-with-line-endings/
$ git config --global core.filemode false
    1. Install git-tfs: http://git-tfs.com/
    2. Clone the repo:
$ git tfs clone http://tfs:8080/tfs/DefaultCollection $/some_project -c XXX

Where XXX is a recent changeset – you’ll only have history available from this changeset, but the further back you go the longer the clone will take.

  1. Open in Visual Studio!

Don’t bother to un-map your workspace: the Visual Studio TFS integration will go away when you open your new “git” project. And it will be easier to go back to pure TFS if you want to.

Everyday Use

Always rebase when pulling:
$ git tfs pull --rebase

To map local commits to checkins one to one, use rcheckin instead of checkin or checkintool.

$ git tfs rcheckin --no-merge

Be careful though, this makes a number of commits in a row, and because TFS is so sloooow the can be nearly a minute apart and trigger more than one consecutive CI build. If the build time is slow this might hold other people up from committing, so keep an eye on it: you can always cancel the first build(s) if this happens. You might just want to squash up the commits to save time committing!

If your project requires certain custom notes fields to be supplied, use the -n (--notes) argument to supply it from the command line:

$ git tfs rcheckin --no-merge -n 'JiraNumber' 'AA-123'

Tags: , ,

Categories: Technical

«
»

Leave a Reply

* Mandatory fields


2 × = six

Submit Comment