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
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 MSDN.
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.
When I try to access the page to download the tools for git for VS 2012 I get an error.
So, what's going on with that? It's been three days now, it's the first comment on this page, that the page for downloading is not working. Doesn't anyone care?
That page ain't working.
Tommie Nygren - download is working for me and we've had lots of successful installs. Can you email me (firstname.lastname@example.org) with details about where you are downloading from in the world and the error that you are seeing? I'm wondering if there is a bad CDN cache somewhere near you or something?
I'm a bit new to Git, but I've been experimenting and it works well. I'm using a mixture of VS and the command line tools installed with GitHub. A few observations/questions:
* I keep getting errors checking out branches in VS, but it works from the command line (and VS properly picks it up)
* I can't figure out how to push a branch that only exists on my local repository (git push --set-upstream origin <branch>) from VS. Is there a way to do so?
* When I try to use the command line git with a remote operation (like git push), I get prompted for credentials and my Microsoft Account credentials don't seem to work.
Dan Crevier: I intend to soon publish guidance on scenarios like these. For the third issue with authentication, see if tfs.visualstudio.com/.../use-git-and-xcode-with-tfs ("Enable basic authentication for your account" section") helps.
Does TFS Support user forks or branch-based security?
If not, this solution is about 5 years behind the GIT offering of BitBucket, Beanstalk and Github.
I'll check back in a year.
There are a couple of checkout situations the our base library Libgit2 doesn't support yet. Most notably handling conflcits. If you could provide more details I could be of more help.
For pushing a branch that exists only on your local repo. You need to go to the branches page, find the branch in the Unpublished Branches section and Publish it.
Forking is on our backlog.
We currently have only repo-level permssions. Adding more types and granularies of permssions is on our backlog.
When adding a new build definition, the UI does not look like the one in your screenshot. In the UI (I am guessing from GitTemplate.xaml) Under Git, it has 1. Clean Repository. There is no Repository Url parameter. When that build then tries to run, you get this exception:
Exception Message: No Repository Url was provided. Either specify the Repository Url as a parameter or set it on the build definition. (type ArgumentException)
Brenton House: Are you running CTP2 or the just released CTP3? As we speak I'm writing a post about CI builds in CTP3. I'll also try to take a look and get more info about your issue.
Andy Lewis: I am pretty sure that it is the CTP 2 with Visual Studio Tools for Git 0.7.0.2. I can try to install the CTP 3 and see if that changes anything.
Brenton House: Our PM advises that installing CTP3 on your dev machine should fix the issue: go.microsoft.com/fwlink. After you do that, check out blogs.msdn.com/.../run-ci-builds-in-your-git-team-project.aspx
I have exactly same issue as Brenton House, installed the latest CTP3 (just run 'vsupdate_KB2707250.exe') but it did not help - I still can't specify git repository and branch in build configuration.
Despite the update added CI build triggering and more options, it is unusable for me as I can't run any build with git source control.
Artiom Ciumac: Have you tried the CI build guidance we published yesterday? blogs.msdn.com/.../run-ci-builds-in-your-git-team-project.aspx Please let us know if it helps or not.
I have tried to follow the instructions from link you provided and the build failed with the following exception:
Exception Message: Value cannot be null.
Parameter name: path (type ArgumentNullException)
Exception Stack Trace: at Microsoft.TeamFoundation.VersionControl.Common.VersionControlPath.IsServerItem(String path) in d:\a1\dd\alm\tfs_core\SourceControl\Common\VersionControlPath.cs:line 66
at Microsoft.TeamFoundation.Build.Workflow.Activities.BuildDropProvider.CombinePaths(String paths) in d:\a1\dd\alm\tfs_core\Build\Workflow\Activities\BuildDropProvider.cs:line 53
at Microsoft.TeamFoundation.Build.Activities.RunMSBuild.GetDefaultLogLocation.Execute(CodeActivityContext context) in d:\a1\dd\alm\tfs_core\Build\Activities\RunMSBuild.cs:line 295
at System.Activities.Activity`1.InternalExecuteInResolutionContextUntyped(CodeActivityContext resolutionContext)
at System.Activities.Runtime.ActivityExecutor.ExecuteInResolutionContextUntyped(ActivityInstance parentInstance, ActivityWithResult expressionActivity, Int64 instanceId, Location resultLocation)
at System.Activities.Runtime.ExecuteSynchronousExpressionWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
In build definition, in Build Defaults page, for option "Staging location" I have specified "This build does not copy output files to a drop folder" - maybe this causes the issue. Will try to reconfigure it and run again (it takes some time until the build queue is processed - don't know why but it seems quite slow).
specifying "Copy build output to the server" for Staging location solved the problem. Now builds seems to work fine.
Artiom Ciumac: Thank you for reporting this issue. I was able to reproduce it and show it to our product team. They will investigate it further.