In the last few lessons, we looked at implementing source control locally, using the command line 1
and also remotely using GitHub. 2
So now I want to take you a little bit further and I want to talk about collaboration using remote repositories 3
and GitHub because this is one of the best ways to start working in a team of programmers and to contribute 4
your skills to open source projects. 5
So we've seen all of these four areas the Working Directory, the Staging area, the Local Repository 6
as well as the Remote Repository, 7
and you should be pretty familiar with all four of these areas by now. 8
Now in the next scenario, let's shift over to just look at the Local and Remote Repository that you 9
own. 10
Let's say that, 11
Angela, so myself, I own this repository. 12
I created it locally and then I pushed it to my remote repository on GitHub. 13
Now let's say that I have an evil twin who's called, I don't know, 14
Bangela. That's a terrible name. 15
Let's say that she also wanted to make changes to my repository. 16
She's looking at my code base and you know, she wants to add some features or fix some bugs or do something. 17
Because I own this remote repository over here. 18
In order for her to work on it, she could make a copy of it that exists on her GitHub account. 19
Remember, this is different from "git clone". 20
Git clone is just grabbing at the entirety of the repository and then cloning it to your local work 21
environment. 22
Now, in this case, we're basically just copying a repository that's hosted on GitHub and we're keeping 23
the copy under our own GitHub account where we can make changes to it. 24
So this in terms of GitHub lingo is called Forking. 25
Now once you've forked a remote repository, then you now own it. 26
You have full permissions to do whatever it is that you like with this copy of the repository, because 27
as you can imagine, it would be pretty crazy if everybody could modify your source code on all of your 28
open source repositories because, you know, it would lead to maybe amateurs changing all sorts of 29
things that you don't want them to or, you know, people making features that are incompatible with 30
what you've got already. 31
Basically, you would only give people who you have a trusting relationship with, write 32
access, to your remote repository. 33
So say if you worked within a team and you're all working on a product, then everybody in the team 34
probably has both read and write permissions on a single remote repository and that way they can "git 35
clone" and work on it locally and then push it and resolve any sort of conflicts that way, 36
but you don't want anybody on the Internet having those kind of permissions. 37
So how do you implement this kind of open source collaboration then? 38
Well, it's through Forking and making Pull requests. 39
So now let's say that evil Angela, Bangela has forked my repository. 40
So on her GitHub account, she now owns a copy of my repository and from this point she can then clone 41
that repository to work on it locally. 42
And if she decides to add some features to it, maybe, you know, improve the code base or add some 43
more code or do something crazy or whatever it is that she wants, then after she's happy with that 44
and she's committed those changes, then she can push it to her remote repository. 45
And then if she wants me or good Angela to incorporate those changes that she made, then her only option 46
is to make a "Pull request", 47
if she is not within that trusted pool of people who all have read and write access to my remote repository. 48
So say if she only has read access, then she would have to make a Pull request. 49
And it's almost like making a suggestion. 50
Here are some suggested changes that I've been working on. 51
What do you think about it? 52
If you okay it, then please, you know, merge it to your remote repository. 53
The reason why it's called a Pull request and not a push request is because the person who has the write 54
permission to the repository, 55
so I have write permission to my own remote repository, which has been forked and duplicated by, you 56
know, my evil twin. 57
If she wants to incorporate those changes, then I have the deciding vote so I can review those changes 58
and I can pull the changes over. 59
So it's not a push because you don't own the rights to the remote repository that you're trying to push 60
to. 61
In this case, if I decide after a code review that actually those features that she added were pretty 62
great and it seems compatible with my code so far and doesn't break anything, then I would approve 63
the pull request and merge her repository with my own, so the changes will be reflected in a new commit. 64
So let's take a look at this in action. 65
So here we've got our original Story repository. 66
So this is a remote repository, remember, because it's hosted online on GitHub and we've got a number 67
of commits and we've been doing some modifications and writing to write our storyline. 68
Now I'm going to log out of my account. 69
So that was the account that created the Story and then I'm going to sign in using a different account. 70
So right now I'm signed in to a different GitHub account. 71
This account is named "gilfoyleismyothername", and now I'm going to search for that repository. 72
So I found the Story repository by the user angelabauer. 73
So that was the one that we saw earlier on. 74
So I'm going to go into this repository and you can see that all of these lines and files are publicly 75
visible and you can read through all of it, even though you are now not signed in to the account that 76
created this repository from here, what I'm going to do is I'm going to Fork this repository. 77
As we mentioned before, forking is simply making a copy or a duplicate of a remote repository and putting 78
it under your own GitHub account. 79
You can see this user that I've created is called gilfoyleismyothername, and now I have this repository 80
under my own username, so I've made a copy of it and you can see it's exactly the same as before. 81
Everything's been copied over, including all of the previous commits that were made. 82
So from here I'm going to make some changes. 83
So let's maybe change one of these storylines. 84
So let's change chapter 4. 85
So let's say that this other user, this other person has some suggested improvements to my code, or 86
in this case, to my writing. 87
They're still keeping the spirit of the original repository alive because we are now converting into 88
a space-theme or an alien-theme. 89
So I've made my changes to chapter4, and I'm going to commit those changes saying, "Add more space- 90
theme to chapter 4." 91
So that's what I did, and I'm going to commit to the master branch. 92
So this is the master branch of my own forked copy of the Story repository. 93
So once I commit those changes, then we can view what it currently looks like under the Graphs. 94
If we have a look at the Network, 95
you can see that this is the point where I forked the story repository and that commit was created by 96
Angela Yu, which basically merged this branch to the master branch. 97
So we did that 98
two lessons back, 99
if you remember. 100
The latest commit though, is made by this current user, 101
gilfoyleismyothername, and you can see that I've added it to the master branch of my forked copy 102
of that repository. 103
Say, if I now open up a incognito window and I log back in to the Angela account and go over to that 104
Story repository, you can see that if I have a look inside my Graphs go into Network that that latest 105
change, it's not reflected on my master branch. 106
It's showing up as a separate branch made by gilfoylismyothername and you can see the members 107
who have forked your repository. 108
This is a great way of collaborating because you can have contributors, make edits or add new features 109
to your pre-existing code base or repository. 110
And now what I can do if I head back to the Gilfoyle account, 111
so I'm just going to flip through these two so that you can see, right now I'm inside the Gilfoyle account, 112
and this is the angelabauer account. 113
Now, under the Gilfoyle account, what I can do is I can make a Pull request. 114
We can do that here 115
and you can see that it's able to merge. 116
And these are the changes. 117
So swapping that word for that word, swapping that word for that phrase. 118
Now, all I have to do is hit, Create Pull request and tell the original author, which is Angela 119
Bauer, what I've done, why I think my modifications or my features are worthy to be merged with the 120
original repository. 121
And you know, 122
any other notes, right? 123
Any other comments that I have. 124
Let's just say... 125
Always helps to be complimentary. 126
Now, let's go ahead and create a Pull request. 127
The pull request is done, 128
but if we have a look back into the Story repository, you can see that those changes are not made right? 129
It's because I don't own this repository. 130
I don't have write access, only have read access as a member of the general public and not a member 131
of the trusted inner circle. 132
So I can only suggest my changes. 133
If we head over back to the angelabauer account who owns this repository. 134
Now, if I have a look under Pull requests, I've got a brand new Pull request, right? 135
So it previously was 0, but now I have 1 and it's showing as 1 Open Pull request. 136
And this is added a minute ago by 137
Gilfoyle and if I look at it, I can see why he thinks that this modification is necessary and what 138
were his commit message. 139
And I can also take a look at the commits that he made and compare the differences. 140
So review those changes. 141
So I could say something like, great job, 142
Gilfoyle. And I can submit this feedback to 143
Gilfoyle and approve merging these changes. 144
Now all I have to do is hit Merge, Pull request and maybe add a, "Merged from Gilfoyle's modifications 145
to chapter 4." 146
Okay, so let's go ahead and confirm the merge. 147
And now you can see that that commit is added to angelabauer, master. 148
So if I have a look inside my Graphs now, 149
you can see that the latest commit was my merge and you can see where it came from. 150
It came from a fork made by Gilfoyle, which shows up as a separate branch, and then it got merged 151
back into the main branch of the main repository. 152
So some people use GitHub purely as version control for their own projects and use some of the features 153
that we discussed in previous lessons, 154
but there's also a huge community of awesome coders on here who have created really brilliant projects 155
and if you can see ways of improving it or contributing to it, then it's a great way of starting to 156
learn how to work in a team of programmers, which is a really essential skill when you're working for 157
a startup or for a company. 158
So, for example, if we have a look at the Alamofire repository, if you have a look at the contributions, 159
you can see that there have been loads and loads of other users who have looked at the code and done 160
things, you know, or made suggestions, and to steadily improve this framework that, you know, everybody 161
else is benefiting off, right? 162
You can see that a total of 4300 forks have been made and there's currently four open pull requests, 163
but 559 pull requests were closed. 164
So let's have a look. 165
So, for example, in this case, this guy updated the Readme to the current version. 166
So that's obviously just editing a text file and that's pretty much within anybody's capabilities, 167
right? 168
And then it got merged by somebody who owned this repository and they gave them a bit of feedback. 169
Right? 170
But there's other things like, you know, code additions or code deletions or modifications that people 171
have made. 172
So this guy made some fixes and he's documented: 173
what were the goals, 174
what were the implementation details, what were the tests that he performed? 175
And then the guy who owned the repository said, hey, just, you know, maybe one thing that you need 176
to change. 177
Have a look in here. 178
And then once it was changed, then it was approved and merged with the master branch. 179
Have a look around on GitHub and see what are some of the cool projects that you could maybe get involved 180
in. To begin with, 181
have a look at the libraries that you've been using and if you want, you can build on top of it, either 182
for your own goals and purposes, 183
but also, you know, if you're building on top of somebody else's open-source code, then it's a nice 184
thing to contribute back to the open source world by forking and making a pull request to offer your 185
improvements or bug fixes or new features. 186
As I said, it's almost like a social network for programmers, and you can make a lot of great friends 187
on here, and you can also get a lot of help on here in your development journey. 188
So I hope you enjoyed all of that and I will see you on the next lesson.