Personal forks are a standard open source approach to tool for making pull requests against repos where you don’t have write access. It’s a little more complicated than working directly in the repo, but it’s not difficult.
...
Terminology
Fork: On GitHub, a fork means making is a copy of a repo into in your own account so that you have write permissions to push commits and branches to it. This is different than the broader open source term of forking a project because of a disagreement about direction. We are talking about the gentle GitHub term, not the aggressive governance term.
Upstream: the repo you are ultimately contributing to. In our world, this is likely in the openedx GitHub organization.
Remote: a server copy of a repo. A local repo on your machine can have a number of different remotes, and pull from them separately. Each remote has a name and a URL. The default remote is called “origin”. You can see your remotes' names and URLs with git remote -v.
...
Visit the repo on GitHub.
In the upper-right corner is a Fork button. Click it.:
On the next screen, you will be asked where to fork it, called the Owner. Choose your own personal account (the default choice):
If you are a member of the edx organization, it will be listed in the drop-down, probably with “insufficient permission”, meaning you cannot choose “edx” as the Owner.
DO NOT FORK INTO edx EVEN IF YOU CAN. Use your personal accountIf you have permissions to fork into your company’s organization, you should check carefully with your process owners to see if you should.
The downsides to forking into your organization:
Now there will appear to be two sources of truth:
openedx/repoandmyorg/repo. Developers will have to be careful about which to clone, and which to merge into.There’s now a shared task of keeping the two repos in sync.
Getting the fork locally
How you get the fork locally depends on whether you already have a local repo copy that you want to keep. If you have a local copy but don’t need it, you can delete the repo directory and use “I don’t have a local copy.”
...
B. I have a local copy I want to keep
| Note |
|---|
The rename will change the remote of all your branches to upstream, which is not what you want. So, it is probably best to complete your work and remove the old copy, and then go with plan A. |
Rename the existing remote:
Use
git remote -vto check that the openedx repo is named “origin”Rename the remote to “upstream”:
git remote rename origin upstream.
Add a new remote for your fork:
git remote add origin https://github.com/USER/REPO.git
...
You now have two remotes: your fork called “origin” and the openedx core repo called “upstream”. Before beginning work on a change, you will want to get the latest code from upstream into your fork. Keep in mind that some repos use a “master” branch, others use “main”. If you are in a “main” repo, replace “master” with “main”:
Switch the current branch to master:
git switch master.Pull down the changes from upstream and update your master:
git pull upstream master --ff-onlyIf everything has been done right, this will be a fast-forward merge, with no explicit merge commit. You shouldn’t have changes on your master, but if you do, the
git pullcommand will fail with “fatal: Not possible to fast-forward, aborting.” If this happens, you will need to fix your master branch before continuing. (TODO: explain how to do this.)Push the changes to your fork to keep it up to date:
git push.
...
Create a branch locally:
git switch -c user/feature-namedescription.Make your changes and commit them.
Push your branch to your fork:
git push -u origin @.Make a pull request on GitHub. The base repository should automatically choose the upstream repo.
Review and work on the pull request as usual. You can push new commits to your branch as usual.
Ask the owning team to approve and merge your pull request.
...