Good afternoon, everyone. How are you doing? Having a good conference? Okay. Well, I'm Brent Shank and I'm a software engineer on the Xcode team. And we're really excited today to talk to you about Source Control. We love Source Control. It's what we work on. And we have a lot of interesting things to show you today. Before we do that, I'd like to get a show of hands. How many people in the audience are using Subversion? Okay, good.

How about Git? All right, so it's really about half and half. That's great. Well, as you know, Xcode has great support for both Git and Subversion, and we'll show you some of those features today. So... Thank you. So what are we going to talk about today? Well, this is really an advanced talk, but before we get into some of those more advanced topics, you need to know about the basic Source Control features in Xcode 4. So I'm going to go over those.

And then we'll get into deeper topics like sharing your code, working collaboratively, and we'll also talk about using branches effectively. Historically, branches have been kind of a difficult part of Source Control in general, and what we've done in Xcode 4 is we made it really easy. So you no longer have to be afraid of branches, and we're going to show you how to use them effectively in Xcode.

So, introduction. Let's talk about Source Control in general in Xcode. And let's talk about editing. Now, why is editing a relevant topic when we're talking about Source Control? Well, you'll see. Then we're going to talk about committing changes. This is probably the most common thing you do with Source Control.

We'll talk about viewing history and all the great ways Xcode helps you do that. And finally, we're going to touch on managing repositories. And really the best way for me to talk about these things is to show you write in Xcode. So, I'm going to give you a demo.

So I've cloned a project from a Git repository here. It's an iOS project. I'm going to open it in Xcode. And some of the things you're going to see today are new in Xcode 4.1 and 4.2. I'll try to point those out as we get to them. So we're going to talk about editing.

And before we do that, like I said, this project already has some modifications. It already has some files that have some kind of source control status. So they've been modified, added, or deleted. And it'd be really nice to see all of those files that have changes. And I can do that by using the Project Navigator. And I'm showing you this because this is a way I like to work in Xcode in general.

So in the Project Navigator, you notice the filter bar at the bottom here. I can zoom in on that. And it's got a number of controls. The middle one here is the source control filter. Let me zoom out. And when I click that, it's going to show me the source control filter.

And It's going to filter the list of files down to show you only the things that have some kind of Source Control status. Now, I really like working with this filter all the time because it means when I'm working on a particular task, every time I edit a file, it shows up in this list. So if you're working with a large project, this is really a quick way to navigate changes in a particular task that you're working on.

So let's talk about editing. So again, why is editing relevant in a talk about Source Control? Well, usually when you're editing, you're editing in a vacuum. You're in a file, you don't know who changed it, you don't know why they changed it, or you've landed on a particular line of code, and again, you don't know who changed that line of code, why or when.

And by telling you these things, we really, we feel we enrich and enhance your editing experience. So how do we bring that stuff into the editor? Well, as you know, Xcode has three kinds of editors. The, I'm in the standard editor right now, which shows me just one editor in the workspace window.

There's also the assistant editor, which you've probably used to wire up your user interface to your source code files. And finally, there's the version editor, and I will select that now. So there are three modes in the version editor. The first is the comparison view. The second is blame view, and the third is log view. And let's talk about each of those right now. So right now, I'm in the comparison view. And to make it more interesting, I'm going to select a file that has modifications.

And when I do that, I see side by side, two versions of the same file. Now in Xcode 4, the file in the leftmost editor represents your document, my document in this case. So this is the document that I'm working on. It has changes to it. I haven't yet committed it back to the repository. On the right-hand side is another version of the same document.

Now in most cases, this represents the previous version to the one you're looking at on the left-hand side, or the most current version on the server. But in most cases, you can actually choose the revision that's displayed in either editor here. And you can do that in one of two ways.

You notice at the bottom of the editors, we have jump bars. And when you open those, you see there are many different revisions for this particular file. And if I want to switch to one, I just select. And now it loaded up that revision in the rightmost editor, and it's comparing it to the one on the left. And since it's an older revision, you would expect to see more changes, and there are.

What's really powerful about this, though, is you can select a file not just in the current branch that you're working on. You can select a branch -- a revision from any arbitrary branch in your repository. So this is really powerful stuff. You can do cross-branch comparisons right in Xcode really, really quickly. I do this all the time. It's really great.

So that's one way to change revisions in the comparison view. The other way is using the timeline. All we need to do is bring up the timeline view. And this should be familiar to you from Time Machine. The long bars here represent dates. And the short bars represent revisions. So when I roll over a short bar, I see everything that's relevant about that particular revision. When, who, and why.

And if I want to load that in the editor, I just click. Okay. Let's try that again. There we go. And I've loaded that revision in the side of the editor that I clicked on. So a couple different ways to choose revisions in the comparison editor -- in the comparison view. So we start with that because we're going to see the comparison view in many other contexts in source control. So now let's talk about blame view. Blame view is really powerful.

Well, what does it provide? It shows you who changed each line in the file, when they changed it, and why. And so you can see as I scroll through the file here, I see many changes by Ian, my friend Ian. Commit messages for everything. Well, why is this useful? Isn't this just noise in the editor? Well, it's actually really powerful because if you've ever started editing in a source file, that maybe you haven't edited in before, or you've found -- you've landed on a line of code that you need to edit, and you don't really get what's going on, well, right now, you know exactly who was responsible for that change. So you can get in touch with him right here.

You can see what the message was. At least for me, this really enhances and enriches my editing experience. So something new and very cool that we've added in Xcode 4.1 is you see this little gear icon over here in the blame view? When you click that, you get a little info panel, and it shows you everything that you see in the blame view. This is really great if the commit message is really long. Before in Xcode 4.0, we cut this off. You couldn't copy and paste it. So you can get to the whole thing here.

But you might notice, you can see on the screen up there, that when the info panel is displayed, the editor highlights every line that was changed in that revision. So this is just an incredible way to see the entire scope of change made by a particular revision. And you can see that by clicking the mouse. You can see the whole thing as I scroll and as I scroll down there.

So this is really -- I love it. You notice this right-facing arrow button here? I'll show that to you in the log view. But when I click that, that will actually take me back to the comparison view, so I get that side-by-side view of this file again. So that's blame. And now let's talk about log.

So what does log view provide? Well, this just provides you the entire history of the file, every change that's ever been made in the file. And again, it tells you the important things -- who made the change, when they made the change, and why they made the change.

Well, why is this useful? Well, if you work in a legacy code base, or maybe just a big code base that has -- it's very deep, there are lots of things going on in it, sometimes you command-click and you end up in a file that you've never been in before.

And I find log view really helpful in that case, because if I see that no one has changed the file in five years or ten years, I know it's a pretty good sign that I should get out of there and not change it either. So I talked about this right-facing button here, arrow button, and if I click that, which I'll do here, this will take me back to the comparison view, and it will load up that version of the file in the left-hand editor, and then the version previous to that in the right-most editor. So really quick and easy ways to scrub through the history of a particular source file.

Oh, I forgot to mention the most important thing about this view over here, and about all of these. These are not just read-only views. These are not just toys. They're actually real editors. So you can see over here, again I'm in the comparison view, I see a diff here because there's a change, a difference between these two files. I can delete that right there. It's actually a live editor. I have code completion, I have quick help, I have everything I could expect in the editor. I have the find bar, the jump bar, everything.

And again, you'll see this is useful in other contexts too when we get there. So I encourage you to use the Version editor as your day-to-day editor, because it provides all this rich history of your repository right in the editor. So, we've talked about editing and how Source Control can enhance the editing experience. Now let's talk about committing. You probably commit, well, maybe you commit more than anything else every day.

