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 anythingKeep my fork updated (so I don’t accidentally submit ancient code)Set up SSH so GitHub stops asking for my password every 5 seconds 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. 🙂 actually 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: same Git questions 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. 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) 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. without 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. 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. 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]” “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). 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 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 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 git remote add upstream https://git.your-company.net/team/repository.git 5. Verify Remote Repositories git remote -v 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) 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 git fetch upstream 7. Checkout to your development branch First, list all branches to see available branches and confirm your dev branch exists. dev git branch -a git branch -a Verify upstream tracking (if the branch tracks a remote branch): git branch -vv git branch -vv Well, Time to get our hands code. Let’s jump into our development branch! git checkout dev 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 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” git add . git commit -m “Add hello.py with greeting message” 10. Push Updates to Your Fork git push origin dev 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 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 [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 ssh-keygen -t rsa When prompted, name the file: id_rsaSet a secure passphrase (optional but recommended). 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/ 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 KeysClick New SSH Key, paste the public key, and save. 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 git push origin dev origin: Your fork.dev: Your development branch. 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 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) 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! 😉
