This article provides outlines on how to contribute to GitHub projects by forking a repository, making changes locally, and pushing updates to your fork. Additionally, it covers setting up SSH credentials to securely push changes to GitHub. Whenever I stare at Git, and felt my soul leave my body. If you feel the same way — this guide is for you.
As someone who has battled Git’s quirks (and lost a few times), I’ve compiled the exact steps my manager taught me to.
- Fork a repo without breaking anything
- Keep my fork updated (so I don’t accidentally submit ancient code)
- Set up SSH so GitHub stops asking for my password every 5 seconds
No vague advice — just clear, battle-tested commands that actually work. 🙂
Description
Contributing to open-source projects on GitHub involves creating a fork of the original repository, making changes in your local copy, and submitting a pull request to the original project. To ensure smooth collaboration, it’s essential to keep your fork updated with the latest changes from the original repository. This guide walks through the entire process, including SSH key setup for secure authentication.
Why I Wrote This Guide
After asking my manager the same Git questions one too many times — and sensing his patience — I decided to document it all-before his patience runs out and he starts charging me for his Git lessons like (“Hello, how do I fork again?”, “Hello, I got an error when I push”). This article is my self-defence guide against:
- My gold fish memory (“Wait, was it upstream or origin?”)
- The inevitable day he signs and says, ‘Didn’t we go over this..?’
- Forgetting the steps (because git commands vanish from my brain instantly)
- Repeating mistakes (like pushing to the wrong remote again)
- Triggering my manager’s “I already explained this” look.
What I will cover
Forking & Syncing — How to clone, update, and push changes without summoning Git demons.
SSH Setup — Stop typing passwords; let your machine handle authentication securely.
By the end, you’ll confidently contribute to projects — without fear of breaking the repo.
Ready? Let’s Git into it. (Sorry, we have to.)
Section I: Forking, Cloning, and Syncing with the Original Repository
1. Fork the Repository, and why?
Forking creates a personal copy of the repository under your GitHub account. This copy is independent but maintains a link to the original repository, allowing you to:
- Submit pull requests to the original project.
- Pull updates from the original repository to keep your fork up to date.
Steps:
- Navigate to the repository on GitHub.
- Click the Fork button in the top-right corner.
Once forked, your repository will show:
“Forked from [original-repository-url]”
2. Clone Your Forked Project Locally
To work on the project, clone it to your local machine:
- Create a new project directory.
- Copy the SSH URL from your fork (use the SSH tab in GitHub).
git clone git@git.your-company.net:username/repository.git
3. Configure Git to Rebase on Pull
This ensures a clean commit history when pulling updates:
git config pull.rebase true
4. Add the Original Repository as a Remote (Upstream)
git remote add upstream https://git.your-company.net/team/repository.git
5. Verify Remote Repositories
git remote -v
Expected output:
origin git@git.your-company.net:username/repository.git (fetch)
origin git@git.your-company.net:username/repository.git (push)
upstream https://git.your-company.net/team/repository.git (fetch)
upstream https://git.your-company.net/team/repository.git (push)
6. Fetch Changes from the Original Repository
Before starting work, pull latest changes from upstream:
git fetch upstream
7. Checkout to your development branch
First, list all branches to see available branches and confirm your dev branch exists.
git branch -a
Verify upstream tracking (if the branch tracks a remote branch):
git branch -vv
Well, Time to get our hands code. Let’s jump into our development branch!
git checkout dev
8. Makes your changes
Let’s say, you create a python file and write some code.
echo “Hello, this is a new file” > hello.py
9. Stage and Commit Changes
git add .
git commit -m “Add hello.py with greeting message”
10. Push Updates to Your Fork
git push origin dev
After making changes, push them to your fork. This keeps your fork synchronized with the original repository, which is crucial for submitting pull requests.
Section II: Setting Up SSH Credentials for Secure Git Push
Before pushing changes, ensure SSH authentication is properly configured.
1. Check Git Configuration
Verify your .git/config file (run from your project directory). In the config file, you should be able to verify whether you clone using https or ssh.
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@git.your-company.net:username/repository.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
vscode-merge-base = origin/master
[pull]
rebase = true
[remote "upstream"]
url = git@git.your-company.net:team/repository.git
fetch = +refs/heads/*:refs/remotes/upstream/*
[branch "dev"]
remote = origin
merge = refs/heads/dev
vscode-merge-base = origin/master
2. Generate SSH Keys
ssh-keygen -t rsa
- When prompted, name the file: id_rsa
- Set a secure passphrase (optional but recommended).
3. Copy SSH Keys to the SSH Directory
cp id_rsa id_rsa.pub ~/.ssh/
4. Copy the Public Key and Add to GitHub
- Open id_rsa.pub and copy its contents:
- Go to GitHub → Settings → SSH Keys
- Click New SSH Key, paste the public key, and save.
5. Push Changes Securely
It’s time to push our changes:
git push origin dev
- origin: Your fork.
- dev: Your development branch.
Finally, we can celebrate with a git push. But, don’t forget to git pull tomorrow by the following command as the development with git never ends!!!
git pull upstream master
In the mean while, we wait.. as our manager reviews our “mighty” code. He might be:
- The Merge: “Hmm. Looks good! (But why did you use 200 lines in this call)
- The Questions: “So… how does this actually work?” (…he may silently Googles)
Next: “How to explain your code to Managers (without panicking)” — stay tuned! 😉