And how do we do that in Xcode? Well, you might be thinking to yourself, "Why commit from Xcode? Why don't I just keep using Terminal like I've done for years?" Well, if you're like me and you've ever perpetrated a commit blunder, we've all done this, right? You leave in some debug logging statement and your QA person tells you that you slowed your app down by 50%, or you've inadvertently changed a file, committed a file that you didn't mean to, or maybe you've even broken the build.

We do that at Apple, we get in big trouble. It's easy to do these things when you commit from Terminal because especially if you're working on a big task, you might have 25 files, a lot of files, a lot of changes. And when you do a diff on the command line, it's hard to see everything that you've--every change that you've made.

So, but when you do it in Xcode, when you do it in a graphical environment, you get a much better user experience and you can make sure that you're committing exactly what you want. So to do that from Xcode, I'll go to the File menu, I'll select the Source Control submenu and select Commit. So this is the commit sheet.

There are two major parts of it. There's the Navigator area on the left, and there's the Version editor on the right, the comparison view. There are three navigators. The first one is the Project View, and that represents all the files that have some kind of source control status, and it shows them to you as they would appear in the Project Navigator in Xcode, so organized by groups and whatnot. The second navigator is the File System View, and that shows you all the files that have some kind of source control status as they appear in the file system. So the blue folders represent actual directories on disk.

And finally, the third navigator is the flat view, and it just shows you a flat alphabetical list of files. Now, all the navigators have a number of things in common. They all have a column of checkboxes along the left-hand side, and they all have a column of status cells on the right-hand side. Well, what does a checkbox mean? The checkbox means that if it's checked, this file is going to be committed as part of this commit. If it's unchecked, the file will not be.

I'll uncheck my class.h here. And the status cells on the right-hand side show you what kind of change has been made to that particular file. So you're probably familiar with this from the command line tools you use. So A means it's been added, M means it's been modified, and when I select a modified file, I see the change that's made there. We also show you files that are unversioned, so files that your Source Control repository doesn't yet know about.

Those up here with the question mark here. A new feature we've added in Xcode 4.1 is you can actually include that, add that file or directory to the commit just by clicking the checkbox right here. And another thing we've added in Xcode 4.1 is we now show you files in this list that Xcode manages but that don't necessarily appear in the project navigator. So things like your breakpoints file. Whenever you add a breakpoint in Xcode, Xcode keeps track of that in this breakpoints file.

And there's also a user data directory here. Xcode stores some other stuff there. We definitely recommend you add some of this stuff to Source Control and not others. We can talk about that more specifically in the labs. So let's, oh, another thing we added in Xcode 4.1, we have a contextual menu here. So you can discard changes to a particular document and other interesting things. So again, we're in the comparison view. We have that loaded here. And I said before, it's a real editor.

So if you want to add a comment here before you commit, you can do that. Or if you find a log message, like I mentioned before, a very common scenario, you can actually, let's just assume that one is not commented out. You can actually delete that right here before you commit. So this is kind of your last sanity check before you commit these files to your source repository.

So what's going to happen when I press the commit button? Well, Xcode just doesn't blindly commit. It's going to do a number of integrity checks. It's going to make sure that, especially if you're using subversion, that no conflicts will be created by your check-in. So if all goes well, I'm going to add a commit message here. Okay.

If all goes well, when I click the Commit button, these check boxes will turn into green check marks, the sheet will disappear, and I will feel confident that I committed exactly what I wanted to do. So let's commit now. There we go. And you can see the list of files that have Source Control status has gone down dramatically because I've committed a bunch of files, so now my project is back in a clean state.

So that's committing. Now let's talk about viewing history and logs. And we have a number of facilities in Xcode 4 to do that. Well, the first thing I want to do is I want to find the log for the thing that I just did, for the large commit that I just made.

And I can do that from the Logs Navigator right in the Workspace window. So I'll select the Log Navigator, and that's the last log in the list here. And you can see I have a couple of commits that I've made over time to this project. I'll select the topmost one, and I have to be in the standard editor for that to show me the log.

