Tag Archives: Git


I don’t think it matters, any tool you use will create a bunch of support files for whatever reason it has. Settings, tracking, state… There is always something. Especially if working with Visual Studio and Git-TF or Git-TFS, make sure your .gitignore file is in order. Realizing what that means, you probably do not want to write your own, so there is one created for almost all environments.

.gitignore on GitHub saves your life.

Update: I got a tips on an additional gitignore resource called GitIgnore.io which generates .gitignore files according to your spec. Perhaps you need to include both Windows and OS X and several editors? This is the tool for you! Thanks @sodper.

Tagged ,

Git-TF vs Git-TFS

TLDR; While both offers a bridge to TFS they do it slightly differently. Git-TF is the only choice if you plan cross platform use. Git-TFS is written for Windows and on top of the TFS-SDK. More on these differences here on StackOverflow. After that their biggest difference is in how they make use of branches and checkins. While Git-TFS can respect and sync a branch-tree from TFS, that is not possible in Git-TF. On the other hand Git-TF provides the –deep option which makes each commit a TFS checkin aswell, which I haven’t found in Git-TFS.

Cross platform

If your need is cross platform, then you don’t really have a choice, Git-TF is the only way to go. Built on Java it runs pretty much anywhere. Git-TFS is built on top of the TFS SDK, which means nearly Windows only. Saying nearly, because I’m unsure weather or not it can run under Mono but I’m guessing not.


Because Git-TFS is built on the TFS SDK it has very nice performance. Connections are quick and swift. Git-TF is notably slower, especially when connecting. Though, in my opinion, it is still not slow enough to be disturbing.


Branching is one of the main differences between the two. Still being quite a n00b in the Git space, but learning, I get the feeling Git-TF respects the Git-way of working with branches more. Not that Git-TFS hinders you to do anything, more that it uses some automagic I’m not comfortable with.
In Git-TF you always push your changes, as well as pull, from the master branch, there is no other way. This also encourages you to keep the master-branch clean if something else comes up.
In Git-TFS you can push from any local git branch. It then also automatically downloads anything from TFS you do not currently have, and merges it in. Git-TFS can also keep your TFS branch tree in sync and keep track of it, which is not available to my knowledge in Git-TF. This is done with the --with-branches flag.

TFS checkins

This is the other point where they really differ from each other. In Git-TF you can use the --deep option to make each commit a checkin in TFS. While this is very nice and preserves all history between the two systems, it does put some contraints on how you work. If you have gated checkins activated on your TFS project, this will not work. Either you have to use --shallow which takes all commits and makes a single TFS checkin, or --deep --bypass which bypasses the gated checkin. This may not be what you want.
Git-TFS on the other hand does not have any option to make each commit a checkin in TFS. But it does have a nice checkin-tool (git tfs checkintool) which takes all your commits and builds a massive (depending on number of commits) comment of all your commit messages since last push. Git-TFS does not have any trouble with gated checkins, I’m guessing this is due to all commits are checked in as a single checkin instead of preserving them. The problem probably being that it would be hard to tell the user everything happening with a gated checkin on every single commit.

Further reading

Tagged ,

Getting started with Git for the TFS dev (and quick reference)

This post is aimed at those totally inexperienced with Git and what it is. So it is very basic, but also covers some useful tips and tricks I’ve picked up along the way.

Git(Hub) vs TFS (pre 2013)

The significant difference between Git and TFS to begin with is that Git is a version control system while TFS is mainly a central code repository system with some version abilities. Then there is GitHub which is a code repository running on Git. The following will not cover GitHub.

The tools

Since I want to lower the bar for trying all this out I will not point you to a bunch of websites and tell you the order to install things. Just use Chocolatey! If you haven’t used it before, just run the command on the frontpage and you are set.
After that you need Git, so run: cinst git
And then, you probably want Git-TF or Git-TFS: cinst Git-TF or cinst gittfs, or both if you want to give both a shot.
To make command line life easier with tab-completion support, and visualise your work a bit better I suggest PoshGit: cinst poshgit
If you are a heavy mouse user and not comfy with the command line you probably want to get GitExtensions, which is a graphical tool to help you with most (if not all) commands. I prefer this when heading down a nasty merge. cinst gitextensions
And last but not least, for those of you quick with the mouse there is a Visual Studio plugin to handle alot of tasks.

Working order

Using Git locally gives you some nice opportunities. Firing up a project and get started is very easy and it can help keep you sane when a large chunk of work is ahead which you do not want to check-in to TFS, yet regularly want checkpoints. Jimmy Bogard has a nice post on how to perform day to day operations. Follow these simple steps and for the most part you will be fine.

The big difference

What you must know when working with Git, is that a folder, any folder, can be a repository. This also means that when you switch branch, the current working folder will change its contents. This is important, because what happens when you have a file open and switch branch? Not to worry, nothing gets lost.

The other difference is that you do not explicitly check out anything. If it is on your machine, you have it accessible and it is never write-locked. Just code away.

The commands, quick reference

  • git init, initialize a new git repository.
  • git checkout myFeatureBranch, switch branch.
  • git checkout -b myFeatureBranch, creates a new feature branch.
  • git add -A, stage all files you want to commit, modified, new files and deleted files alike.
  • git add ., stage all modified and new files, no deleted files.
  • git add -u, stage all modified and deleted files, no new files.
  • git commit -m "Your descriptive commit message", commits all staged files with given message.
  • git rebase branchName, applies and fast forwards work from “branchName” on top of your current branch. Sort of a merge in TFS.
  • git checkout -- <filename>, if, god forbid, you made something wrong, reverts to last HEAD (commit).
  • git reset --hard HEAD, reverts entire branch to last commit undoing anything not commited.
  • git tf clone http://tfs-server:8080/tfs/DefaultCollection $/Path_In_SourceControl, initializes a new Git repo from an existing TFS path. The –deep flag is optional and clones each TFS changeset and vice versa.
  • git tf configure --deep http://tfs-server:8080/tfs/DefaultCollection $/Path_In_SourceControl, configures an existing Git repo to communicate with a path in TFS. The –deep flag is optional and clones each TFS changeset and vice versa.
  • git tf pull, fetch everything from TFS you don’t currently have on your local git repo.
  • git tf checkin, checks all your commits in to TFS. If you’ve used the deep option, each commit will be a TFS checkin as well.
  • git tfs quick-clone http://tfs:8080/tfs/DefaultCollection $/some_project, performs a quick clone letting you keep working from latest changeset.
  • git tfs fetch, fetches latest work from TFS to your local repo.
  • git tfs checkin -m "Did stuff", checkin all your work to TFS with a comment.
  • git tfs checkintool, checkin all your work to TFS using a graphical tool and builds a checkin comment consisting of all your git commits.
  • And then…

    And then you get started! Pull it down, play around with, get a feel for what you like. I really like the commandline for just staging and commiting, as well as performing basic merging where everything goes smoothly, and also pushing commits to TFS. It takes less of my focus away from what I’m currently doing and I don’t have to let go of the keyboard. But then if there’s a hairy merge coming up or a rebase gone wrong, to me the overview and messages are clearer in GitExtensions.

    Speaking of merging, as a last note I want to point out that Git performs mergings much smoother than TFS and can handle 3-way merges. So alot of pain is taken away directly. Then GitExtensions uses KDiff by default to handle the merges (still 3-way) which visualizes it all very well. I can’t remember a single merge having gone totally bonkers with this approach. And if you still don’t like git, consider setting KDiff as your standard TFS merging tool, it will help a lot.

    Further reading

Tagged ,