Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
More videos »
By Matthew Mitrik (MS), Andy Lewis, and Martin Woodward
Today we announced the availability of Git for Visual Studio and Team Foundation Service. In this post, we'll walk through the new experiences.
Get set up: Get the free service, and then you can use it with any Git client tools you want, including Visual Studio. To use the Visual Studio client tools you'll need to install Visual Studio 2012, apply Visual Studio 2012 Update 2 CTP, and finally install Visual Studio Tools for Git. You can use these client tools with any Git service you want.
With this announcement, each time you create a new team project we give you a choice: Team Foundation Version Control (TFVC) or Git? The best option for you depends on a lot of factors, including size of codebase, team size, and team distribution to name a few. Now that Git is fully integrated with TFS, the decision depends solely on what your team needs from version control. Looking at the strengths and features of each system can help make the decision easier.
TFVC is a centralized version control system. While it works well for small teams with small code bases, TFVC is capable of scaling to support very large codebases (millions of files per branch with server workspaces) and it handles large binary files well. TFVC provides very granular permission control, allowing teams to restrict access down to a file level if needed. Since all contributions are checked in to the central server, it is very easy to audit changes and identify exactly which user committed a given code change.
Learn more about TFVC on MSDN.
Git is a distributed version control system where each developer has a copy of the entire source repository. Having a local repository means that Git works well in environments where developers need to work without connectivity. It also offers a simple branching model that enables developers to quickly create local and private branches, enabling flexible workflows. Git also works well in modular codebases where code is distributed across many repositories.
Learn more about Git on the official Git site: http://git-scm.com/documentation
Ultimately, much of the decision about which version control system to use is about preference. Both systems are equally capable for the majority of teams. Make sure your team is happy with the version control system you choose.
You can quickly spin up a new Git team project with just a few clicks.
In the next section we'll tell you more about how to connect to your new team project from VS. Also, we'll talk about another option you have to begin from your local dev machine instead of from a team project.
Git provides powerful DVCS features that enable your team to collaborate on an app. But Git's user interface can be difficult to use, and to get full value from it you may need to bring separate tools together. Visual Studio provides an integrated experience that makes it easy for your team to leverage the power of Git. And if you are a Git pro who has some favorite Git tools you still want to use, you can use them alongside Visual Studio.
If your Git repository is in a TFS team project, you get additional benefits from the integration with other TFS features such as work items. But even if you are not using TFS, you can use Visual Studio with Git to work on a completely local repository, or to collaborate using Git hosters such as GitHub and BitBucket.
When you are ready to begin working in your Git team project, you begin by connecting to it. Once you've connected to your new Git project, you'll be prompted to Clone the repository in the team project onto your dev machine.
After you cloned from a Git team project, you will have two entries for this codebase, one under Team Foundation Service and one under Local Git Repositories.
You can also use the tools to clone from any hosted Git repository.
Maybe one of the coolest features of Visual Studio with Git is that in just a few seconds, you can be writing code on a new project under local version control. Want to try it? You can create a new code project in a new local Git repository in less than a minute:
You can continue coding and committing locally for as long as you like. When you are ready to share and collaborate, just publish your code into TFS, or into whatever Git service your team uses (e.g. CodePlex, GitHub, Bitbucket).
Git associates each commit you create with your name and email address. When you first begin using Visual Studio with Git on your dev machine, if you begin by cloning from a Git team project, then Visual Studio fills these in for you.
You can override the name and email settings and specify other settings.
Enable download of author images from 3rd party source: Visual Studio can display author images on commits. By default it uses the image in the user's TFS profile. If the user doesn't have an image set, an image from Gravatar will be used.
Ignore File: To avoid checking in temporary non-source items such as binaries, you can specify a .gitignore file. See Ignoring files and gitignore(5) Manual Page.
Attributes File: To specify options such as how the system handles line-breaks, you can specify a .gitattributes file. See Customizing Git - Git Attributes.
For more information on Git settings, see Customizing Git - Git Configuration.
As you write your code, you can commit to create a snapshot of your changes on your dev machine as often as you like. You can associate a work item with your commit by specifying its id in the comment.
Later when you push your local repository to the Git team project, the commit will be associated with work item 255. In TFS you can also associate a work item with a commit after it has been pushed using the Links tab in the work item.
To ensure your code integrates well with the latest code from the team, you should pull changes on a regular basis. Also, if there are any changes in the remote branch, you must pull them before you can push.
Before you pull, you can fetch to see what changes are coming.
When you are ready to take the changes, pull them.
For step-by-step instructions, see Pull changes from the team.
When you are ready to push the changes in your selected branch, just click Push.
For step-by-step instructions, see Push your changes.
Git branches differ from TFVC branches in a few ways. Git branches are local (and thus private) until pushed. They are also more lightweight, so you can quickly create a branch on your dev machine whenever you need one.
You can switch the branch you are working in from Changes and Commits pages.
When you are ready, you merge to combine the work.
For more details on how branches work in Git, see Git Branching.
Sometimes you will need to resolve conflicts before you can complete a pull or a merge.
Visual Studio makes it easy for you to resolve some of the most common kinds of conflicts, such as content conflicts.
Some conflicts (such as rename conflicts) must be resolved using a command-line tool such as Msysgit.
You can view the history of an item from Solution Explorer or from the Changes page. You can also view the history of an entire branch from the Branches page.
After commits have been pushed into the repo, the Code hub starts to look a lot more interesting.
The Explorer view is the center of the browse experience in the web. You can drill in to the contents of a repository and see the commit message and author of the latest changes to each folder and file.
As you're exploring the repo, you can easily switch to the History view to view the history of a file or folder. The history view is a similar to the VS view, providing the comment, author, and time of the commit. Off to the left is an indicator showing relative size of each commit.
Using the Compare view, you can compare versions of a file in either a side-by-side or inline diff view, complete with syntax highlighting.
To see an all-up view of the repo history, use the commits view. By default, the view shows all changes, but you can filter to view just your commits, or use the Advanced search to filter down the list by author, path, and/or date.
Drilling in on a commit shows the detailed metadata for the commit, including associated work items. Each file modified in the commit is also shown with an inline diff to summarize the changes.
In any of the views in the Code hub, the branch selector may be used to pivot the entire repo view by branch. If you've pushed any tags to the repo, they'll be shown in the same picker.
Developers using Xcode will be able to use the existing Git integration to work with repos hosted in Team Foundation Service. Be sure to enable alternate credentials (basic auth) for your TF Service user profile before trying to push and pull from Xcode (or any other third party Git client for that matter). Note that you can get the clone URL from the Explore view in the project's web portal.
The cloud build service can be used to build Git projects much like you can build TFVC projects.
Configuring a build for Git projects is similar to configuring TFVC builds. You can start by clicking New Build Definition in the Builds page in Team Explorer.
In the build definition editor, give your build a name and a description. On the process page specify the branch you want to build and the relative path to the solution file to build. Note that only the manual trigger is currently available, but we're working on adding more.
Queue a new build from the Builds page. Remember, you need to push your commits to the service in order to build them.
After the build has completed, the build report shows that the build succeeded.
This is super and the video on Channel9 was clear, concise and 'to the point'.
The "naming" also seems to have improved. Please keep it that way.
Is there any way to migrate CVS Code and history to TFS
John, it will be supported in Express in the next release: blogs.msdn.com/.../git-init-vs.aspx
Vimal, the easiest way would be to check in the latest version for TFVC. For moving to git, see stackoverflow.com/.../importing-cvs-to-git-scm.
How can I let Visual Studio use the new git integration with a project I already have on bitbucket?
Alessandro: You simply clone the repo from the Connect page. See "To get going, connect and clone" above. We've been talking about posting some guidance to focus on this scenario more explicitly.
Vimal: Try Timely Migration.
I'm in the same boat as Alessandro: I jhave an existing GitHub repository. Under Lical Git Repositories, I choose Clone and enter the repository URL. I can an error that reads: "An error was raised by lbgit2. Category = Net (Error). Response status code does not indicate success: 302 (FOUND). I assume this is because I need to log in to GitHub, but I don't see anywhere to do that. Any ideas?
@Mike - If you have the Git repo that's hosted on GitHub on your local disk already, you can use the "Add" command in the "Local Respositories" section of the Connect page to add the repo to the list. No need to clone again, and the origin should already be configured, so you should be able to push and pull using the Commits page.
As for the specific error, we'll look into it. At the least, we need something more meaningful/actionable - we have an item on our backlog for us to do a sweep of all of the error messages to make them better.
@Mike E Yeager
First its going to look in the Windows Credentials Store. It should prompt you for credentials on private repos when you click Clone if it doesn't find any there. I guess maybe you maybe have old credentials cahced? Auth problems would be a 401 not a 302. Are you maybe cloning from something that redirects, like TinyUrl?
I'd argue that git-tfs is faster/more flexible/more mature for moving from TFS to git and vice versa.
Can I use Git as a local version control system, and TFS as a remote VCS for one project?
Wentao: I think you are asking about using Git on local dev machine and TFVC as remote version control, yes? If so, then this might help: gittf.codeplex.com/wikipage
Does TFS plan to have "pull request "just like Github
Mohammed: "We’re nowhere near done with our Git solution. We are currently lacking major features – like pull requests – but they are coming." (blogs.msdn.com/.../git-init-vs.aspx)