Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
We'll continue with our GitHub project in Xcode, but this time focus on the collaborative aspects of using git. Specifically, we'll: create a branch, make commits, merge branches and resolve conflicts.
-
0:00
Just to review, in our last video we set up a GitHub account, created a new repo,
-
0:05
added our new Xcode project, made commits, explored GitHub and pulled some changes.
-
0:11
Now, we'll pretend that we're working on a collaborative project and
-
0:14
we'll need to be creating branches and merging.
-
0:17
So, like I said, we're collaborating on a project.
-
0:20
Now in a second, I'll open that project and we'll take it from there.
-
0:23
But first I'd like to spell out what we'll be doing.
-
0:26
First, we'll create our own new branch to work in.
-
0:28
After we make some changes to that branch, we'll eventually wanna merge any
-
0:32
recent changes our team has committed and pushed into our branch.
-
0:37
Just to illustrate a point, I'll be sure we have some merge conflicts, so
-
0:40
we can see how to resolve them.
-
0:42
Now, just to be clear, branching, merging and
-
0:44
resolving conflicts aren't processes that only happen collaboratively.
-
0:49
Generally, when you have more developers working on the same code base, you'll need
-
0:52
more branches to keep everyone moving forward without disrupting each other,
-
0:56
which in turn, will mean more merges and perhaps more conflicts to be resolved.
-
1:00
But creating new branches is absolutely something you should put to use,
-
1:04
even on solo projects.
-
1:06
Doing so allows for a very clean and safe segregation of your code and is often much
-
1:10
better suited to experimentation, feature enhancement, and more.
-
1:15
For example, I recently had an old app that I hadn't touched in years.
-
1:19
It sells on the App Store, but
-
1:20
doesn't make enough money to warrant any new feature enhancements.
-
1:23
When the Apple TV came out, I thought it made sense to try and rework the app for
-
1:27
a living room experience.
-
1:29
The first step in that process was creating a new tvOS branch
-
1:32
that allowed us to benefit from all the work that had all ready been done and
-
1:35
not worry that our new changes would jeopardize the existing code.
-
1:40
Surely, when trying to build an Apple TV app,
-
1:42
which was uncharted territory at the time,
-
1:44
we'd probably end up breaking our existing app and there was no reason to risk that.
-
1:48
Also, down the road, once our tvOS app is done, we could in theory, merge it
-
1:53
back into the original to create a single universal app if that indeed made sense.
-
1:59
So, like I mentioned before, I've been asked to collaborate on a project.
-
2:02
I've been sent the link to the Git repo, so let's check out an existing project.
-
2:16
That replaced window just popped up because I demoed this myself beforehand,
-
2:20
but that's not gonna pop up for you on a real project.
-
2:24
Now this app is called Potluck and it's just a sample app provided by Apple.
-
2:28
You can download the code.
-
2:30
By the way I'm only creating this repo as a temporary demo for
-
2:33
you also don't go looking for it on GitHub.
-
2:35
If you want your very own copy, I've supplied the link below.
-
2:38
Anyway we can run the app
-
2:51
And it's nothing too exciting here.
-
2:53
It's a location based app, and I'm running in the simulator.
-
2:56
Let's just click this button, and we see the text changes up here.
-
3:03
Location manager updating.
-
3:07
Okay, now I've been tasked with improving the text user C on the home screen.
-
3:13
The team leader has said that this feature is number 8675309.
-
3:16
We're gonna quit our sim.
-
3:20
Now, let's go up and create ourselves a new branch.
-
3:23
Since we have a feature number, we're gonna do that.
-
3:34
Now, Xcode assumes that when you create a new branch you'll want to use that as your
-
3:38
working copy, so that's where I am.
-
3:41
You can confirm that by going to source control and now you see the repo
-
3:45
followed by the branch here that we created Feature 8675309.
-
3:47
If I wanted to, I could switch back to the master branch,
-
3:53
by clicking Switch to Branch and then I'd have that choice.
-
3:57
Okay, so my task was to change the text and improve on it.
-
4:01
Let's see if we can find that.
-
4:05
So right here, in our view controller, we see we've got some strings here.
-
4:11
Location manager updating.
-
4:16
I don't love that.
-
4:17
Let's change that a little bit.
-
4:18
It sounds redundant, we know it's a location manager.
-
4:21
Let's just call it Manager updating.
-
4:25
We'll also change this second one just to manager updating.
-
4:28
I'm gonna save my file.
-
4:32
And now you'll see, this little M showed up here.
-
4:35
That indicates that the file, this file has been modified.
-
4:40
Once I commit, like this,
-
4:52
You'll see the M has gone away.
-
4:54
Those Ms by the way can be very helpful if your code just suddenly stops working and
-
4:59
you aren't sure what you may have broken.
-
5:01
Assuming that you saved but didn't yet commit, it's a good place to look for
-
5:05
first clues.
-
5:07
Now let's pretend that that's the only change we need to make and
-
5:10
that I've already tested the app.
-
5:12
I've spoken with the team lead and they say they definitely don't want me to merge
-
5:16
my new changes back in the master yet.
-
5:19
However, they do want to make sure that my changes jibe nicely with
-
5:23
anything else that may have changed in master.
-
5:26
The way we can do this is by merging master into my branch.
-
5:31
Now of course I just created this branch a second ago.
-
5:34
So there probably aren't any changes to master yet.
-
5:37
Just for kicks, I'm going to hop in to GitHub and make a change.
-
5:42
Now here you see that I'm in GitHub and I'm looking at the same repo.
-
5:46
But I'm not me, I'm this other guy, whynoserous who looks suspiciously
-
5:50
like me, and I'm gonna change one of the things that we changed in Xcode.
-
5:55
So this is like a collaborator on the project changing the repo.
-
5:59
Now they're still gonna be working in the master branch,
-
6:15
And we'll update that first string that we updated before.
-
6:20
And of course we'll have to go back down and
-
6:23
commit In real life
-
6:29
your collaborators would be doing this in Xcode probably not right on GitHub.
-
6:33
But this just shows you that someone else on the team is doing it and
-
6:37
now our work flow will continue inside Xcode.
-
6:40
So here back inside, we wanna make sure our branch is up to date as possible.
-
6:47
We'll eventually wanna merge our changes back into master.
-
6:51
But for now we wanna merge master into our branch.
-
6:54
That helps test for compatibility.
-
6:56
And it also means that when the time comes to merge our changes back into master,
-
7:01
there won't be as many differences to present potential problems
-
7:04
since we already have many of those changes in our branch.
-
7:08
Okay, so let's merge.
-
7:11
We can see here that we can merge from a branch
-
7:16
into our branch, and we can do that from master.
-
7:24
There are no changes to merge from the branch master.
-
7:27
Well why is that happening?
-
7:30
That's right.
-
7:31
The reason that's happening is cause we haven't pulled the changes.
-
7:34
AKA those changes that I just made when I was pretending to be whynoseros pn GitHub.
-
7:39
They only exist on the remote.
-
7:41
They don't exist on my local repo.
-
7:44
To pull those, what we need to first do is switch to that branch.
-
7:55
And then we can pull.
-
7:58
When we do that You'll see that it's updated to what we entered on GitHub.
-
8:06
Now we can merge the master into our branch.
-
8:09
Remember this is not the same thing as merging our branch into master.
-
8:13
When you merge you're only changing the branch you merge into,
-
8:16
the other branch remains unchanged.
-
8:32
Okay, here we are.
-
8:34
But our merge button is grayed out and we have this red C icon over here.
-
8:41
Red icons are almost never good.
-
8:43
And as you might have guessed, that red icon is the reason we can't merge.
-
8:48
The C stands for conflict by the way.
-
8:51
Git, in its magical wisdom has decided that there are changes in the two branches
-
8:55
that relate to the same code and it can't figure out which code to keep.
-
8:59
Let's click on it.
-
9:01
If you notice, one of the changes seems fine and isn't showing a conflict.
-
9:05
This one down here.
-
9:07
That's because we never change that line in our master branch.
-
9:10
So Git assumes that the line that we changed
-
9:13
over here locally is the one we want going forward.
-
9:17
That said, I could still overwrite it in my branch by clicking here.
-
9:25
But I won't do that.
-
9:27
We'll just leave it.
-
9:29
Now, up here, where we have the question mark, that's our conflict.
-
9:33
You can resolve it in four ways using these buttons down here.
-
9:38
Starting from the left,
-
9:40
this will keep both lines with the working copy change up top.
-
9:44
The next button just keeps the working copy.
-
9:47
By working copy of course I mean the branch we're in, 8675309.
-
9:50
The next two buttons would keep just the master version.
-
9:55
And lastly it would keep both versions with the master as first.
-
9:59
Now at the beginning I mentioned there is much more you can do with Git.
-
10:03
I absolutely encourage you to take the complete tree house Git
-
10:06
course linked below but it is lengthy and for the time being you may be more
-
10:10
concerned with getting up and running and using X code safely and collaboratively.
-
10:14
To that end I'll bring our workshop to a close by showing just a few more things
-
10:18
you can do here inside of X code.
-
10:21
So let's merge this, so the first is viewing version history.
-
10:26
One way to do that is simply to go to source control history,
-
10:32
And inside, we see a list of all the commits to this branch.
-
10:36
It shows them in reverse chronological order along with who made the commit, and
-
10:41
a timestamp, shaw, and if you click this
-
10:45
right here where it says how many files were modified you can get a list of them.
-
10:52
Now when you're in here.
-
10:54
You can't edit.
-
10:55
But you can copy code out of here and
-
10:57
paste it back into the editor if that's useful.
-
11:00
You can also send an email to one of your collaborators if you'd like.
-
11:07
Now speaking of older versions which we might have down here.
-
11:10
Sometimes you'll find changes that you made aren't what you actually want.
-
11:15
Maybe they broke something else in the code or
-
11:17
perhaps you were just tinkering and you want to go back.
-
11:20
Well if you haven't yet committed those changes.
-
11:23
You can head to Source C>Discard All Changes.
-
11:28
If you do that the changes are gone.
-
11:31
But what if the changes you wanna get rid of have already been committed or
-
11:35
what if you want to get back to some state your code was in six commits ago?
-
11:39
To do that we're gonna use the version editor.
-
11:42
We'll head to view Version editor, comparison view.
-
11:49
Once here you can compare different commits by tapping on the clock icon or
-
11:55
using your menu down here
-
12:07
And then you can scroll through.
-
12:09
And see your changes.
-
12:11
You'll notice on the right side here we have these little horizontal lines which
-
12:15
indicate where changes that's a very helpful when you have a very long file and
-
12:19
you're not sure changes are.
-
12:21
By the way they disappear when you're not scrolling.
-
12:23
So you have to start scrolling again to see them.
-
12:26
When we see changes here we can get at them by hiding the center panel.
-
12:30
And then, you have some choices here, they're grayed out now but
-
12:33
often you can discard your changes.
-
12:36
Let's find a more recent one and see if we can do just that?
-
12:48
Okay here we go.
-
12:50
Let's discard that recent change.
-
12:54
If we go back to our traditional editor.
-
12:58
We're going to see that now we have an M here.
-
13:01
Since we discarded that change, we now have a modified file.
-
13:05
But we didn't commit it yet.
-
13:07
So of course we could still commit or discard that most recent update.
-
13:12
So just for fun let's commit that change.
-
13:22
And again we're just committing the changes in this file right here.
-
13:29
Our M should disappear.
-
13:31
That's good.
-
13:32
Not just for fun.
-
13:34
Let's head to our history again.
-
13:38
So what we see now is that we have a recent commit, the commit we made
-
13:42
at the beginning of our lesson and then a whole bunch of old commits.
-
13:48
Again just to be clear we didn't rewind our code to that point in time and
-
13:52
lose everything that happened since.
-
13:55
We simply discarded the old change and made a new commit.
-
13:58
This gives us a lot more safety and
-
13:59
transparency, if we ever need to go investigating these changes in the future.
-
14:04
By the way if you ever find that you want to revert your entire project,
-
14:08
you won't be able to do that in Xcode in unless you go file by file.
-
14:12
To revert in one fell swoop.
-
14:14
You'll want to either work from terminal, GitHub or GitHub desktop client.
-
14:19
If command line reverts interest you, I've supplied a link on that below.
-
14:24
I hope you found this intro to get in lightning using a VCS like get
-
14:27
is an essential part of working as a developer either independently or
-
14:30
on a team We've given you the basic tools and processes here but
-
14:34
there's plenty more you can learn in our full Git course linked below.
-
14:37
I would strongly suggest you make time to work through that when the time is right
-
14:41
as future employers may expect you to be comfortable using git on the command line
-
14:45
or taking advantage of more advanced features.
-
14:48
Until then have fun with your repos, branches, commits, and
-
14:51
merges it's a way of life.
-
14:53
See you soon
You need to sign up for Treehouse in order to download course files.
Sign up