Just to review, in our last video we set up a GitHub account, created a new repo,

added our new Xcode project, made commits, explored GitHub and pulled some changes.

Now, we'll pretend that we're working on a collaborative project and

we'll need to be creating branches and merging.

So, like I said, we're collaborating on a project.

Now in a second, I'll open that project and we'll take it from there.

But first I'd like to spell out what we'll be doing.

First, we'll create our own new branch to work in.

After we make some changes to that branch, we'll eventually wanna merge any

recent changes our team has committed and pushed into our branch.

Just to illustrate a point, I'll be sure we have some merge conflicts, so

we can see how to resolve them.

Now, just to be clear, branching, merging and

resolving conflicts aren't processes that only happen collaboratively.

Generally, when you have more developers working on the same code base, you'll need

more branches to keep everyone moving forward without disrupting each other,

which in turn, will mean more merges and perhaps more conflicts to be resolved.

But creating new branches is absolutely something you should put to use,

even on solo projects.

Doing so allows for a very clean and safe segregation of your code and is often much

better suited to experimentation, feature enhancement, and more.

For example, I recently had an old app that I hadn't touched in years.

It sells on the App Store, but

doesn't make enough money to warrant any new feature enhancements.

When the Apple TV came out, I thought it made sense to try and rework the app for

a living room experience.

The first step in that process was creating a new tvOS branch

that allowed us to benefit from all the work that had all ready been done and

not worry that our new changes would jeopardize the existing code.

Surely, when trying to build an Apple TV app,

which was uncharted territory at the time,

we'd probably end up breaking our existing app and there was no reason to risk that.

Also, down the road, once our tvOS app is done, we could in theory, merge it

back into the original to create a single universal app if that indeed made sense.

So, like I mentioned before, I've been asked to collaborate on a project.

I've been sent the link to the Git repo, so let's check out an existing project.

That replaced window just popped up because I demoed this myself beforehand,

but that's not gonna pop up for you on a real project.

Now this app is called Potluck and it's just a sample app provided by Apple.

You can download the code.

By the way I'm only creating this repo as a temporary demo for

you also don't go looking for it on GitHub.

If you want your very own copy, I've supplied the link below.

Anyway we can run the app

And it's nothing too exciting here.

It's a location based app, and I'm running in the simulator.

Let's just click this button, and we see the text changes up here.

Location manager updating.

Okay, now I've been tasked with improving the text user C on the home screen.

The team leader has said that this feature is number 8675309.

We're gonna quit our sim.

Now, let's go up and create ourselves a new branch.

Since we have a feature number, we're gonna do that.

Now, Xcode assumes that when you create a new branch you'll want to use that as your

working copy, so that's where I am.

You can confirm that by going to source control and now you see the repo

followed by the branch here that we created Feature 8675309.

If I wanted to, I could switch back to the master branch,

by clicking Switch to Branch and then I'd have that choice.

Okay, so my task was to change the text and improve on it.

Let's see if we can find that.

So right here, in our view controller, we see we've got some strings here.

Location manager updating.

I don't love that.

Let's change that a little bit.

It sounds redundant, we know it's a location manager.

Let's just call it Manager updating.

We'll also change this second one just to manager updating.

I'm gonna save my file.

And now you'll see, this little M showed up here.

That indicates that the file, this file has been modified.

Once I commit, like this,

You'll see the M has gone away.

Those Ms by the way can be very helpful if your code just suddenly stops working and

you aren't sure what you may have broken.

Assuming that you saved but didn't yet commit, it's a good place to look for

first clues.

Now let's pretend that that's the only change we need to make and

that I've already tested the app.

I've spoken with the team lead and they say they definitely don't want me to merge

my new changes back in the master yet.

However, they do want to make sure that my changes jibe nicely with

anything else that may have changed in master.

The way we can do this is by merging master into my branch.

Now of course I just created this branch a second ago.

So there probably aren't any changes to master yet.

Just for kicks, I'm going to hop in to GitHub and make a change.

Now here you see that I'm in GitHub and I'm looking at the same repo.

But I'm not me, I'm this other guy, whynoserous who looks suspiciously

like me, and I'm gonna change one of the things that we changed in Xcode.

So this is like a collaborator on the project changing the repo.

Now they're still gonna be working in the master branch,

And we'll update that first string that we updated before.

And of course we'll have to go back down and

commit In real life

your collaborators would be doing this in Xcode probably not right on GitHub.

But this just shows you that someone else on the team is doing it and

now our work flow will continue inside Xcode.

So here back inside, we wanna make sure our branch is up to date as possible.

We'll eventually wanna merge our changes back into master.

But for now we wanna merge master into our branch.

That helps test for compatibility.

And it also means that when the time comes to merge our changes back into master,

there won't be as many differences to present potential problems

