Okay.
So we spend a lot of time talking about poll requests, but it's a very important feature and it's actually
going to come up again in this next workflow.
I'm going to introduce I'm calling it Fork in Clone or Forking and cloning.
It's it's a different approach to what we've seen so far.
So this is a workflow where instead of just one centralized repository on GitHub, every developer has
their own GitHub repository in addition to some main centralized repo.
And then individual developers can make changes and push to their own versions, their own forks before
making pull requests.
So I'm going to diagram all this and hopefully it makes sense.
The the whole point of this is that large open source projects, projects with lots of contributors,
maybe thousands and thousands of contributors, they often employ this strategy or this workflow where
there might be a handful of actual maintainers and owners of the project.
They're not adding thousands of people as direct contributors like we saw with an invite where I could
invite Stevie.
I manually went in here.
Where was that?
Manage Access and I invited Stevie.
So they're not doing that for every single person who wants to collaborate on React or TensorFlow or
something.
Instead, this workflow, this fork and clone workflow enables anybody to try and make a contribution.
You don't need permission.
You make your own copy, you try making changes and then you make a PR.
Anybody can make a pull request.
So the first concept to understand is forking.
Forking is a feature that is not part of git itself.
Just like a PR is not part of Git, it is a feature of GitHub and other similar hosting services for
Git repos.
When we fork a repository, it creates a personal copy of somebody else's repository on our GitHub account.
So we would call the new copy a fork of the original repository.
So when I click the button to fork a repo, I'm asking GitHub to please make me a personal copy of this
repo.
This only works if it's a public repo and we have access to it.
Or I guess if it's a private repo, you can fork it if needed, but you still need access to it.
So I'll demonstrate this.
I want to be clear again, this is not a git feature, it's part of GitHub.
So on some repository this is for example, not my repository.
Clearly automatic Udemy course enrol or get paid.
Udemy course is for free.
I don't even know if this is still up or not, but this is not my project.
But if I want to work on it, I'm not a collaborator.
Instead I'm going to click this fork button right there.
So when I do that, notice what the URL or the what would you call this?
I guess the breadcrumb is somebody's username slash the repository name.
When I fork, I click that button.
Now we have a copy that is on my account, Colt slash, Automattic, blah, blah blah.
So I still have all the history, all the files, but I can do my own stuff on here.
I can clone this, I can delete branches, I can completely break code.
It's totally up to me.
It's just my repo now and it's just based upon the original.
So here's the two side by side, the original, and then my fork.
It shows my username, but also it says where I forked it from.
And that's just an intro to the concept of forking.
In the next video.
I'll demonstrate it and then we'll talk about how we can use this concept to make open source contributions.