There we go. And so I see a list of all the files that were part of that commit. Now, if it's your team's policy to paste the entire--the full transcript of that commit, maybe in your bug tracking system or something, I commonly do that. You can actually get to the full Git or Subversion transcript right here. You just need to find this button on the right-hand side and that shows you the raw--the full transcript for the commit that we just made.

So, if that's part of your company's workflow, you can get to it there. But there's a much--so that's for--that's viewing the log for the last commit. Wouldn't it be great if we could view history for the entire repository that this project is backed by? Well, of course we can do that in Xcode. We do that in the Repositories Organizer.

I'll go over there, open the Organizer window, make sure the Repositories Organizer is selected. So what do we have here? Well, this is where Xcode displays all the repositories it knows about. How does Xcode learn about a repository? Well, anytime you open a project that's backed by Source Control, Xcode will auto-discover that.

It will figure out what repository is backing it and it will add it to this list over here. You can see I just have one repository in the list right now. I've only opened one project in Xcode. You can also add a repository using the plus button down at the bottom of the window.

We'll go into these branches and remotes more--in more detail later. The blue folder here though, that represents the working--what we call the working copy and that's just the on-disk representation of the repository, of what you've checked out. And this isn't just a static list here. You can actually double-click these things and open them in the appropriate editor. Let me go back and select the top of this repository because we're talking about logs and viewing logs.

So what's over here on the right-hand side? Well, this is a log of the entire repository. So you can see the commit that I just made is right here. And commits that my coworkers have made are also over here. Well, this is actually--there's a lot more here. Let's look at this commit that Kevin made. He just changed one file. And if I want to see all the changes that he made, I can just double-click that.

And what we see here, this looks a lot like the commit sheet. In fact, this looks exactly like the commit sheet would have looked or did look when Kevin made this commit. So I see a list of files over here. In this case, it's just one file. A list of files that was part of this change, the kind of change it was. And again, I see the comparison view over here to see exactly what those differences are.

One of my favorite hidden features here is you can bring up the contextual menu and you can copy the source changes. And this is great if you're suspicious about something in this commit or you have a question and you need to get in touch with that person who made the commit. And in fact, you can do that right from Xcode. You can notice I have a bunch of people paired already. I'm paired. My friend Kerry is paired here because I see his picture. But Kevin, he's just this sad blank man silhouette icon here. He's not yet paired.

I can do that by clicking the icon there, choosing Kevin's card. And what does this mean? Well, now it means right from Xcode, both from the repository organizer and from the blame view, I can get in touch with Kevin. So in this case, I can say, I want to send an email to Kevin.

And I'm going to paste in those changes I just copied from the review file sheet. So this is a really powerful workflow. It's a quick and easy way to learn more about a change a particular person made. Or prove that you made a change that you actually insisted that you did. So there it is. We've talked. I'm going to go back.

There we go. So what have we talked about? We have talked about editing and how your editing experience can be enhanced by Source Control. We talked about committing changes and why Xcode is the best place to do that. We've talked about viewing history and all the different ways you can do that in Xcode. And finally, we've talked about managing repositories. So now that you know all that, you have all the basics you need to know to jump into more advanced topics of Source Control in Xcode. And for that, I'm going to bring up Kevin Lindeman to talk about sharing code.

Thank you, Brent. My name is Kevin, and the first thing I'm going to talk to all of you about today is sharing your code. So I'm sure that all of you at some point have created a new project in Xcode. Starting with Xcode 4, you now have the ability to immediately start using Source Control. Now what does that mean exactly? That means that Xcode will create a Git repository at the base of your new project and commit all the files associated with that project to this new Git repository.

