Whether you're looking to contribute to an open-source project or to a private project where you don't have
write permissions, the way to do it is the same: using your own fork.
Here is how.
If you joined a new open source project or a new development team working on a private repository without single-branch permissioning, it's very likely that you won't get direct access to push commits or branches up to the repository itself.
If you want to check out the individual steps, keep reading.
1. Fork the repository
Let's use the
next.js project as an example. First, visit its page on GitHub, and click the "Fork" icon in the upper right of the page.
You now have a fork of the project under your own user account.
2. Clone it locally
Next, clone your forked version down to your local machine.
In the example case I will be typing in terminal:
git clone email@example.com:fpert041/next.js.git ─I personally use SSH to clone but you can use whatever method you prefer.
Note: If the Fork option is disabled, you need to tell the organisation to enable forking for that repo, in Settings >> Options >> Features. If the repository is private, they will need to make sure to enable also forking for private repositories for the organisation as a whole.
3. Keep it in sync with the source
Since you will probably want to contribute over time, you need to make sure your fork is in sync with the original.
To do that, add the original as a remote:
git remote add upstream ORIGINAL-REPO-URL
So in my example, I would type in terminal:
git remote add upstream https://github.com/vercel/next.js
TRY IT! ─If you check your remotes (git remote -v), you can now see that you have two "remotes" that your local repo is pointed towards:
origin, which points to your repo, and
upstream, which points to the original. It's all normal, bear with me :)
4. Spin up a branch
You will probably want to branch from whatever the project's default branch is. This is often
master, but in the case of
canary, at the time writing.
Depending on the project, there might also be a specific branch developers should be aiming to push to (E.g. a "
Make sure you're on the branch you want to track and that it's up-to-date with the source repo. If you just forked it, it always will be —but if there have been a lot of changes to the original repo since you forked it, yours might be out of sync.
This is why we wanted our forked repo to track the original repository as the
upstream. Now, let's see how to get a repo in sync. We will be using
canary as the example name for the branch we want to eventually contribute to:
git checkout canary git fetch upstream git merge upstream/canary git push origin canary
Now you can spin up your new branch:
git checkout -b my-feature-name
5. Edit, Open Pull Request, Merge
Let's assume that in our example, we created a branch called
Pro Tip: Don't do that, use a telling name instead!
We now want to make all the changes we want on our local branch, then commit, then push to our Forked remote.
git commit -m "Commit Name" git push origin fpert041-patch-1
Note: If you are only making a small improvement and you are part of the development team of the project, you can make your changes directly to the chosen development branch, then commit and push to your Forked repo, without branching out. The reason why, in most cases, you DO want to create a sub-branch, is because, if your Pull Request is not quickly merged into the original repository by the maintainers, you can still pull any new changes made to the original branch without having to merge all the time. Also, creating separate branches to deal with specific improvements or issue patching helps create better history tracking.
Now, you can create a pull request in the GitHub user interface. Visit your repo on GitHub and click the "New Pull Request" button, and you can create your PR from there.
In our example, we can open a Pull Request with the
canary branch of the original
next.js repo and submit the request.
In the real world, please make sure to explain the purpose and context of your Pull Request. This will allow reviewers to understand it and quickly check for approval. See GitHub's guide on How to write the perfect pull request.
That's it! The pull request will show up to the maintainers of the original repo and they can take it from there.