Angela: In the last few lessons,
we looked at implementing source control locally
using the command line and also remotely using GitHub.
So now I wanna take you a little bit further
and I wanna 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 conflict 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 gonna 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 angelabauer.
So that was the one that we saw earlier on.
So I'm gonna 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 gonna 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 chapter 4
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 gonna 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 gilfoyleismyothername.
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 preexisting code base or repository.
And now what I can do
if I head back to the gilfoyle account.
So I'm just gonna 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 angelabauer,
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.
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.
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 zero, but now I have one.
And it's showing as 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 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 requests
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 project
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 of, right?
You can see that a total of 4,300 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 him 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.