This means that you have immediate access to all of the great Source Control features built into Xcode 4 that we just saw. But now that you have a Git repository, what do you usually want to do with it? Well, you want to be able to configure remotes. So new in Xcode 4.1, we have enabled the ability to configure remotes directly from within the repository organizer. This means now you can share your code. So then you want to push those changes to this remote, and Xcode 4.1 has also improved upon this ability. So why don't we see a quick demo of this? All right, so I'm going to switch to my user.

And here we have the Xcode Welcome Window. So I'm going to create a new project. I just want a Cocoa application, so I'll click Next, and I'm going to name it My Awesome Application. and click the Next button. Now here we see the option for putting this project under Source Control. We want to do this, so I'm going to leave it checked and click Create.

So now we have our new Xcode project, but if I go up to the organizer, And look in the Repositories section, we see that the project that I just created has already been auto-discovered as having a Git repository backing it, including the initial commit that Xcode did of all the files that are part of that project. So now I want to be able to share all of this with my friends. So I've actually created a GitHub repository for my project.

How many of you use GitHub? All right, great. So. says that I need to set up a remote for this URL, so I'm going to copy it and go to the New Remote section in the Repository Organizer. Since this is a new project, we don't actually have any remotes set up yet, so I'm going to click the Add Remote button.

and name it Origin and paste in the URL that I got from GitHub and click Create. So now we have a new remote for our repository. And we see here at the bottom, there's a section listing information about this remote, including a username or password if you need it. So now that I have a remote set up, I want to go back to the workspace and now push all of this content onto GitHub so everyone can have access to it. So I'll go to the File, Source Control, Push menu option.

And now this has changed a little bit in Xcode 4.1. We have seen that we now have this remote that we have set up. And it sees that we have a master branch locally, but not remotely yet. So it gives us the option to create it when we push it. So I will push. And it's pushing the changes. And the push was successful. So now if I go back to GitHub, where it just had all the setup information, and I reload, now all of my new project is up on GitHub.

So now that we've been able to share our project, let's talk a bit about a more advanced topic, branching and merging. First off, branches are great. Your repository is, by nature, a tree. It has a trunk, This is hopefully where you have all of your most stable changes, everything that you want to ship.

But you might want to work on some large feature, or a bug fix. So we can have a couple of branches, a bug fix branch, a task branch, a release branch. These are all things where we go to work on large implementations that we don't want to put on our trunk yet.

So, branches help isolate your changes. By isolating your changes onto a branch, it means that later on when you want to go through and look at all the history that went into making some large feature work, it's all right there in the branch history. If you've been working on the same branch that everyone else is working on, you end up just being confused because all of your commits are intermixed with everyone else's commits.

But then, you can also help reduce regressions by working on branches. If you're working on a branch, you end up being able to less likely destabilize other people's work on their main branch because, you know, who wants to implement some huge thing and, you know, not be completely done at the end of the day and then everyone else is broke for the rest of the day and everyone just gets upset at you.

It also helps simplify code reviews. So if all of your work is on a branch, it means that you can have all of your coworkers just check out your branch, take a look at all the history, build and run your changes, and it's not messing with all of their other work on all of their own branches and on the main trunk.

So let's talk about what one of these task branches that I mentioned looks like at the repository level. So here we have our repository. It has two commits. The blue dots are the commits. And master, as Git would call its main trunk branch, is pointing at the topmost commit, so it has all the content of that commit and all the commits below it. So I can create a task branch, and it starts off with having all the same content as master does at that point. You are branching off of master.

But now I can commit to my task branch and it has a little bit more content than the master branch does. But everyone else can still commit to master and I can commit to task. And then I can merge my task branch into master later on when I know that I'm all done. Now master has all the content of both the task branch and the master branch.

So what am I going to actually show you inside of Xcode? I'm going to show you how you can create branches, how you can switch branches, And then later on we'll talk about how you can end up merging those changes back into your master branch. So in order to show this, this is my repository setup. I have a local Git repository and a remote Git repository. They start off with all of the same content.

