I'm a .NET developer and I've used TFS (team foundation server) as my source control software many times. Good features of TFS are:

  1. Good integration with Visual Studio (so I do almost everything visually; no console commands)
  2. Easy check-out, check-in process
  3. Easy merging and conflict resolution
  4. Easy automated builds
  5. Branching

Now, I want to use Git as the backbone, repository, and source control of my open source projects. My projects are in C#, JavaScript, or PHP language with MySQL, or SQL Server databases as the storage mechanism.

I just used github.com's help for this purpose and I created a profile there, and downloaded a GUI for Git. Up to this part was so easy.

But I'm almost stuck at going along any further. I just want to do some simple (really simple) operations, including:

  1. Creating a project on Git and mapping it to a folder on my laptop
  2. Checking out/checking in files and folders
  3. Resolving conflicts

That's all I need to do now. But it seems that the GUI is not that user friendly. I expect the GUI to have a Connect To... or something like that, and then I expect a list of projects to be shown, and when I choose one, I expect to see the list of files and folders of that project, just like exploring your TFS project in Visual Studio. Then I want to be able to right click a file and select check-in... or check-out and stuff like that.

Do I expect much? What should I do to easily use Git just like TFS? What am I missing here?

  • 8
    I switched from SVN to git one year ago, and I'm very happy about it. I would NOT recommend SVN to anybody except to a rigid command line hater. Once you learn git, you'll love it.
    – maaartinus
    Commented Oct 15, 2011 at 12:25
  • 14
    Why is it that windows folks are so obsessed about graphical interfaces?
    – tdammers
    Commented Oct 15, 2011 at 15:57
  • 8
    @tdammers Because command line on Windows sucks like hell? I know, there's PowerShell, but do they use it?
    – maaartinus
    Commented Oct 15, 2011 at 16:20
  • 3
    @Saeed, for a start, you're expecting that there's any such thing as checking files in and out in git. No usable VCS has had that for years. Commented Oct 15, 2011 at 17:18
  • 1
    Recommended read: ericsink.com/entries/vcbe_print_edition_free.html It explains the basics of version control and the differences between centralized and decentralized (that could still use a central server, mind.)
    – Inca
    Commented Oct 16, 2011 at 8:46

7 Answers 7


The advantages git has come from tossing out a lot of old assumptions about what a VCS should do. The disadvantages git has come from not being able to leverage prior experience and not being able to do things the way you are used to.

If you are going to switch from something else to git, try to start tabula-rasa (though it is impossible to truly do in practice). Evaluate it based on what it does and how well it does it, not on how it does it compared to how you are used to doing it. It's not that you expect too much, it's that your expectations are orthogonal to what git provides. If you're married to GUI operation, you'll be disappointed. Git does have gui tools available, but they don't add much. That's not a failure to provide them so much as there isn't that much that a gui can add. GitK does help, not in day-to-day operations, but rather in visualizing the branch structure and examining or searching history.

Here's a goofy analogy for what I mean by "orthogonal". One of the things you can do with a newspaper is wrap fish in it, or use it to line a birdcage. But those are not essential to the function of a newspaper, those are incidental features of the form it comes in. Expecting git to "check in files", or "allow you to select projects", or provide a "connect to..." is kind of like expecting to be able to wrap fish or line your birdcage with a newspaper's website.

  • Ooops, I forgot to explain the edit. I just added the last paragraph after getting up for more coffee and having the analogy pop into my head.
    – kylben
    Commented Oct 15, 2011 at 14:20
  • 3
    Loved the metaphor in the end. +1 Commented Jun 18, 2012 at 19:00

Have you considered mercurial? Like git, it is a DCVS and lets you do all the neat things one can do with a DCVS. Like git there is a pretty good, cloud-based service provider (bitbucket). But, unlike git, the windows story is pretty decent, you are not a 2nd class citizen. You've got good tooling options (TortiseHG) and pretty decent Visual Studio integration (VisualHG).

