I'm back in the collaborator account,
as I called it. And as you know,
this collaborator now has access to this
private repository in here.
Besides collaboration, we also have the concept
of contribution in GitHub.
Contribution is something you can see in open-source
projects. This means projects where the code,
the underlying source code
of a website, for example,
or of a programming language,
is shared publicly,
and where anybody can implement
new features or fix bugs in there.
Of course, the process of such an
open-source project and how people
can contribute to it has to be well-structured.
Otherwise, anybody could basically
push any kind of code to this project.
The structure of such an open-source project
is not the core focus of this course, though.
I just want to show you how you
can contribute to open-source projects.
Meaning, how can you suggest that your
code changes should be implemented
to an existing GitHub project
without being a collaborator?
For this, I'll go back to the owner account
that I created.
So here again, I'm in Chrome.
So I am in my mLoAM account.
In there, I'll go to the landing page of this repository,
there, to the repositories ribbon,
and there I'll create a new repository.
Let's create a new one.
And I'll call this "open-source" now
and this project will be a public project.
And with that, we can actually create this repository.
In this project. I'll again, add a new file,
a new dummy file,
which I'll call "initial-code.txt."
And also name the commit accordingly.
So "added initial code,"
and I'll commit this.
Nothing new so far.
If I now go back to the other account,
so to the earlier collaborator account
here, and go to this mLoAM page,
then I can see these two public repositories,
but keep in mind that although I can see and access this
repository here and I could, of course, also clone it,
if I would like to push to this repository,
then this would not be possible
because this repository is
not part of this user account.
It is owned by another account,
and therefore I don't have the rights to push to it.
If the other person would add me
as collaborator, yes, then this would work.
Then I would be part of this repository search you say,
but in this case I can only access it,
but not contribute to it.
Therefore contributing to open source projects
works a bit differently.
Because if we would be able to bring this
project to our own repository,
so basically, in our user account, your repositories.
So if this project would be here,
don't get distracted by these projects here.
These are not related to this course here.
So if we would have access
to this repository in here,
then it would be part of our user account,
and then we would be able to push to this project
even without having the personal access token
required to do so actually.
Well, for this, I'll go back now
to the mLoAM repository, in my case,
and to this open source project.
And here I will now go to this fork option over here.
As you can see by hovering over it
"fork" here means that we can
fork our own copy of this repository to our own account.
So we create a complete copy of this project,
which will then become part of our GitHub account.
And therefore this copy will not be related at all to the
repository, which is part of the owner account.
So to keep things simple,
keep in mind that currently this open source project
is linked to this mLoAM account here.
If we now press "fork,"
then we can choose where we should fork this project to,
this Academind account here
is nothing you should worry about here,
It's all about this Manulorenz account.
So this account I'm currently using.
So let me select this.
And now the forging takes a few seconds.
This is totally normal.
Now the fork was successful and if you now check
the left part of this page,
then you see that now Manulorenz is the owner of this
open source repository.
We see the information that this was forked from, well,
another repository.
This is something we'll dive into in a few minutes,
but generally now we have full access to this project.
And as we have created a personal access token
in the last lecture,
to be able to access this GitHub account
locally from this computer, with our Git project,
well, then we should be able now to
clone this project and to implement
a change to this code, for example,
which could be a back fix in the real world
or a new feature, which you might want to implement.
To do this,
we'll follow our good old approach
of clicking onto code and
copying the URL of this repository now again,
which is part of this user account now.
Now I'll create a new folder and open a new
visual studio code instance.
We know how this process works in the meanwhile.
So here I created a folder named "fork,"
and now I'll simply clone
the repository into this folder,
again with a space and a dot
to have the same structure in here
inside this fork folder.
And now we have this initial code text file.
And now, what I could do is
I could create another text file
named "added-new-feature.txt," for example,
and there I could add a change. Well,
"New feature added" to have some texts in there,
which I can save now.
Now I'll add this to the staging area
and I'll commit this
"implemented new feature."
And now,
well, I can push this to my repository, right?
As I said, we have the required access to my account,
which now holds the forked repository,
therefore with "git push origin main,"
well, this should be possible.
Let's see if this works.
Yeah, no errors, nothing like this.
So by going back to GitHub now,
to the account that holds the fork repository,
and if we now reload this page,
you see that we added this new feature text file,
nothing new so far.
The question now is how can we inform
the actual owner of the real repository? So to say.
So basically the owner of this open source repo.
So this mLoAM account.
So how can be informed this user
about the fact that we added a new feature,
and that will request him to implement this
new feature to his open source project?
Well, for this, we have to create a so-called
pull request.
You saw pull in the last lecture, pulling meant,
basically updating and implementing
the latest changes from GitHub locally on Git.
Here, "pull requests" simply mean
I request the owner of the initial repository
to pull the changes I made on GitHub here
and to implement those changes on his project on GitHub.
Therefore, if we go to pull requests now,
and over there,
create a new pull request, it's over here, this option,
we see that we have a base repository,
which is part of this mLoAM account.
So this is the initial owner of the repository.
And on the other head, we have the head repository.
This is the account where the forked repository lives in.
So in the left part, we always have the repository
where we request the pull, in the right part,
we have our repository,
so the repository of the person that
initiates the pull request.
If we scroll down a bit,
we can also find some information about what we changed
in this fork repository, not too much in our case,
so this is quite straightforward.
And now by clicking onto create pull request over here,
we can give a short overview of well, what was changed.
So with the headline here, so we implemented,
for example, "teams page," something like this,
And on there, you will then give
the owner of the repository,
a detailed description about what you did,
what you changed and well,
what the code is all about.
Not required for us here at the moment,
as it's just an example pull request here.
Therefore we can simply continue
with creating the pull requests down here.
So let's do this.
And now you'll see that this pull request
was obviously successful. So it is an
open pull request now.
And if we now switch back to the account
that owns the initial repository,
so this account here in my case,
and if I now reload this page,
you see that we have one open pull request
indicated by this symbol here.
And we can, of course now switch to this ribbon.
And in there we see now that we have this open pull request
here we see the headline we created,
let's now access it.
And then there, we can all dive deeper
into the pull request, what was made,
and so on.
As I said, for us, it's pretty straightforward.
We don't have any big changes.
We just added a new file.
So we won't dive deeper into this here,
but we have two important options here.
One would be to close the pull request.
This simply means that we do not agree.
So we are not happy with these changes,
and we don't want to implement these
into our project.
Or if we say yes, this is a nice change,
a nice addition, a nice bug fix, anything like that.
Then we can merge this pull request.
You remember merging from this module
means basically bringing the
changes of two branches together,
which is actually what is also happening right here,
in the case of a pull request,
merge the state of the project,
of the forked repository
and the main branch in there, in our case,
with the initial repository in the main branch.
So we'll merge this pull request now
by confirming this
once and twice here.
And now with this, we see the confirmation up here
with this purple symbol that we merged
our projects.
And by going back to the code ribbon over here,
you see that "added new feature" is now also
available in here. This is the pull request
implemented successfully.
And by going back to the other account,
which initiated the pull request,
well then there we can also see
that our merge was successful.
And with this, we've reached the end
of this Git and GitHub introduction module.
Now these are just the core basics of
what Git and GitHub are all about.
It is just important for you to understand
that these tools are existing
and how you can use these tools on your journey
to become a web developer.
Nevertheless, in the next lecture,
I want to give you a quick summary
of what you learned
and also about how you can continue
to dive deeper into Git and GitHub you want to.