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