Nothing is going to be like TFS in visual studio though -- the world just isn't wired that way.

  • 1
    I'd agree, a few years ago I moved from VSS to Mercurial and it was a real epiphany. Suddenly I could do things I never thought would be practical. Then I moved to svn and missed lots of things which were just so easy in hg. Now I'm moving to git and have mixed feelings. I love getting back many of those facilities I missed in svn, but I still miss the simplicity of hg compared to the unnecessary complexity of git. Even just installing TortoiseGit on windows requires you to jump through hoops that simply aren't necessary with TortoiseHg.
    – Mark Booth
    Commented Oct 17, 2011 at 16:38
  • @Mark Booth: I'd agree that git is not very user-friendly, but what unnecessary complexity? Installation problems do not count, they could be attributed to TortoiseGit (which is a different program) or to Windows.
    – maaartinus
    Commented Oct 18, 2011 at 20:39
  • This would be better off on chat, but I see no need whatsoever for the index/cache/staging area, IMHO the default should be to commit everything with the option of partial commits if requested (better still would be to shelve the changes you don't want immediately , re-run your unit tests, commit and then unshelve). I also hate having to explicitly create a new branch when I want one. With hg an unnamed branch is created silently whenever you commit to a non head. In git, if you move away from a head without branching you can potentially lose it and then have it garbage collected!
    – Mark Booth
    Commented Oct 19, 2011 at 11:15

I switched from SVN to git one year ago, and I'm very happy about it. However, I'm not relying on any GUI and in case you rigidly refuse command line it may be a problem.

You seem to expect git to work the way you're used to, but it doesn't. It's not hard, but you should take a look at its principles before you proceed.

Creating a project on Git and mapping it to a folder on my laptop

Git is distributed, which means you always work with your local repository, which may be mapped to any number of remotes, including zero. When playing with other's project I'm using two remotes: their git or SVN repository and my own server.

I always start by creating an empty directory and then either git init or git clone SOME-REMOTE-REPOSITORY. This link could help you.

Checking out/checking in files and folders

You missed to write what GUI you're using. Both TortoiseGit and git-gui surely can do it.

Resolving conflicts

For this I'm using git-gui or my favorite text editor.

I expect the GUI to have a Connect To... or something like that

Connect to what, when there may be 0 to N remotes? Git doesn't stay connected to a remote server, it creates the connection only temporarily and only for the few commands working with the remote repository. Most of the work gets done locally.

then I expect a list of projects to be shown

I'm assuming by projects you mean repositories.

I'm afraid there's no such thing. Git on a remote server works strictly with one repository only. Listing all repositories is equivalent to listing all directories containing the subdirectory .git. I'm sure there's something like this on GitHub.

I choose one, I expect to see the list of files and folders of that project, just like exploring

Again, I'm afraid there's no such thing, since git works locally. And again, it wouldn't be of much use. Simply clone the repository and explore it on your computer. While cloning of huge repos takes some time, all subsequent operations are much faster, and you may look at any commit or branch.

Then I want to be able to right click a file and select check-in... or check-out and stuff like that.

Again, git works locally. So it makes no sense to check-in or check-out to a remote repo. Working this way is a waste of time even on a fast LAN. Get the repository to your computer, work with it and git push the changes to the remote. Think about it like about publishing your changes and also making backup. You should commit locally very often.

Before you start your work, git fetch or git pull the changes from the remote in case somebody else may have been working with it.

Do I expect much?

Yes and no. You expect something different from what it offers. You can get something much better, git is powerful, flexible, safe, fast like hell, and can do everything you need, but it can't mimic exactly what a centralized VCS does.


I have made the journy from visual source safe to tfs to svn to git.

Going from vss to tfs was a pleasant experience. Going from tfs to svn was a pleasant experience. Going from svn to git has been sort of an internal battle.

Often I find myself to be quite conservative and I try to hang on to what works. A nice gui is for me preferable over the command line and I found myself searching for some gui that would let me play with the cool kids I work with. They all used git with the command line exclusively.

The eureka moment for me came once I gave up on the search for a silver bullet gui and started to give git bash a try (I'm still learning).

I have some guis installed and they do complement git from the command line. Git extensions, Git source control provider for visual studio and tortoise git. But I say get familiar with git bash. The commands can be a little cryptic but once you learn them they are so much faster than the gui.

Branching with git is just AWESOME compared to the others. Create branches and switching between branches it almost instant. You can do stuff you would not bother doing with svn because svn basically copies your working copy (at least the way I did it).

I find Git to have a steeper learning curve than svn. But once you "get it" with git you don't want to go back.

Git all the way.


You're used to having a server which stores your files and is the omnipotent owner of them. To edit a file you must ask for permission from the server.

Git is not like that. Think of git this way: you have your local repository. Git lets you commit changes, reverse commits, easy and quick branching, etc. When you want to backup your source-control history, you push your changes to another repository, which "just happens to be" a server, like GitHub.com.


  1. Clone(Download)/Create repository
  2. Make some changes. Continue with development without caring about others.
  3. Push to another repository (could be a server like GitHub).
  4. When you push to a repository, that other repository's owner is notified of the pending push, and must decide whether to accept those commits, decline them, or only take a subset of them.
  5. The cycle continues.

That is all.


What do you mean, "the" git gui? There are a gazillion of them, including a plugin for visual studio integration, if I remember correctly. If one GUI doesn't work for you, try some more until you find one that does. I personally use different GUIs for different tasks (and the CLI for others).

However, git is more of a version control framework than a fixed system. You're still going to have to learn some basics to get the most out of it.


Do I expect much?


What should I do to easily use Git just like TFS?

Nothing. Git is CLI-centric and haven't any good frontend (I know about TortoiseGit, which is not answer, comparing to other Tortoise*). You can try to use SmartGit (beware of Java)

  • 1
    -1: Checking in/out files and resolving conflicts is not 'expecting much' from source control. Commented Oct 15, 2011 at 13:47
  • 2
    +1 Checking them directly from a remote server simply makes no sense. It's just to slow, even over LAN. Doing such things is something FTP is for, not VCS.
    – maaartinus
    Commented Oct 15, 2011 at 13:50
  • 1
    "Checking in/out" files is not a fundamental operation for a VCS. It is an implementation feature common to most VCSs, and one that has subtle but unfortunate side-effects.
    – kylben
    Commented Oct 15, 2011 at 14:03
  • 2
    @kylben: checking in/out is one way to look at version control; editing-and-merge is another way. Some VCS's use the former approach, giving you exclusive locks and the ability to check out individual files; others take the latter, and with those, you download the entire repository, make your local changes, and then push them back to the remote; the VCS takes care of managing conflicting changes, asking for your input in case of doubt. Neither approach is better, but you can't usually bend a VCS into the one it hasn't been made for.
    – tdammers
    Commented Oct 15, 2011 at 15:56
  • 1
    By 'checking in/out', I was actually talking about the way lock-based VCS's implement things, not how you can download source files for editing (which is indeed something every VCS must be able to do). The fact that many VCS's refer to the mere process of downloading a file as 'checkout' is a bit of a misnomer IMO - nothing is checked, and the repository does not remember who has the file.
    – tdammers
    Commented Oct 15, 2011 at 21:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.