Visual Studio 2013 includes in-the-box support for Git version control. That support includes the ability to perform Git network operations from inside of Visual Studio, such as cloning a repository, or performing a fetch, push, or pull operation on an existing repository.
An endpoint for a clone, fetch, push, or pull operation in Git is called a “remote.” Visual Studio 2013’s Git support contains support for remotes using the following protocols.
- HTTP (i.e. https://github.com/libgit2/TestGitRepository, or https://yourname.visualstudio.com/DefaultCollection/_git/YourRepo)
- File paths (i.e. F:\myrepo.git, or \\servername\sharename\myrepo.git)
- git:// URIs
As of this writing, Visual Studio 2013 does not have support for ssh-based remotes. If you have a Git remote that uses SSH and you try to perform a network operation in Visual Studio, you’ll get the message “This transport isn’t implemented. Sorry.” (This message comes from the libgit2 library.) I don’t have a timeline for when support for SSH remotes might be implemented in Visual Studio.
When performing network traffic against an HTTP endpoint, Visual Studio uses the System.Net stack (HttpWebRequest and friends) to actually issue the web requests. Both HTTP and HTTPS URIs are supported.
The System.Net stack in the .NET framework has full support for web proxy configuration through the Internet Options page. If you need to use a web proxy to communicate with your remote endpoint, you should set up your proxy configuration there. Start the Control Panel, then select Internet Options to open the Internet Properties dialog. On the Connections tab, at the bottom of the page is a button labeled “LAN settings.” Clicking this button opens the proxy configuration dialog for Internet Explorer.
The System.Net stack also includes support for proxy authentication (HTTP status code 407), if your environment requires it.
Special considerations for HTTPS endpoints
If an HTTPS URI is used for a remote, the Windows certificate store is used to validate the server’s SSL certificate.
If the server to which you are pushing/pulling has a self-signed certificate, then as of this writing, we give an unfortunate and vague error message to the user. “An error occurred while sending the request” is what is commonly seen. You should use the Windows certificate manager (certmgr.msc) to add the self-signed certificate (or the authority at the top of the certificate’s chain) to the Windows certificate store as a trusted certificate, and then try your network operation again. We hope to improve on this user experience in a future release, because it is very hard to make the mental jump here from “an error occurred” to “oh, I need to add the certificate to my certificate store.”
Visual Studio 2013 also supports the use of client certificates as part of the SSL negotiation, if the server requires it. Certificate selection is automatic, by default. If you need to use a specific client certificate to prove your identity to the server, you can use the command-line “tf certificates” command to select which client certificates are eligible for presentation.
When using HTTP to communicate with a remote, Visual Studio may be required to authenticate with the remote server. Visual Studio 2013 supports 3 methods of authentication when communicating with a Git server over HTTP.
- Basic authentication
- Integrated Windows authentication
- Team Foundation Service federated authentication (used only when communicating with endpoints at https://*.visualstudio.com/)
Each authentication method has its own credentials acquisition dialog.
If you are communicating with a third-party Git hosting service like Github or Bitbucket, you will probably be using Basic authentication to send your password in cleartext inside the SSL tunnel. Visual Studio 2013 is able to store and retrieve basic auth credentials from the Windows credentials vault using the same protocol as the Windows Credential Store for Git. If you have this plug-in for Git for Windows installed, then once you save your credentials once, you should be able to use both git.exe and Visual Studio to perform network operations without any password prompts.
If you ever want to clear the password from storage, you can use the Credential Manager in the Control Panel to remove it, or use cmdkey.exe from the command line.
If you are using an on-premises Team Foundation Server 2013 server to host your Git repository, then you probably authenticate to it with integrated Windows authentication. If you are logged on with your domain account, authentication from Visual Studio should be transparent.
However, git.exe (which uses CURL for its transport layer) will not be able to retrieve your credentials transparently. You can either type your DOMAIN\username and password strings when you push/pull, or you can install the Windows Credential Store for Git and persist your credentials for git.exe’s use.
Most customers do not use HTTPS to secure their Team Foundation Server 2013 server on their intranet. However, if your organization does use HTTPS, and has its own certificate infrastructure used to sign the certificate for the Team Foundation Server 2013 deployment, then you may find git.exe fails to validate the SSL certificate. This is because the root certificate for your organization’s certificate infrastructure is pushed to your machine’s Windows certificate store through Active Directory, but git.exe cannot see it. Git for Windows uses OpenSSL for its certificate store and the set of certificates comes with the Git for Windows package. You can disable SSL verification for git.exe through your .gitconfig file, or use the http.sslCAInfo and http.sslCAPath configuration options to help Git for Windows find the certificate at the root of the certification chain for your TFS 2013 deployment.
This authentication mechanism is used only by the Team Foundation Service (https://*.visualstudio.com/) and is based on Windows Live ID. If you have already logged into your Team Foundation Service account using the Team Explorer, you should find that authentication for push, pull, clone, and fetch operations is transparent.
The command-line Git for Windows executable, git.exe, does not support this authentication method. If you want to perform network operations against a Team Foundation Service-based Git repository using git.exe, you will need to provision a basic authentication username and password using the Edit Profile dialog in the Team Foundation Service web interface. You can then use that basic auth username and password from the command line. (Visual Studio will still prefer to authenticate using federated authentication.)