since we already have many of those changes in our branch.

Okay, so let's merge.

We can see here that we can merge from a branch

into our branch, and we can do that from master.

There are no changes to merge from the branch master.

Well why is that happening?

That's right.

The reason that's happening is cause we haven't pulled the changes.

AKA those changes that I just made when I was pretending to be whynoseros pn GitHub.

They only exist on the remote.

They don't exist on my local repo.

To pull those, what we need to first do is switch to that branch.

And then we can pull.

When we do that You'll see that it's updated to what we entered on GitHub.

Now we can merge the master into our branch.

Remember this is not the same thing as merging our branch into master.

When you merge you're only changing the branch you merge into,

the other branch remains unchanged.

Okay, here we are.

But our merge button is grayed out and we have this red C icon over here.

Red icons are almost never good.

And as you might have guessed, that red icon is the reason we can't merge.

The C stands for conflict by the way.

Git, in its magical wisdom has decided that there are changes in the two branches

that relate to the same code and it can't figure out which code to keep.

Let's click on it.

If you notice, one of the changes seems fine and isn't showing a conflict.

This one down here.

That's because we never change that line in our master branch.

So Git assumes that the line that we changed

over here locally is the one we want going forward.

That said, I could still overwrite it in my branch by clicking here.

But I won't do that.

We'll just leave it.

Now, up here, where we have the question mark, that's our conflict.

You can resolve it in four ways using these buttons down here.

Starting from the left,

this will keep both lines with the working copy change up top.

The next button just keeps the working copy.

By working copy of course I mean the branch we're in, 8675309.

The next two buttons would keep just the master version.

And lastly it would keep both versions with the master as first.

Now at the beginning I mentioned there is much more you can do with Git.

I absolutely encourage you to take the complete tree house Git

course linked below but it is lengthy and for the time being you may be more

concerned with getting up and running and using X code safely and collaboratively.

To that end I'll bring our workshop to a close by showing just a few more things

you can do here inside of X code.

So let's merge this, so the first is viewing version history.

One way to do that is simply to go to source control history,

And inside, we see a list of all the commits to this branch.

It shows them in reverse chronological order along with who made the commit, and

a timestamp, shaw, and if you click this

right here where it says how many files were modified you can get a list of them.

Now when you're in here.

You can't edit.

But you can copy code out of here and

paste it back into the editor if that's useful.

You can also send an email to one of your collaborators if you'd like.

Now speaking of older versions which we might have down here.

Sometimes you'll find changes that you made aren't what you actually want.

Maybe they broke something else in the code or

perhaps you were just tinkering and you want to go back.

Well if you haven't yet committed those changes.

You can head to Source C>Discard All Changes.

If you do that the changes are gone.

But what if the changes you wanna get rid of have already been committed or

what if you want to get back to some state your code was in six commits ago?

To do that we're gonna use the version editor.

We'll head to view Version editor, comparison view.

Once here you can compare different commits by tapping on the clock icon or

using your menu down here

And then you can scroll through.

And see your changes.

You'll notice on the right side here we have these little horizontal lines which

indicate where changes that's a very helpful when you have a very long file and

you're not sure changes are.

By the way they disappear when you're not scrolling.

So you have to start scrolling again to see them.

When we see changes here we can get at them by hiding the center panel.

And then, you have some choices here, they're grayed out now but

often you can discard your changes.

Let's find a more recent one and see if we can do just that?

Okay here we go.

Let's discard that recent change.

If we go back to our traditional editor.

We're going to see that now we have an M here.

Since we discarded that change, we now have a modified file.

But we didn't commit it yet.

So of course we could still commit or discard that most recent update.

So just for fun let's commit that change.

And again we're just committing the changes in this file right here.

Our M should disappear.

That's good.

Not just for fun.

Let's head to our history again.

So what we see now is that we have a recent commit, the commit we made

at the beginning of our lesson and then a whole bunch of old commits.

Again just to be clear we didn't rewind our code to that point in time and

lose everything that happened since.

We simply discarded the old change and made a new commit.

This gives us a lot more safety and

transparency, if we ever need to go investigating these changes in the future.

By the way if you ever find that you want to revert your entire project,

you won't be able to do that in Xcode in unless you go file by file.

To revert in one fell swoop.

You'll want to either work from terminal, GitHub or GitHub desktop client.

If command line reverts interest you, I've supplied a link on that below.

I hope you found this intro to get in lightning using a VCS like get

is an essential part of working as a developer either independently or

on a team We've given you the basic tools and processes here but

there's plenty more you can learn in our full Git course linked below.

I would strongly suggest you make time to work through that when the time is right

as future employers may expect you to be comfortable using git on the command line

or taking advantage of more advanced features.

Until then have fun with your repos, branches, commits, and

merges it's a way of life.

See you soon