So in the last few lessons we looked at implementing source control locally using the command line as
well as using Xcode and also remotely using GitHub.
So now I want to take you a little bit further and I want to talk about collaboration using remote repositories
and GitHub because this is one of the best ways to start working in a team of programmers and to contribute
your skills to open source projects.
So we've seen all of these four areas, the working directory, the staging area, the local repository as
well as the remote repository.
And you should be pretty familiar with all four of these areas by now.
Now in the next scenario let's shift over to just look at the local and remote repository that you own.
So let's say that Angela
so myself, I own this repository.
I created it locally and then I pushed it to my remote repository on GitHub.
Now let's say that I have an evil twin who's called, I don't know,
Bangela, that's a terrible name.
Let's say that she also wanted to make changes to my repository.
She looking at my code base
and you know she wants to add some features or fix some bugs or do something.
Now because I own this remote repository over here, in order for her to work on it she could make a copy
of it that exists on her GitHub account.
So remember this is different from git clone. Git clone is just grabbing at the entirety of the repository
and then cloning it to your local work environment.
Now in this case we're basically just copying a repository that's hosted on GitHub and we're keeping
the copy under our own GitHub account where we can make changes to it.
So this in terms of GitHub lingo is called forking.
Now once you fork a remote repository, then you now own it. You have full permissions to do whatever
it is that you like with this copy of the repository.
Because as you can imagine, it would be pretty crazy if everybody could modify your source code on all
of your open source repositories because you know it would lead to maybe amateurs changing all sorts
of things that you don't want them to or you know people making features that are incompatible with
what you've got already.
Basically you'd only give people who you have a trusting relationship with write access to your remote
repository.
So say if you work within a team and you're all working on a product then everybody in the team probably
has both read and write permissions on a single remote repository.
And that way they can get clone and work on it locally and then push it and resolve any sort of conflicts
that way.
But you don't want anybody on the Internet having those kind of permissions.
So how do you implement this kind of open source collaboration then?
Well it's through forking and making pull requests.
So now let's say that evil Angela, Bangela, has forked my repository.
So on her GitHub account she now owns a copy of my repository.
And from this point she can then clone that repository to work on it locally.
And if she decides to add some features to it maybe you know improve the code base or add some more
code or do something crazy or whatever it is that she wants,
then after she's happy with that and she's committed those changes then she can push it to her remote
repository and then if she wants me or good Angela to incorporate those changes that she made, then the
only option is to make a pull request if she is not within that trusted pool of people who all have
read and write access to my remote repository.
So say if she only has read access, then she would have to make a pull request and it's almost like making
a suggestion. Here are some suggested changes that I've been working on,
what do you think about it? If you ok it, then please you know merge it to your remote repository.
So the reason why its called a pull request and not a push request is because the person who has the
right permission to the repository,
so I have write permission to my own remote repository which has been forked and duplicated by you know
my evil twin.
If she wants to incorporate those changes then I have the deciding vote.
So I can review those changes and I can pull the changes over.
So its not a push because you don't own the rights to the remote repository that you're trying to push
to.
In this case if I decide after code review that actually those features actually added were pretty great
and it seems compatible with my code so far and doesn't break anything, then I would approve the pull
request and merge her repository with my own.
So the changes will be reflected in a new commit.
So let's take a look at this in action.
So here we've got our original story repository,
so this is a remote repository remember because it's hosted online on on GitHub, and we've got a number
of commits and we've been doing some modifications and writing to write our story line.
Now I'm going to log out of my account.
So that was the account that created the story.
And then I'm going to sign in using a different account.
So right now I'm signed into a different GitHub account.
This account is named gilfoyleismyothername.
And now I'm going to search for that repository.
So I found the story repository by the user Angela Bauer.
So that was the one that we saw earlier on.
So I'm going to go into this repository and you can see that all of these lines and files are publicly
visible and you can read through all of it even though you are now not signed in to the account that
created this repository.
So from here what I'm going to do is I'm going to fork this repository.
So as we mentioned before, forking is simply making a copy or a duplicate of a remote repository and
putting it under your own GitHub account. So that you can see this user that I've created is called
gilfoyleismyothername
and now I have this repository under my own username.
So I've made a copy of it and you can see it's exactly the same as before.
Everything's been copied over including all of the previous commits that were made.
So now from here, I'm going to go-- From here
I'm going to make some changes.
So let's maybe change one of these storylines. So let's change chapter 4.
So let's say that this other user, this other person, has some suggested improvements to my code or
in this case to my writing.
They're still keeping the spirit of the original repository alive because we are now converting into
a space theme or an alien theme.
So I've made my changes to chapter r and I'm going to commit those changes saying, 'Add more space
theme to chapter 4.'
So that's what I did and I'm going to commit to the master branch.
This is the master branch of my own forked copy of the story repository.
So once I commit those changes then we can view what it currently looks like and the graphs.
So if we have a look at the network, you can see that this is the point where I forked the story repository.
And that commit was created by Angela Yu which basically merged this branch to the master branch.
So we did that two lessons back if you remember.
So the latest commit though is made by this current user, gilfoyleismyothername, and you can see that
I've added it to the master branch of my forked copy of that repository.
So say if I now open up a incognito window and I log back in to the Angela account and go over to that
story repository, you can see that if I have a look inside my graphs, go into network, that that latest change
is not reflected on my master branch.
It's showing up as a separate branch made by gilfoyleismyothername.
And you can see the members who have forked your repositry.
So this is a great way of collaborating because you can have contributors make edits or add new features
to your preexisting code base or repository.
And now what I can do if I head back to the Gilfoyle account, so I'm just going to flip through these
two so that you can see right now I'm inside the Gilfoyle accounts and this is the Angela Bauer account.
So now under the Gilfoyle account what I can do is I can make a pull request, so we can do that here.
And you can see that it's able to merge.
And these are the changes.
So swapping that word for that word, swapping that word for that phrase.
So now all I have to do is hit create pull request and tell the original author which is Angela Bauer
what I've done, why I think my modifications or my features are worthy to be merged with the original
repository,
and you know any of the notes
right?
Any other comments that I have.
Let's just say...
Always helps to be complimentary.
So now let's go ahead and create a pull request.
So the pull request is done
but if we have a look back into the story repository you can see that those changes are not made right?
It's because I don't own this repository. I don't have write access,
I only have read access as a member of the general public and not a member of the trusted inner circle.
So I can only suggest my changes.
Now if we head over back to the Angela Bauer account who owns this repository,
now if I have a look under pull requests, I've got a brand new pull request right?
So it previously was zero
but now I have one and it's showing us one open pull request and this is added a minute ago by Gilfoyle.
And if I look at, it I can see why he thinks that this modification is necessary
and what were his commit message.
And I can also take a look at the commits that he made and compared the differences,
so review those changes.
So I could say something like,
'Great job!
Great job
Gilfoyle and I can submit this feedback to Gilfoyle and approve merging these changes.
So now all I have to do is hit merge pull request and maybe add a 'Merged from Gilfoyle's modifications
to chapter 4'.
OK.
So let's go ahead and confirm the merge. And now you can see that that commit is added to Angela Bauer
master.
So if I have a look inside my graphs now you can see that the latest commit was my merge and it
was and you can see where it came from.
It came from a fork made by Gilfoyle which shows up as a separate branch and then it got merged back
into the main branch of the main repository.
So some people use GitHub purely as version control for their own projects and use some of the features
that we discussed in previous lessons.
But there's also a huge community of awesome coders on here who have created really brilliant projects.
And if you can see ways of improving it or contributing to it then it's a great way of starting to
learn how to work in a team of programmers which is a really essential skill when you're working for
a startup or for a company.
So for example if we have a look at the Alamofire repository which is something that we've been using
for quite a while, if you have a look at the contributions you can see that there have been loads and
loads of other users who have looked at the code and done things you know or made suggestions and to
steadily improve this framework that you know everybody else is benefiting off
right?
You can see that a total of 4300 forks have been made and there's currently 4 open pull requests
but 559 pull requests were closed.
So let's have a look.
So for example in this case this guy updated the readme to the current version.
So that's obviously just editing a text file
and that's pretty much within anybody's capabilities right?
And then it got merged by somebody who owned this repository.
And you know they gave them a bit of feedback back right?
But there's other things like you know code additions or code deletions or modifications that people
have made.
So this guy made some fixes and you know he's documented what were the goals what are the implementation
details,
what were the tests that he performed
and then the guy who owned the repository said, 'Hey just, you know, maybe one thing that you need to change.
Have a look in here.'
And then once it was changed then it was approved and merged with the master branch.
So have a look around on GitHub and see what are some of the cool projects that you could maybe get
involved in.
So to begin with you know some of these things that we've been using for example progress HUD
right?
We've been using inside Quizzler.
You can actually have a look inside the code files and see, you know, what are the things that you would
change about it.
Obviously progress HUD is written in Objective-C, maybe choose one that is written in Swift. But have
a look at the libraries that you've been using
and if you want
you can build on top of it either for your own goals and purposes but also you know if you're building
on top of somebody else's open source code then it's a nice thing to contribute back to the open source
world by forking and making a pull request to offer your improvements or bug fixes or new features.
So as I said, it's almost like a social network for programmers and you can make a lot of great friends
on here and you can also get a lot of help on here in your development journey.
So the last thing that I wanted to say was that in this module I've mentioned a lot of different Git
Hub or Git commands and it can be quite difficult to remember all of it just by watching these videos
once.
So remember you always have these videos so you can always come back and listen to my terrible jokes
hum.
But also the information again.
So you can always re watch it and refresh yourself.
But I've actually made a PDF cheat sheet of some of the most common
Git and GitHub commands that you'll be using.
And I've laid it all out in terms of arrows that we've explained before so that you'll know what I'm
talking about and you can download this PDF inside this lesson.
So I hope you enjoyed all of that and I will see you on the next lesson.