In the last few lessons, we looked at implementing source control locally, using the command line
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.
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's looking at my code base and you know, she wants to add some features or fix some bugs or do something.
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.
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've forked 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 would only give people who you have a trusting relationship with, write
access, to your remote repository.
So say if you worked 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 "git
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 her 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 okay it, then please, you know, merge it to your remote repository.
The reason why it's called a Pull request and not a push request is because the person who has the write
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 it's 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 a code review that actually those features that she 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 GitHub and we've got a number
of commits and we've been doing some modifications and writing to write our storyline.
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 in to 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 angelabauer.
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. From here, what I'm going to do is I'm going to Fork this repository.
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.
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 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 chapter4, and I'm going to commit those changes saying, "Add more space-
themes to chapter 4."
So that's what I did, and I'm going to commit to the master branch.
So 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 under the Graphs.
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.
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.
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, it's not reflected on my master branch.
It's showing up as a separate branch made by gilfoylismyothername and you can see the members
who have forked your repository.
This is a great way of collaborating because you can have contributors, make edits or add new features
to your pre-existing 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 account,
and this is the angelabauer account.
Now, under the Gilfoyle account, what I can do is I can make a Pull request.
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.
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 other notes, right?
Any other comments that I have.
Let's just say...
Always helps to be complimentary.
Now, let's go ahead and create a Pull request.
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, 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.
If we head over back to the angelabauer 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 0, but now I have 1 and it's showing as 1 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 compare the differences.
So review those changes.
So I could say something like, great job,
Gilfoyle. And I can submit this feedback to
Gilfoyle and approve merging these changes.
Now, all I have to do is hit Merge pull request and maybe add a, "Merged from Gilfoyle's modifications
to chapter 4."
Okay, so let's go ahead and confirm the merge.
And now you can see that that commit is added to angelabauer, master.
So if I have a look inside my Graphs now,
you can see that the latest commit was my merge 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, 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 four 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 they gave them a bit of feedback.
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 he's documented:
what were the goals,
what were 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.
Have a look around on GitHub and see what are some of the cool projects that you could maybe get involved
in. To begin with,
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.
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 I hope you enjoyed all of that and I will see you on the next lesson.