So by forking, we've made a copy of the repository that exists on my account on Colt and I've made
some changes locally.
I push them up.
We see the changes.
We did this in the last video where it's that commit basic.
No, not basic.
Here it is change color palette on this style directory.
Anyway, I have some work and it actually shows I am one commit ahead of the original repository that
I forked from.
So GitHub is actually telling me automatically, hey, you have some work on your fork that is not on
the original and I can just ignore that and never do anything with the original, or I can actually
share my work or attempt to share it by making a pull request.
I can make a pull request from my fork to the original repository.
So I'm not going to actually go through with it because I don't want to bother the creator of this repository
with a dumb, useless pull request that they'll just close.
But you can see it's the same interface.
I can create a pull request with my changes.
I can leave a comment, I can explain why you know why I think this should be merged in.
And then the repository owner and anybody who has merge permissions can then take my poll request and
merge it in or close it or whatever they want to do.
So that mechanism is really, really important.
This would be a way for me to make a real contribution, not the silly one that I did, but I could
make a real contribution to a project that I don't own.
I don't have permission to push to it, but I can fork it.
I can make my own suggestions, my own changes, and then open up, pull request.
And that's the basis of this workflow.
So this workflow, I'm calling it fork and clone.
Other people say fork and clone.
I'm pretty sure it's not some official term, but it's common enough.
It allows a whole bunch of people to work on the same project without actually all having permission
and write permissions for the same repository.
So I have some diagrams that I'll be using to illustrate how this all works.
If we have three collaborators, which is just a subset, let's say we have way more on a big project,
potentially thousands of people who want to collaborate.
But here on the diagram, I've only included three people me somebody named Taylor and somebody named
Lupe.
And then we have the official project repository.
Maybe we're working on React or some, I don't know, some big repository that we don't have access
to, to directly push or change settings.
We have to make a fork.
So we each fork, that's what the fork is representing.
And then on my local machine, I clone my fork.
So that's what this is indicating.
So I have my fork that I made from the original project repo.
I cloned that down.
So now I have this automatic remote set up called Origin.
Just because I cloned this repository, the default remote name is going to be origin.
So Origin refers to my fork.
That's done automatically when I cloned.
But then I'm going to set up a second remote and this remote is going to be anything I want.
But normally we would call it upstream.
That's a very conventional name and it refers to the original repo that we forked.
So this allows me to basically have a place where I can do my own work and push changes up to.
But also if there are changes made to the original repository on a large open source projects like React,
there might be new commits and pull requests merge daily.
I want to be able to get those down on my machine.
So even if I can't push up, I can still pull changes down so often upstream or original will be the
name of this remote.
But now we have two remotes, one going to my fork and one going to the original.
So now if I do some work, I make a new commit or a bunch of commits.
Normally this would be on a feature branch, but for the diagram sake I'm just doing it on the main
branch or whatever this branch is.
So I make some work or I make some commits.
Then if I want to try and share it with the repository creators, I definitely cannot push up because
I don't have permission.
So instead I can push up to my origin, which is my fork.
I can push whatever I want up there.
I could make the whole thing empty.
I have permission to do anything with that because I own that fork.
So now on GitHub I have my fork that I've worked on and I can make a pull request just like what I showed
you here where I forked 2048.
I can make a PR and ask for my changes to be merged in.
So then if I do that, open up a pull request, then it's up to the original or the official project.
Repo owners, somebody who maintains it, who has permission to accept, to merge or close my pull request.
And if my pull request is accepted, it's merged in.
So then the next step is basically show up at work again and pull down my changes from upstream.
So there's new work that was done on upstream.
I don't have it locally, so I go and get the latest from the real repository.
I pull that down and then I can do some more work locally.
Push that up to my.
Fork and then from my fork make a request when necessary.
So the whole point of this workflow is to allow people who don't have direct access, direct permission
to push or to change anything in a project repository.
They can still collaborate, they can still make pull requests by forking and then pushing their changes
to their fork and opening a PR.
So this would be the sort of cycle we pulled down the latest changes from the official repo.
That's one remote.
We make changes, we push them up to our fork and then we can make a pull request if we want, with
suggestions or with our changes that we want to be merged into the original repo.
And then we just wait and we hope that someone responds.
So here's a short summary for the project.
Clone the fork, add our upstream remote, do some work, push to the origin and then open a PR to the
original or the upstream.
So I'm going to demo that again in the next video we'll wrap up by just talking about why this is a
good idea.
In some situations, this is not a workflow that you may want to use on every single project that you're
working on.
But again, at a larger scale where there might be some project that thousands of people might be interested
in working in, or even if it's just two or three people, but you don't want to give them access directly
to your repository.
People can still make these suggestions, they can make their own changes and hope that you merge them
and they can make a pull request from their forks.
So this allows us to work with tons and tons of people without having to have direct collaborators added
to a repo.