views:

40928

answers:

11

As a long-time Visual SourceSafe user (& hater) I was discussing switching to SVN with a colleague; he suggested using Git instead, since apparently it can be used peer-to-peer without a central server (we just have a 3-developer team). I haven't been able to find anything about tools that integrate Git with Visual Studio, though - does such a thing exist? If not, can anyone report on their experiences using Git with Visual Studio?

+33  A: 

I use Git with Visual Studio for my port of Protocol Buffers to C#. I don't use the GUI - I just keep a command line open as well as Visual Studio.

For the most part it's fine - the only problem is when you want to rename a file. Both Git and Visual Studio would rather that they were the one to rename it. I think that renaming it in Visual Studio is the way to go though - just be careful what you do at the Git side afterwards. Although this has been a bit of a pain in the past, I've heard that it actually should be pretty seamless on the Git side, because it can notice that the contents will be mostly the same. (Not entirely the same, usually - you tend to rename a file when you're renaming the class, IME.)

But basically - yes, it works fine. I'm a Git newbie, but I can get it to do everything I need it to. Make sure you have a git ignore file for bin and obj, and *.user.

Jon Skeet
git should be fine with VS doing the renaming. For good rename tracking in git log you just have to be sure that you stage the 'remove' part of the change in the same commit as the 'add' part. git add -A makes this easy if your .gitignore is up to date.
Charles Bailey
I'm a git newbie too, and to tell you the truth I *prefer* to use it from the command line. I'd be a bit scared to handle the git power to a GUI that tries to be "clever" and do some "magic" behind my back.
hasen j
Thanks for the advice. I just moved to git (and github) and will never look back. My client uses perforce (ugh!). So my plan is to make one checkout from perforce, do my work with git, then check it back in.
Mark Beckwith
im not agree. newbie to Git will have difficulties to use command line and not friendly. Managing the source control a bit harder because it require more steps to perform a task.
CallMeLaNN
@CallMeLaNN: You're making a big assumption there, about newbies to Git having difficulty when using the command line. Look at hasan j's comment from April 2009.
Jon Skeet
A: 

While it is true that DVCS and Git in particular are the new hotness, it's also true that Windows is still very much "the undiscovered country" for Git.

It can be made to work, but forget about any kind of integration into the Explorer or Visual Studio.

SVN is actually pretty solid on Windows these days (TortoiseSVN + AnkhSVN + command line). If you really want to play with Git, use a blended approach. Use SVN for your shared stable repository and Git locally for experimental work and push changesets with git-svn.

I wouldn't bother with git-svn, even on Windows, unless you are transitioning from one to the other.I've found Git quite usable on Windows, if you don't mind using Git's own GUI app, or the command line for you grognards. That was over a year ago when I last checked too. It's probably better now
T.E.D.
I have been using git on Windows without any problems. If you have problems setting up a repository that is shared/hosted you could still host one shared repository on a Linux server and work form Windows development computers. There are some cheap git hosting services out there too. For example this website is free for the first project even if not open source and includes unlimited users: http://codaset.com/pricing
INTPnerd
+125  A: 

There is a project called Git Extensions that includes add-ins for Visual Studio 2005, 2008 and 2010, as well as Windows Explorer integration. It's regularly updated and having used it on a couple of projects, I've found it very useful.

Jon Rimmer
Oooh. Thanks.I don't suppose any of that stuff works w/ VS2005?
T.E.D.
Fantastic. This application is brilliant...i've been patiently using the command line and waiting for a tortoiseSVN equiv, but this is better.
Vertis
ted.dennison: According to this page (http://code.google.com/p/gitextensions/) it is a VS 2005/2008 plugin.
Jonas
Vertis: TortoiseGit has been out for a while...
Chris Charabaruk
TortoiseGit kind of sucks though. Git Extensions is much nicer.
Ibrahim
/win. This is very helpful ^_^
Hazior
It does work with VS2005
Gabriel Guimarães
It seems a bit strange that a Git project isn't being hosted on Github. Why did they (or anyone) choose sourceforge...anyway rant aside it is still updated . Version 1.91. was 23rd March 2010
Chris S
To correct myself - the source is hosted on Github, the MSIs aren't.
Chris S
It seems to support VS2010 now.
Maciej Piechotka
+12  A: 

I find that git, working on whole trees as it does, benefits less from ide integration than source control tools that are either file based or follow a checkout-edit-commit pattern. Of course there are instances when it can be nice to click on a button to do some history examination but I don't miss that very much.

The real must-do is to get your .gitignore file full of the things that shouldn't be in a shared repository. Mine generally contain (amongst other stuff) the following:

*.vcproj.*.user
*.ncb
*.aps
*.suo

but this is heavily C++ biased with little or no use of any class wizard style functionality.

My usage pattern is something like the following.

1) Code, code, code in VS.

2) When happy (sensible intermediate point to commit code, switch to git, stage changes and review diffs. If anything's obviously wrong switch back to VS and fix, otherwise commit.

Any merge, branch, rebase or other fancy SCM stuff is easy to do in git from the command prompt. VS is normally fairly happy with things changing under it, although it can sometimes need to reload some projects if you've altered the project files significantly.

I find that the usefulness of git outweighs any minor inconvenience of not having full IDE integration but it is, to some extent, a matter of taste.

Charles Bailey
How about telling Git to ignore the bin/ and obj/ directories within a project too? Unless, of course, you want it to track your build cruft... :p
Chris Charabaruk
Just curious, but why would you want it to ignore your project file?
Mike Brown
You don't, you definitely should have your project file under version control.
Charles Bailey
This is very important - recovering from forgetting to include something in .gitignore once you've started committing and branching is painful, to say the least...
Benjol
@Benjol: It shouldn't be that painful. You just need to `git rm <file>` and `echo <file> >>.gitignore; git add .gitignore` on the tips of your active branches. Once you've committed the change once you can always cherry-pick the fix onto other branches.
Charles Bailey
@Charles Bailey, see my adventures in this question: http://stackoverflow.com/questions/1887049/recovering-from-forgetting-to-gitignore
Benjol
@Benjol: I think your linked question isn't relevant to this question. Here we are talking about ignoring files that Visual Studio will automatically generate, whereas you were concerned with recovering files that you'd removed from a branch (and ignored) but still needed to reinstate in your working tree because they weren't automatically generated.
Charles Bailey
@Mike Brown: He is ignoring *.user files, which are user-specific settings.
Srdjan Jovcic
I agree. I recently made the switch from Subversion to git. I have been using the command line instead of a VS plugin and this works just fine. I originally thought working without a VS plugin would be a pain, but that was a misconception I had because of my Subversion experience.
INTPnerd
+15  A: 

I've looked into this a bit at work (both with Subversion and Git). Visual Studio actually has a source control integration API to allow you to integrate third party source control solutions into VS. However, most folks don't bother with it for a couple of reasons.

The first is that the API pretty much assumes you are using a locked-checkout workflow. There are a lot of hooks in it that are either way expensive to implement, or just flat out make no sense when you are using the more modern edit-merge workflow.

The second (which is related) is that when you are using the edit-merge workflow that both Subverion and Git encourage, you don't really need Visual Studio integration. The main killer thing about SourceSafe's integration with VS is that you (and the editor) can tell at a glance which files you own, which must be checked out before you can edit, and which you cannot check out even if you want to. Then it can help you do whatever revision-control voodoo you need to do when you want to edit a file. None of that is even part of a typical Git workflow.

When you are using Git (or SVN typically), your revision-control interactions all take place either before your development session, or after it (once you have everything working and tested). At that point it really isn't too much of a pain to use a different tool. You aren't constantly having to switch back and forth.

T.E.D.
Exactly. My company uses SourceGear Vault, which does have VS integration. But since it also supports the edit-merge-commit workflow, I never ever (ever) actually use the VS integration. In fact, I think I uninstalled that bit.
Joel Mueller
Don't you guys ever move or rename files/directories? I started using VisualSVN a couple of months ago and I could never go back.
JohnOpincar
@TED To me this means that after a long development you have to remember the reasons for every file change until you check in. If I am working on something and see something that needs to be fixed in a unrelated area I like to check out, fix, and check in knowing that I can purge that change from my memory. I'd rather do this from within VS
Peter M
I suppose. I generally don't have that particular situation come up much. When I do, the responsible thing is to turn around and pull down that baseline into a fresh directory and build and test it, to ensure the change doesn't screw up devlopers who don't have my other unmerged changes available. That is generally best done with a second instance of VS, so you are *still* going outside your one VS instance as part of the process.
T.E.D.
The Git Extensions Visual Studio plugin doesn't try to shoehorn itself in to the old school locked-checkout source control API that Microsoft have provided. It is very well suited to an edit-merge workflow and basically just adds commit/push/pull and file history right inside the IDE. Having file history on the context menu is extremely useful!
Jacob Stanley
I disagree mainly because having to go out of visual studio to check in encourages longer times between check ins. Too many people already checkout at the start of the day and don't check in until the end (or worse days later). Integration with visual studio allows for you to constantly keep the source control in your workflow.
Chris McGrath
@Chris - Ahh, you are clearly a member of the "check in early and often" camp. You are entitiled to your opinion, of course. However, I'm a member of the "don't check it in unless it works" camp. Revision control systems are for controlling working software revisions. If I want disaster backups of works in progress, that's what IT's backups are for. But for you, yeah VS integration would be a lot more useful.
T.E.D.
+2  A: 

As mantioned by Jon Rimmer, you can use GitExtensions. GitExtensions does work in Visual Studio 2005 and Visual Studio 2008, it also does work in Visual Studio 2010 if you manually copy and config the .Addin file.

Henk
+1  A: 

a little late but i would suggest mercurial with visualhg for visual studio

Wow. Someone needs to port that to Git!
Jim Raden
+11  A: 

Also don't miss TortoiseGIT ... http://code.google.com/p/tortoisegit/

tonyo
+3  A: 

The newest Release of Git Extensions supports VS 2010 now (along with 2008 and 2005).
I found it to be fairly easy to use with 2008 and the Interface seems to be the same in VS 2010.

Andreas Klebinger
+7  A: 

Git Source Control Provider is new plug-in that intgrates Git with Visual Studio.

http://gitscc.codeplex.com

yysun
Shameless plug, eh? +1 :)
Khanzor
Is there any chance to get it working in 2005?
Art
A: 

Hi

Is it any extension for git for MAC users? I would like to use git integrated with TextWrangler or any text editor in my MAC.

Kukoda János
You should ask this as a [new question](http://stackoverflow.com/questions/ask), not as an answer.
voyager
Or search through existing questions and answers on this site. http://stackoverflow.com/questions/83789/what-is-the-best-git-gui-on-osx
Alison R.