UpStream and DownStream
In term of “flow of data”, your repo is at the bottom (“downstream”) of a flow coming from upstream repos (“pull from”) and going back to (the same or other) upstream repos (“push to”).
In terms of source control, you’re downstream when you copy (clone, checkout, etc) from a repository. Information flowed “downstream” to you.
When you make changes, you usually want to send them back “upstream” so they make it into that repository so that everyone pulling from the same source is working with all the same changes.
You cannot always make a branch or pull an existing branch and push back to it, because you are not registered as a collaborator for that specific project.
Forking
Forking is nothing more than a clone on the GitHub server side:
without the possibility to directly push back, with fork queue feature added to manage the merge request
You keep a fork in sync with the original project by:
- adding the original project as a remote
- fetching regularly from that original project
- rebase your current development on top of the branch of interest you got updated from that fetch.
Only contributor can approve the changes you pushed into fork for merge with original code
Clone
When you are cloning a GitHub repo on your local workstation, you cannot contribute back to the upstream repo unless you are explicitly declared as “contributor”.
So that clone (to your local workstation) isn’t a “fork”. It is just a clone.
upstream generally refers to the original repo that you have forked
origin is your fork: your own repo on GitHub, clone of the original repo of GitHub
The general pattern is as follows:
- Fork the original project’s repository to have your own GitHub copy, to which you’ll then be allowed to push changes.
- Clone your GitHub repository onto your local machine
- Optionally, add the original repository as an additional remote repository on your local repository. You’ll then be able to fetch changes published in that repository directly.
- Make your modifications and your own commits locally.
- Push your changes to your GitHub repository (as you generally won’t have the write permissions on the project’s repository directly).
- Contact the Contributor once u have committed your changes in fork to pull it in orginal