I'm going to try building and then see that there's a build error, so I'm going to commit a fix to my local repository that fixes that. I'm just going to do it to master. It's a simple fix. I know that everyone's going to want it right now, so I'm not going to create a branch just yet. But since everyone wants this fix, I'm going to push it up to the remote.

Now I can create my branch and it's going to have that fix right away. And I can commit a few features. And I remember that some of my coworkers wanted to review my changes, so I'm going to push my branch to the remote and notice that it doesn't stomp on all the content of the master branch. I now have my own copy of my Kevin task branch on the remote that everyone can check out. So let's take a look at this.

Launch Xcode. I don't actually want to work on my awesome application anymore. I want to work on my best friend. So I'm going to build, and unfortunately I have some build failures. So I'm kind of curious at why the main master isn't building. You know, it should be the most stable, right? So I'm going to take a look at the Version editor and look in Blame view.

Well, I see that our friend Sarah Lightwater must have just accidentally miscommitted this change. It looks like she was switching to using some new block-based UI view transitions and must have just misspelled this. But now that I looked at Blame, I can talk to her about it later. So we see here that we have a fixit hint, and fixits say that it has a suggestion to fix our problem. So I'm going to take its suggestions because I like it.

So let's try building and running this now. Great, looks like the build succeeded. Alright, so what sort of an application do we have here? It's just a simple tile matching game. There's 16 tiles, 8 different pairs of our best friend. What are our best friends? Our dogs, of course. So if I pick this dog and number 10, it wasn't the same dog, so it flips it back over.

But if I pick the same dog... We see here there's actually a pattern. They kind of appear in all the same spots. If I go all the way to the end, I should have won this game. So I want to make the dogs appear randomly and I also want to make the game winnable.

So that sounds to me like a perfect job for a task branch. So now that I see that it built, I'm going to commit my build failure fix, since everyone wants it. So I bring up the commit sheet, put in a handy dandy commit message, "Fixed build failure," and click the commit button.

All right, the commit is complete, and now I know that everyone wanted this change, so I'm going to push my changes up to the remote. So we see here that since this isn't a new repository, master already exists on the remote, it doesn't give me the option to create, it's just going to push the new changes up that don't exist on the master on the remote yet. So I click push, and the push was successful. Now everyone on our team has access to this new fix.

So now I want to create my branch, so I go to the Repository Organizer, and go to the My Best Friend Repository, and click Branches. So we see that there is a master branch already, but I want to create my own, so I click Add Branch. So it gives us an option to put in a name. I'm going to name it Kevin Task. Now it also asks us what the starting point should be. That means that we are going to branch off of the starting point, and in this case master, since we only have one branch.

If we know that we want to immediately start working on this branch, we can automatically switch this branch once the branch is created, but I want to show you how you can switch otherwise, so I'm not going to select that. I'll click Create, and now we see that the new branch is in the list, and I can even get the history for it. It's all the same history as master since I just branched.

So now if I go to the working copy, the blue folders, there's a switch branch icon here at the bottom right of the repository organizer. If I click that, it says that master is my current branch and that I have a second branch, Kevin Task. I want to switch to that, so I click that one and click OK. We also see up here that the current branch has been updated to Kevin Task for this working copy.

Alright, so now I'm in the perfect spot to start fixing some of these problems. I also remember that in an earlier conversation with Brent, he really didn't like that this "show alternate image" code here, which ends up being called whenever we tap on a tile, is creating an NSRA every time. He says that can be easily solved with a dispatch once.

Now I unfortunately don't remember how the syntax of dispatch once works, what sort of other variables you will need to set it up. So I'm just going to start typing dispatch once. Now we see here that code completion has come up, and it sees that there is a code snippet that it found in our snippet library that we can see based on this icon.

This will set up a dispatch once for us without even having to look at any of the documentation or anything. So I select that one, and it already set up the dispatch_once token for me. And so I want to go in here and make this a static NSRA that starts off as nil, since I'm going to be modifying it inside of the dispatch_once.

