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.
- 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.
- 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.
For me, unfortunately the disadvantages don’t outweight the advantages, 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.
If you do decide to use it, this is what I did to set it up:
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.
- 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.
Always rebase when pulling:
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
--notes) argument to supply it from the command line: