 Hey, I'm Jeremy Eppling, a Principal Program Manager on the Team Foundation Server and Visual Studio Team Services Team. Today, I'm here to talk to you about Git and version control in that product. So there's a couple of things to keep in mind with version control and what we're doing. One of the things is we're all about Git. We want to have a great awesome Git solution with unlimited private free repos for up to five people. So we want to be able to host your projects, even if you're an individual, a small team, or all the way up to a large organization with a lot of complex needs. We really want to have all those Git workflows just be great. Then if you are a large corporation, you can have the policies, permissions, and controls that you need to really enforce the type of workflows that you want with your team just to make them successful. A lot of time when people think about Microsoft, they think about our Visual Studio and.NET integration. We've done a great job with those. But Visual Studio Team Services and Team Foundation Server are really about more than that. You can really use any language, any tool to build any app that you want. So it doesn't matter if it's a Node app, or if it's a Java app, or you're building for iOS or for Android. We have full support for all those platforms, and we have great integration with those IDEs. So IntelliJ, Android Studio, there's plugins dedicated to these. You can hook up with TeamCity and with Jenkins. So what I want to show you now are two demos. I'm going to walk through some of the flows that we have on our website. Then after that, I'm going to show you a demo of IntelliJ and our rich support there. Now let's go look at those demos. So for the first demo, I'm going to show you some of the Git functionality that we have directly from our web experience in Visual Studio Team Services. So as you can see right now, I'm on a Kanban board and I have a user story assigned to me right here. So I'm going to click and I can actually create a branch right from my work item. A lot of the time before, you'd have to have your work item somewhere else and you go and do that manually and we've tried to make that easier just by associating those two things, because we know it's a really common workflow. So I click create new branch and then right from here, I can create my branch name. So we'll do fix bow tie and then I can pick the repository that I want to apply to in case I have multiple repositories in my team project. I can choose the branch that I'm going to base my change off of. As you can see right here, it's already linked to the work item and the great thing about linking that now is all the changes that I do afterward will be linked as well. So when I create a pull request, that work item will be appearing right in the pull request. Then later when I commit and push my changes and get them into master, when you're looking at the history, you'll also be able to see the work items that were fixed with that code change. So right now I'm going to click create new branch. As you can see, I'm in my new branch, the fix bow tie branch and one other thing you'll notice is that we have integration with CI builds. You can see in this topic branch, I don't have a build going right now. But if this was in a master branch or releases branch, we actually have CI configured and I'll show that a little bit later on. So now what I want to go do is find where that issue is with bow tie. So let me go up into our global search box and I can type bow tie style. What this is going to do is search all the code across all the repositories and all the team projects. So you can look at the search came back and it turns out that this change is only in one team project and then in one repository, but there's four changes in there. So it turns out the one that it got at the top is the one that I need. So I want to go change this max width right here. So I'm going to go over here and click bow tie common styles to go make that change. So right there, I clicked on my search result and now I am directly looking at that bow tie common file. So I can go down here and click edit. And right from the web, I can make these changes. It's really convenient for simple changes. So I'll go through, change this to 500 and then I'm just going to commit that change to my branch. So as you can see that change was committed right up here and it updated the bow tie common.css. Now I can go through and if we refresh, we'll see that now I can go ahead and create a pull request because I just pushed three minutes ago. So I'm going to go through and click this right here, create a pull request. And right now, it's looking at comparing my changes against master and then I'm going to be able to see what those are and review that before I start my pull request. So I can go ahead and see that it grabbed, updated the file name right here. I can see what the description is. And I can see that we already had policies configured that whoever updates this file, this team, VS Online VS O team should actually be part of the reviewers. So that's one of the features we have along with branch policies. So if I were to go back and look at our branch policies, and as you can see on the master branch, we have a set of policies. So there's a lot of different policies that you can go choose to enforce on an individual branch. This is really helpful if you have a specific get flow type workflow where maybe you have a releases branch and in that you want to have a different set of policies on who can make edits and what they can go do in that versus a users branch where you have all of your topic branches versus your main branch like master. So you can say automatically create builds for every single pull request. You can require people to link work items. You can have a minimum number of code reviewers assigned. And one of the things that we've used in this repo here is to actually say for certain paths of the code, certain code reviewers are actually required. So as you can see, sometimes it's a actual team or a VS O group that's assigned to this or sometimes we have individual users who we say, hey, this is really the engineering expert on this area. So any change that happens in this area, that person needs to go review it. And if you go back to where we were in pull requests, you'll see that's why I had this reviewer automatically added right on here. So I can go through and review my pull request. I can see the commit and I can see the diff of the change that I made. Then I'm gonna go right here and click create pull request and my pull request is created right here. And because we have CI builds hooked up, you'll see that there's a merge in progress. Again, no one has responded yet, as you would imagine. A couple of different teams were added onto here who we know need to go review the changes because of the path that I was in. And then as soon as the merge is done, it's going to kick off a build. And then I'll have that build going and get my build results right in there. So it's really a full ALM solution from when I go through, I can configure those policies so that once I do a pull request, we'll automatically kick off a build and add the right reviewers just to reduce some of those manual steps that you have getting started. So one other thing that you'll notice on the pull request is that that work item was associated right here. So if I click right here, because I created my branch off of that work item, it was automatically associated with me. And like I said, it'll also automatically be associated with the commits. So it'll be in the history of your branch. As you can see right now, that there was no merge conflict and the build is going right now. If I were able to switch over and go to pull requests, we can look at some pull requests that are already in flight now. So as you can see, we've improved the pull request view. So I can see pull requests that were requested by me, the one that we just did right at the top. Because most of the time, I wanna see my pull requests that are out first. We can see the branch that it came from, the one that it's going into and the individual reviewers. I can go down and see all the ones assigned to me that other people want me to review. And you'll notice that my avatar is right here in the front. And I can see that, oh, two other people have already approved this. I can see that Jay has approved this. And then I can look over here and see that a team has also approved this pull request. And then I can go down and see all the pull requests that are actually assigned to my team, which I may care about looking at. Or I can jump over and just see all the pull requests in the product and filter by those as well. So as you can see, we really have this end-to-end experience where on the web, you can go in, you can create a work item from a branch, that association is linked up. I can go ahead and make edits on the branch, commit those edits, can go and create a pull request. And then I can go review that pull request and have CI builds kicked off automatically. Now for the second demo, I wanna show you our integration with IntelliJ. We just built a plugin called Team Foundation Git. And it just makes the IntelliJ experience much easier because one of the things we wanna be great with is not just great with Visual Studio and .NET where we have deep integration. We're also gonna have deep integration with all the other IDEs and tools you use. And Java is extremely important to us. We love Java and wanna make sure we have a great experience for Java developers as well. So I'm gonna click out right here, click check out from version control, Team Foundation Git. And right from there, you can see that it's gonna pull down all the repos that I have associated with my account. So previously I've already logged in with my Microsoft account. And it knows that I have a Visual Studio Team Services Account associated with that. And I can see all the repositories right there. I can go ahead and search for the list of repositories. So very easy for me to find what I'm looking for in clone. I don't have to go to the web and go find a clone URL. So I'm gonna grab this console app right here, change the directory name to console app four. And then I'm gonna click clone. And I'm gonna go through and do the different setup experience here. This is just the normal IntelliJ setup experience for my repo go through. And now I've got my repo cloned down and you can see all of the code added right here. So what I wanna go do now is open this up and I'm just gonna add a comment just to show you what some of the developer flows like. So I just typed in my change right there. I can go down and then we're gonna go ahead and create a new branch for these changes. I'll test branch. Now my branch is created. I can see it's right down here and I've got my change. I've got my branch. Now I wanna go ahead and do a pull request for this change. So I'm gonna go up to the version control menu, go to get and down at the bottom you'll see with the Visual Studio Team Services logo right there a create pull request button. So it's integrated just directly into VSTS. So I'm gonna click right here, create a pull request. As you can see we've created a create pull request experience right here that just matches and feels just like the rest IntelliJ. So you feel like you're at home in your IDE right there. I can go ahead and see the target branch of where I wanna go, which is Origin Master. We went ahead and grabbed the commit message and description and prefilled those based on the ones that were already in the commit. I can review my changes and then I can click create pull requests. Right now we're pushing that branch to the service and then you can see the pull request was created right here with a little notification. I'm gonna click right on pull request number three and I'm taken right to my accounts and I can view that pull request. And as you can see, there were no merge conflicts and it's already gone ahead and started to kick off my CI build that I have configured. And again, just like I showed you before in the previous demo, I've got a branch policy set up right here so that we automatically build whenever a pull request is created and I block the merge if the latest build didn't succeed. So this is a more strict environment through here but as you can see, all that integration just makes it very easy for developers to go and do the right thing by default. And so right there is our integration with IntelliJ. As you can see, it just feels like a native part of the IDE and that's our goal is to really make this a great experience for Java developers who are using VSTS or TFS. Well, I hope you enjoyed the demos of walking through what it's like to use Visual Studio Team Services and Team Foundation Server with IntelliJ and then also on the web using a Mac. And as I said before, we have great support for Visual Studio as well. Obviously it works great on Windows. What I wanted to show you today was really just the breadth of the offering that we have that we aren't just about .NET and Microsoft. We also love Java. We love allowing you to build any sort of application you want. So here's a couple of resources for you to check out. You can get started with Visual Studio Team Services. If you just go to visualstudio.com, there's a link right there to get started for free. And then if you want more information just on version control, what exactly do we support? What is our get support? What's our centralized version control story as well? You can check out the second link right there. Thank you very much.