And then make the images equal to that array. All right. But images isn't really a good name for this. It's a static NSRA. So I'm going to actually edit all in scope. So now, every time I type, it's editing all uses of this variable inside of the scope. So I want to call that underbar S images. That's one good fix down, so I'm going to commit it. Give it a commit message. "Made show alternate image. Use dispatch once." And click commit.

Now I can go and move on to the meat of my features. So the first thing that I need to do is find the random identifier method that picks where it wants to put the dogs. This doesn't look really random, so I'm going to fix this. Now, I actually fixed this bug earlier, and I made a code snippet for it. So I go into the utilities, scroll down in the code snippet library, and drag in my code snippet.

I don't need this old random identifier. And so this should pair up the dogs completely randomly. So now I need to modify tap tile, which is called whenever the tiles are tapped, so that the game is winnable. So I also have a snippet for that, so I'll drag that one in.

So now, all the features that I wanted should be implemented. Let's give it a quick try. So I'll build it and run it. So 1 and 9, look, it looks like they were different dogs. I'm not very good at this game, especially once it's random, so I'm actually not going to try to win it right now. So I'm just going to commit this. Kerry's going to end up taking a look at this in a minute anyways. So I will commit this. Made the game winnable, also made dogs appear randomly. And click commit.

Now all my code is finished, I want to share this with all my coworkers, so I need to push this new branch up to the remote. So I will go to the File, Source Control, Push menu item again, and it sees that we have Kevin task locally but not remotely.

We have master remotely, so it wouldn't create that, but I want to create a copy of this branch on the remote. So I'm going to push it. And the push was successful. So now all my coworkers have access to this branch and they can take a look at it and review my changes.

So what did we just show you? We showed you how to create new projects and immediately start using Source Control so you can use all the great Source Control features like the Version editor and the Commit sheet. I also talked about how to share your code and how to use branches effectively. So now Kerry Hazelgren will come up and finish our application.

Thanks, Kevin. Hello, everyone. My name is Kerry. And I am going to show you the second half of sharing your code, which is getting changes that other people have made into your repository. Now, as part of this, I'll be showing you a new feature in 4.1, which is how to create a tracking branch, or also known as a remote tracking branch. It's a local branch in your repository that tracks a remote branch in a remote repository. Also going to show you how to resolve conflicts, because whenever you're pulling in changes from other sources, eventually you're going to hit a conflict.

And then I'm also going to share the final results. So this is my local repository, and these are an overview of the changes that I'm going to be making. And in my subsequent demo, I'll show you how to do these things in Xcode 4. So, firstly, I'm going to pull the change that Kevin made, the fix, the build--fix to the build errors that he made on the master branch. Then I'm going to make a new commit of my own. Now, I know the best practice is not to make changes on the master branch, but I'm a manager, that's just how I roll.

So I'm going to pull Kevin's branch. I'm going to create a remote tracking branch which pulls down the contents of his branch into a local branch in my repository. And finally, I will merge the results, resolving any conflicts that might happen, and push the completed app up to our remote.

So let's see how to do that. So we open up Xcode, and I go to my copy of my best friend. Now, the first thing I need to do is pull Kevin's fix. So I go to File, Source Control. Pull. And we see that I'm going to pull from Origin Master.

The poll was successful, so I should be able to build now. Great. Now the change that I'm going to make is to make the game winnable. Now I know, you're probably thinking, didn't Kevin already do that? Well, he did, but I was out of the office. I think I went golfing. I took a long lunch. I took my dog for a walk and forgot that I had told him to do that.

So I'm going to make a change in the same location. Now, this is actually a very common scenario where you've got groups of people working together. We're editing the same source code, and a conflict happens. So I'm going to drag in a snippet of code here. Similar to the one Kevin did, But it'll make the game winnable.

And just go ahead and commit that change, because, again, I'm a manager. I know you guys test and build and run your code, but I'm just going to go ahead and commit it. Now, the thing that I need to do next is to create a remote tracking branch. And I'll show you how to do that, because that's new in Xcode 4.1.

So what I do is I go to the Organizer and Repositories tab and select Remotes. Firstly, actually, let me show you, if we look at our branches, our local branches, I only have one. That's the master branch. But if I select my origin remote and open it up, I can see that on the remote there are two branches.

So Kevin Task is the one that I want to track. So I just select it and then come down here and say Track Branch. Now I can give it a different name if I want, but I'll just leave it the same. And I do not want to switch to this branch because I'm going to merge it into my current branch. So I click Create. And if I go back to branches, I can see that it's already there.

Now I am ready to merge it. So I go to File, Source Control, Merge. And the way that merging works in Xcode is that you always merge the branch that you select into your current branch. And the UI here reminds me that my current branch is on master. So I'm merging Kevin Task into the master branch. I'll hit Choose there. And what we see looks very similar to the commit UI with some important differences.

First thing I notice is that next to my file name here, I have this red C marker, status indicator. And that means that in this file, there is at least one conflict. And I can see that conflict here in the Version editor because it's highlighted in red rather than the normal blue.

Another important difference is that on the left-hand side, this is not my local document. This is actually the merged document. It's the document that you will have once the merge is completed. So why do we show you that? Well, the idea is that you will edit this document and resolve your merges however you want so that the final result is the way the document will be or the way that you want it to be when the merge is done.

Now, you're probably thinking, "Wait a second. How can there be conflicts when we haven't even merged yet?" Now, this is an important distinction that Xcode makes over any other tool you probably have used. For example, if you go to the command line and do a Subversion update, the update will-- Operation will complete and then you'll have conflicts in your source code.

Like these funky little chevron characters that stop your project from building or your source code from compiling. Xcode 4 has the ability to identify conflicts that would occur and asks you to resolve them ahead of time so that you get no conflicts when you're done. So the end result is if you always update, pull, or merge from Xcode, you will never get a conflict in your source code.

Okay, so how do we actually resolve this merge? There's a little question mark here in the middle, and this is Xcode saying, "You haven't yet made a decision on how you want to resolve it." There's one of four different ways that you can do that, represented by the segmented control here at the bottom.

You can choose right, meaning the changes that are incoming, and if I choose that, I can see that the changes on the right are reflected in my merged document. Or, of course, I can choose left, meaning my own changes. I can also choose both of them, left then right, in that order, or right then left.

And for those of you who like to use arrow keys, the arrow keys work. If you hit left, it'll choose the left, left, left, hitting the arrow key twice, chooses left then right, and vice versa for the right side. So as far as this conflict's concerned, I'm going to choose my changes because I like my changes. Once the conflicts are all resolved, then I can merge. Okay. So now we should be able to build and run and win the game, though I may need some of your help to do so.

Clicking at random here. Oh, one and two. There we go.

For my last act, I will just push these changes all up to the remote repository. Here we go. Yay, now we can submit it to the App Store. Okay, so what I just showed you, showed you how to create a remote tracking branch so that you can grab code from remote branches on a remote repository. How to resolve conflicts, very important. And how to share the final results.

So in conclusion, what have we learned today? I think we've shown that Xcode contains some very powerful Source Control features, and yet they work with you, and they're very easy to use. You can easily share code with others by configuring multiple remotes that you can push and pull from multiple repositories and really take advantage of the distributed nature of Git.

also showed you how branching works in Xcode. And branching, if you've been afraid of using branching in the past, I think you should give Xcode a try in its branching workflow because it's really very powerful and you don't, you know, you want to be isolating your changes on a branch and not breaking your coworkers. And also we showed you how Xcode lets you eliminate conflicts before they actually happen. It's amazing. Let's see Terminal do that. For more information, you can contact Michael Jurowicz. He's our Developer Tools evangelist. Thank you very much.